Chater 01. 디자인 패턴의 세계로 떠나기, 디자인 패턴 소개와 전략 패턴

• 소프트웨어 개발 불변의 진리 : “변화”

  → 아무리 디자인을 잘한 애플리케이션이라고 해도 시간이 지남에 따라 변화하고 성장해야 한다.

  그렇지 않으면, 그 애플리케이션은 죽고 만다.

• 디자인 원칙 1. - “애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분과 분리한다.” → 바뀌는 부분은 따로 뽑아서 캡슐화한다. 그러면 나중에 바뀌지 않는 부분에는 영향을 미치지 않고 그 부분만 고치거나 확장할 수 있다.

• 디자인 원칙 2. - “구현보다는 인터페이스에 맞춰서 프로그래밍한다.”

  • “인터페이스에 맞춰서 프로그래밍한다” 라는 말은, 사실 “상위 형식(supertype)에 맞춰서 프로그래밍한다.” 라는 말이다.

    • “상위 형식에 맞춰서 프로그래밍하라”

    : 변수를 선언할 때 보통 추상 클래스나 인터페이스 같은 상위 형식으로 선언해야 한다. 객체를 변수에 대입할 때 “상위 형식을 구체적으로 구현한 형식”이라면 어떤 객체든 넣을 수 있기 때문이다. 그러면 변수를 선언하는 클래스에서 실제 객체의 형식을 몰라도 된다.

• 디자인 원칙 3. - “상속보다는 구성(Composition)을 활용한다”

• 전략 패턴은 알고리즘군을 정의하고 캡슐화해서 각각의 알고리즘군을 수정해서 쓸 수 있도록 한다. 전략 패턴을 사용하면 클라이언트로부터 알고리즘을 분리해서 독립적으로 변경할 수 있다.

Chapter 02. 객체들에게 연락 돌리기, 옵저버 패턴

• 주체(Subject) + 옵저버(Observer) = 옵저버 패턴

• 옵저버 패턴은 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체에게 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다 의존성(one - to - many)을 정의

• 느슨한 결합 (Loose Coupling) 은 객체들이 상호작용할 수는 있지만, 서로 잘 모르는 관계를 의미

• 옵저버 패턴에서는 다음과 같은 방식으로 느슨한 결합을 만듦

  • 주체는 옵저버가 특정 인터페이스(Observer 인터페이스)를 구현한다는 사실만 안다
  • 옵저버는 언제든지 새로 추가할 수 있다
  • 새로운 형식의 옵저버를 추가할 때도 주체를 변경할 필요가 전혀 없다
  • 주체와 옵저버는 서로 독립적으로 재사용할 수 있다
  • 주체나 옵저버가 달라져도 서로에게 영향을 미치지는 않는다

• 디자인 원칙 4. - “상호작용을하는 객체 사이에는 가능하면 느슨한 결합을 사용해야 한다.”

  → 느슨하게 결합하는 디자인을 사용하면 변경 사항이 생겨도 무난히 처리할 수 있는 유연한 객체 지향 시스템을 구축할 수 있다. 객체 사이의 상호 의존성을 최소화할 수 있기 때문.