디자인 원칙

관리가 용이한 객체지향 시스템을 만드는 비결 1. "나중에 어떻게 바뀔 것인지" 생각 해보기

• 바뀌는 부분은 캡슐화한다.

  • 애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분과 분리한다.

  • 달라지는 부분을 찾아서 나머지 코드에 영향을 주지 않도록 캡슐화

  • 코드를 변경하는 과정에서 의도치 않게 발생하는 일을 줄이면서 시스템의 유연성 향상

• 구현보다는 인터페이스에 맞춰서 프로그래밍한다.

  • 인터페이스에 맞춰서 프로그래밍한다 라는 말은 상위 형식에 맞춰서 프로그래밍 한다라는 말이다.

• 상속보다는 구성(composition)을 활용한다.

• 클래스는 확장에는 열려있어야 하고, 변경에는 닫혀있어야 한다.

• 상호작용하는 객체 사이에는 가능하면 느슨한 결합을 사용해야 한다.

• 추상화된 것에 의존하게 만들고, 구상 클래스에 의존하지 않게 만든다.

• 최소 지식 원칙(Principle of Least Knowledge)

  • 객체 사이의 상호작용은 될 수 있으면 아주 가까운 '친구' 사이에만 허용하는 편이 좋다

  • 여러 개체가 복잡하게 얽혀 있어서, 시스템의 한 부분을 변경했을 때 다른 부분까지 줄줄이 고쳐야하는 상황을 미리 방지 가능

  • 객체 자체, 매개변수로 전달된 객체, 직접 생성하거나 인스턴스를 만든 객체의 메서드, 객체에 속하는 구성요소를 제외한 친구들은 피하기

• "Don’t call us, we’ll call you", 할리우드 원칙

  • 상위 수준의 모듈(프레임워크, 사용자 시나리오)이 흐름 제어권을 가지고, 하위 모듈(구현체)은 필요할때만 호출되는 구조를 의미

  • 즉, 하위 객체가 상위 객체를 직접 호출하지 않고, 상위 객체가 정해진 시점에 하위 객체 호출

  • 제어 흐름: 상위 → 하위

  • 의존성: 하위 → 상위

  • 책임: 상위(흐름제어), 하위(세부구현)

• 어떤 클래스가 바뀌는 이유는 하나뿐이어야 한다.

  • 어떤 클래스에서 맡고 있는 모든 역할은 나중에 코드 변경을 불러올 수 있음

  • 역할이 2개 이상이라면 바뀔 수 있는 부분이 2개 이상이라는 것