본문 바로가기

[Terry] JAVA

[Design Patterns] Strategy Pattern 3

이전 포스팅에서 만든 프로그램의 문제점에 대해 다시 정리해 보자.

자바 인터페이스에는 구현된 코드가 전혀 들어가지 않기때문에 코드 재사용을 할 수가 없다. 즉, 한 행동을 바꿀때마다 그 행동이 정의 되어 있는 모든 서브클래스들을 일일이 수정해줘야 하는데, 이는 새로운 버그를 발생시킬 확률이 높다.

이러한 상황에 어울리는 디자인 원칙은 다음과 같다.

"바뀌는 부분을 바뀌지 않는 부분과 분리해서 캡슐화 시킨다. 그렇게 하면 나중에 바뀌지 않는 부분에는 영향을 미치지 않은채로 그 부분만 고치거나 확장할 수 있다."

무슨 뜻인지 이해가 가는지...?? ㅋㅋㅋ

클래스 다이어 그램을 먼저 보면서 이해해 보자.
사용자 삽입 이미지

위에서 말한 디자인 원칙에 따르면, 자주 변하는 부분은 fly()와 quack() 이다.
이 부분들을 Duck 클래스와 분리하려면, 나는것과 관련된 집합과 우는것과 관련된 집합. 즉, 두 개의 클래스 집합(set)을 만들어야 한다.

그리고 각 클래스 집합에는 각각의 행동을 구현한 것을 모두 집어 넣으면 된다.
(ex 꽥꽥거리는 클래스, 삑삑거리는 클래스, 소리는 내지 않는 클래스 ... etc)

두개의 클래스 집합을 만들어야 한다는 것을 알았다면 다음으로 알아야 할 것이 무었일까??

바로 최대한 유연하게 코드를 작성해야 한다는 것이다. 처음부터 이런 문제가 발생한 원인은 오리의 행동인 fly()와 quack()가 유연하지 않았기 때문이었다.

추가로 Duck의 인스턴스에 행동을 할당할 수 있어야 한다. (이해가 힘들다면 소스를 확인해 보길...설명하기 귀찮아 지기 시작함..ㅡㅡ;;)

위와 같이 유연하게 코드를 작상하고자 한다면, 구현이 아닌 인터페이스에 맞춰서 프로그래밍해야 한다.

인터페이스에 맞춰 프로그래밍한다는 말은 자바의 인터페이스를 사용하라는 의미일 수도 있지만, 조금더 깊게 의미를 생각하면, 상위 형식에 맞춰서 프로그래밍함으로써 다형성을 활용해야 한다는 것을 의미한다.

그래서 위 다이어 그램과 같이 FlyBehavior인터페이스를 구현한 클래스 집합과 QuackBehavior인터페이스를 구현한 클래스 집합을 만든 것이다.

이런식으로 디자인 한다면, 다른 형식의 객체에서도 나는 행동과 꽥꽥 거리는 행동을 재사용 할 수가 있다.

음....추가로 설명해야 할 것들이 상당히 있지만, 역시나 공부한 내용을 다시 설명하는 것은 정말이지 어려운 것 같다. 새삼 선생님들을 존경하게 되었다는...ㅡㅡ;;;

마지막으로 소스하나를 올리고 이번 포스팅을 마치고자 한다.