오브젝트: 코드로 이해하는 객체지향 설계 5장을 읽으며

오브젝트: 코드로 이해하는 객체지향 설계 5장을 읽으며

 

느낀점

영화 설계를 바꾸는 모습을 보면서 어떻게 설계하는지에 대해서 생각을 많이 함. 재사용 되지 않는 메서드를 분리하면 시선이 분산되는 느낌이라 특정 메서드는 주석을 통해 전개하는데 몬스터 메서드라는 개념을 보면서 새로운 시각에 대해서 생각하게 됨.
 

책임 할당하기

문맥을 벗어나 고립된 객체의 상태에 초점을 맞추기 때문에 캡슐화를 위반하기 쉽고 요소들 사이의 결합도가 높아짐. 다양한 객체 할당 방법이 존재하고 어떤 방법이 최선인지는 상황과 문맥에 따라 달라짐
 

데이터보다 행동을 먼저 결정하라

객체에게 중요한 것은 데이터가 아니라 외부에 제공하는 행동. 객체지향 설계에서 가장 중요한 것은 적절한 객체에게 적절한 책임을 할당하는 능력
 

협력이라는 문맥 안에서 책임을 결정하라

메시지를 결정한 후에 객체를 선택. 메시지를 전송하는 클라이언트의 의도에 적합한 책임을 할당.

• 클라이언트는 단지 임의의 객체가 메시지를 수신할 것이라는 사실을 믿고 자신의 의도를 표현한 메시지를 전송할 뿐.

 

책임 주도 설계

핵심은 책임을 수행할 객체를 결정한 후 수행할 객체를 결정하는 것
 

도메인 개념에서 출발하기

설계 시작 전 도메인을 대한 개략적인 모습을 그려 보는 것이 유용. 도메인 개념을 완벽하게 정리하는 것이 아님. 빠르게 설계와 구현을 진행

• 올바른 도메인 모델이란 존재하지 않음.
• 도메인 모델은 구현과는 무관하다고 생각하나, 도메인 모델의 개념을 오해한 것에 불과
• 도메인 모델이 구현을 염두에 두고 구조화되는 것이 바람직하는 것을 의미
• 도메인 모델의 구조가 코드의 구조에 영향을 미치기 때문이며, 유연성이나 재사용성 등과 같이 실제 코드를 구현하면서 얻게 되는 통찰력으로 도메인에 대한 개념을 바꾸기 때문.

 

정보 전문가에게 책임을 할당

애플리케이션이 제공해야 하는 기능을 애플리케이션의 책임으로 생각하는 것

• 객체가 상태와 행동을 통합한 캡슐화의 단위라는 사실에 집중
• 상태는 동일한 객체 안에 존재해야 함.
• 객체에게 책임을 할당하는 첫번째 원칙을 수행할 정보를 알고 있는 객체에게 책임을 할당하는 것

높은 응집도와 낮은 결합도

몇 가지 설계 중에서 한 가지를 선택해야 하는 경우가 빈번하게 발생.

• 책임을 할당할 때 항상 고려해야 하는 기본 원리
• 높은 응집도와 낮은 결합도를 얻을 수 있는 설계가 있다면 그 설계를 선택해야 한다는 것
• Low Coupling(낮은 결합도)
  • 의존성을 낮추고 변화의 영향을 줄이며 재사용성 증가.
• High Cohension(높은 응집도)
  • 어떻게 복잡성을 관리할 수 있는 수준으로 유지할 것인지.

 

창조자에게 객체 생성 책임을 할당하라

GRASP의 CREATOR(창조자) 패턴을 통해 책임 할당 패턴으로써 객체를 생성할 책임을 어떤 객체에게 할당할지에 대한 지침 제공

• 변경의 이유에 따라 클래스를 분리
• 인스턴스 변수가 초기화되는 시점
  • 객체의 속성 중 일부만 초기화하고 일부는 초기화되지 않은 상태로 남겨짐
  • 서로 다른 시점에 초기화되거나 일부만 초기화 되는건 응집도가 낮다는 증거. 함께 초기화되는 속성을 기준으로 코드를 분리해야 함.
• 메서드들이 인스턴스 변수를 사용하는 방식을 살펴보기
  • 모든 메서드가 객체의 모든 속성을 사용한다면 클래스의 응집도는 높다고 볼 수 있다.

 

다형성을 통해 분리하기

동일 책임을 수행한다는 것은 동일한 역할을 수행하는 것을 의미

• 자바에서는 추상 클래스나 인터페이스를 사용
• 역할을 대체하는 객체들의 책임만 정의하고 싶다면 인터페이스를 사용.
• POLYMORPHISM(다형성) 패턴
  • 조건에 따른 변화는 if - else 또는 switch - case 등의 조건 논리를 사용해서 설계한다면 새로운 변화가 일어난 경우 조건 논리를 수정
  • 이것은 프로그램을 수정하기 어렵고 변경에 취약하게 만듦.
  • 다형성 패턴은 객체의 타입을 검사해서 타입에 따라 여러 대안들을 수행하는 조건적인 논리를 사용하지 말라고 경고하고, 다형성을 이용해 새로운 변화를 다루기 쉽게 확장

 

변경으로부터 보호하기

변경을 캡슐화하도록 책임을 할당하는 것을 변경 보호 패턴

• 객체에게 중요한 것은 상태가 아니라 행동.
• 도메인의 구조가 코드의 구조를 이끔
  • 변경 역시 도메인 모델의 일부라는 것.
  • 도메인에 대한 직관이 우리의 설계가 가져야 하는 유연성을 이끎.

변경과 유연성

설계를 주도하는 것은 변경

• 코드를 이해하기 쉽고 수정하기 쉽도록 최대한 단순하게 설계
• 수정하지 않고도 변경을 수용할 수 있도록 유연하게 만드는 것.
• 상속대신에 합성을 활용할 것

 

메서드 응집도

메서드가 너무 길고 이해하기 어려움.

• 어렵고 재사용하기도 어려우며 변경하기도 어려움. 이런 메서드라고 함.
• 메서드가 명령문들의 그룹으로 구성되고 각 그룹에 주석을 달아야 할 필요가 있다면 그 메서드의응집도는 낮은 것.