Ch03. 객체지향 기본 원칙 - 객체지향 설계 원칙

설계가 필요한 이유 : 요구사항이 변경될 때 코드를 쉽고 안전하게 수정하기 위해 필요하다. 객체지향의 설계 방식으로 변경한 이유 역시 코드를 쉽고 안전하게 수정하기 위해서이다. 즉, 객체지향 설계를 이해하기 위한 첫걸음은 객체지향의 모든 원칙은 변경을 중심에 두고 있다는 사실을 이해하는 것이다.

객체지향 설계 원칙

• 협력에 필요한 행동을 먼저 결정하고 행동에 적합한 객체를 나중에 선택하라
• 객체의 행동을 먼저 구현하고 행동에 필요한 데이터를 나중에 선택하라

협력에 필요한 행동을 먼저 결정하고 행동에 적합한 객체를 나중에 선택하라

• 절차지향 방식에서의 설계(추측에 의한 설계)는 사용될 목록을 고려하지 않고 데이터를 설계하기 때문에 모든 경우에 사용 가능하도록 Getter와 Setter를 추가했다.
  • 겉으로는 필드를 캡슐화한 것으로 보이지만 Getter/Setter를 통해 실제로는 캡슐화가 깨지게 된다.
  • 데이터의 구조가 프로세스에 그대로 노출되기 때문에 데이터의 내부 구조가 수정되면 데이터를 사용하는 프로세스도 함께 수정될 수 밖에 없다.
• 책임을 이동(데이터를 사용하는 로직을 데이터를 구현한 모듈로 이동시키는 작업)을 하고 나면, 프로세스를 구현한 코드는 더 이상 내부의 데이터 구조에 의존할 필요가 없다.
  • 프로세스에서 데이터 구조를 변경해도 변경할 필요가 없다.
• 즉, 데이터를 자유롭게 수정하기 위해서는 외부 객체가 데이터가 아닌 행동에 의존하도록 만들어야한다.외부 객체가 데이터에 의존하지 않도록 만드는 가장 좋은 방법은 데이터를 결정하기 전에 먼저 행동부터 결정하는 것이다.
  • 데이터가 없는 상태에서 행동을 먼저 결정하면 외부에서는 데이터에 대해서는 알 수 없기 때문에 행동에 의존할 수밖에 없음

행동에 초점을 맞추는 설계 순서

1. 해당 객체가 외부에 어떤 행동을 제공할 지를 먼저 결정(데이터 고민 X) -> 메서드를 구현
2. 메서드를 구현하면서 필요하다고 판단된 데이터를 추가

메서드를 먼저 구현하고 필요하다고 판단된 데이터를 나중에 추가하면, 내부의 데이터가 변경되더라도 외부의 클라이언트가 영향을 받지 않게 되기 때문에 코드를 수정하기가 쉬워진다. 

객체의 행동을 먼저 구현하고 행동에 필요한 데이터를 나중에 선택하라

• 다른 객체의 요청을 처리하기 위해 필요한 행동을 먼저 결정하고, 행동에 적합한 객체를 나중에 선택하는 원칙
• 클래스를 고립시킨 상태에서 외부에 제공할 행동을 결정해서는 안된다.
  • 문맥을 고려하지 않고 데이터를 설계의 문제점이 발생한다.
• 객체의 행동은 고립된 상태가 아닌 다른 객체와의 협력이라는 문맥 안에서 결정되어야 한다.
  • 클라이언트의 요청을 먼저 결정하고, 이 요청을 처리할 객체를 나중에 선택해야한다.
  • 이처럼 행동을 먼저 결정하고 객체를 나중에 선택하는 방식으로 객체를 설계하면 변경에 유연하고 필요한 요소만 포함하는 클래스를 얻을 수 있다.
• 객체가 다른 객체에게 도움을 얻기 위해 요청하고 응답하는 과정을 협력이라고 부른다. 

객체가 다른 객체와 협력하려는 필요성이 설계를 위한 문맥을 제공하며, 객체지향 설계에서는 객체와 객체사이의 협력을 먼저 설계하고 그 후에 클래스의 내부 구조를 구현하는 순서로 진행해야한다 -> 협력에 필요한 행동을 먼저 결정하고 행도에 적합한 객체를 나중에 선택하면 , 객체 사이의 협력이 설계된다. 이처럼 객체들의 협력 관계를 기반으로 애플리케이션을 설계하는 방식을 책임 주도 설계라고 부른다.