헤드 퍼스트 디자인 패턴(개정판)- 에릭 프리먼 외 3명

디자인 원칙

애플리케이션에서 달라지는 부분을 찾아내고 캡슐화하여, 달라지지 않는 부분과 분리한다.
구현보다는 인터페이스에 맞춰서 프로그래밍한다.
상속보다는 구성(Composition)을 활용하라. SimUDuck 예제
Duck이라는 추상 클래스를 상속하는 다양한 종류의 오리가 있다.
Duck은 소리를 낼 수 있고, 헤엄칠 수 있다.
날 수도 있게 추가를 요청했다.
나는 것을 상위 클래스인 Duck에 구현하여 오버라이드하도록 하려고 했지만, 날아선 안되는 오리도 있다. 이러한 오리는 fly로직을 오버라이드해서 동작하지 않도록 해야했다.
fly라는 메소드를 인터페이스를 따로 만들어서 날아야하는 오리들만 날도록 하고자 했지만, 각각의 구현한 오리 클래스에서 모두 구현을 해줘야하기 때문에 코드 중복이 빈번히 발생하여 유지보수가 떨어지고 재사용성이 떨어진다.
fly라는 기능을 아예 위임하여서 구현체도 별도로 구성한다.
이 때, 구체 클래스인 특정 오리 클래스는 Duck도 상속 받고 flyBehavior 인터페이스를 구현한 구체 fly 클래스도 상속받을 수 없다. 어떻게 해야할까 ?
인스턴스 변수를 선언하고 주입받아서 사용!!

이는 상속, 구현을 넘어서서 결합도를 낮추고 응집도를 높히는 객체지향적인 방식이라고 할 수 있겠다, 오브젝트라는 책에서도 비슷한 내용이 나왔던 것이 기억이 난다.

- 상속과 구현은 생각보다 두 클래스 간에 결합도가 높다.
- 상속이나 구현을 받는 대신, 메시지를 통해 협력.
- 상속과 구현이 적합한 상황이 있을 것이고, 두 클래스가 각각 캡슐화 되어 메시지를 통해 협력하는 방식이 적합한 상황이 있을 것이다.

전략 패턴

알고리즘군을 정의하고 캡슐화해서 각각의 알고리즘군을 수정해서 쓸 수 있게 해 준다. 전략 패턴을 사용하면 클라이언트로부터 알고리즘을 분리해서 독립적으로 변경할 수 있다. 디자인 패턴은 훌륭한 객체지향 디자인 품질을 갖추고 있는 시스템을 만드는 방법을 제공한다. 패턴은 검증받은 객체지향 경험의 산물이다. 대부분의 패턴과 원칙은 '변경'문제와 연관되어 있으며 대부분의 패턴은 시스템의 일부분을 나머지 부분과 무관하게 변경하는 방법을 제공한다. 패턴은 개발자와의 의사소통을 극대화하는 전문 용어 역할을 한다.