[오브젝트 2회독] 5장 - 책임 할당하기

• 데이터 중심의 문제는 객체에 상태에 초점을 맞추기 때문에, 변경등에 취약함
• 따라서 책임에 초점을 맞추도록 해야하지만, 실제로 어떤 객체에 책임을 할당하지 정하는게 쉽지 않음

→ 올바른 책임 할당을 위해 Grasp 패턴을 적용

1. 책임 주도 설계를 향해

데이터 중심에서 책임 주도 설계로의 전환을 위한 두가지 원칙

• 데이터 보다 행동을 먼저 결정
• 협력이라는 문맥 안에서 책임을 결정

데이터 보단 행동을 먼저 결정

• 객체에서 중요한 건 데이터가 아닌, 외부에 제공하는 행동(이것이 곧 “책임”)
• 객체가 수행할 책임을 먼저 결정하고, 필요한 데이터가 무엇인지 결정

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

• 책임의 품질은 협력에 적합한 정도로 결정
• 메세지 전송 클라이언트 의도에 적합한 책임을 할당
• 메세지 수신자에 대한 가정을 하지 않기 때문에, 수신자가 완벽하게 캡슐화 됨

2. 책임 할당을 위한 GRASP 패턴

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

• 책임 할당의 첫번째 원칙은 책임을 수행할 정보를 알고 있는 객체에게 책임 할당
• GRASP에서 INFORMATION EXPERT(정보 전문가) 패턴
  • 정보와 데이터는 다르기 때문에, 그 정보를 반드시 “저장”하는 객체가 아님

높은 응집도와 낮은 결합도

• GRASP에서 LOW COUPLING, HIGH COHESION

1. 높은 응집도

결국 변경의 책임이 한곳에 집중되는 것

• 낮은 응집도의 문제를 해결하기 위해서, 변경에 이유에 따라 클래스들을 분리하는게 좋음

A클래스 내에서 1,2,3 기능이 존재하고, 이들은 각각 독립적으로 사용된다면?
A클래스를 기반으로 한 1,2,3 타입의 분리를 생각해볼 수 있음! 반드시 그런건 X

• 응집도 판단 기준
  • 클래스가 하나 이상의 이유로 변경되어야 할 때(이땐, 변경 기준으로 클래스 분리)
  • 인스턴스 초기화 시점에 서로 다른 속성들을 초기화 할 때(초기화 속성들의 그룹을 기준으로 분리)
  • 각 메서드가 instance 변수들을 사용하는 지 여부(이를 가시적으로 나타내기 위해 Swift에서는 self 키워드를 사용할 수 있음)

1. 낮은 결합도

결국 최소한의 의존성을 갖고, 독립적으로 변경할 수 있는 것을 의미

다형성을 통해 분리

• GRASP에서는 POLYMORPHISM 이라고 함
• 기존 객체가 하나의 클래스를 통해 협력하다가, 다양한 타입이 나왔을 때?
• 다형성을 통해서 타입들과 협력이 가능함
• 기존 객체의 입장에서는 타입은 많아져도 같은 역할을 하는 집합들이기에 이전과 차이가 없음

변경으로부터 보호

• GRASP에서는 PROTECTED VARIATIONS(변경 보호) 라고 함
• 새로운 타입을 추가할 때마다, 기존 코드의 변경이 있어서는 안됨
• 이를 위해서, 타입을 캡슐화 하여 새로운 타입이 추가되더라도 기존 객체에 영향을 미치지 않음

결론

• GRASP 패턴이라고 하였지만 결국 SOLID 원칙이 떠오르는 순간(SRP, OCP)
• 객체 지향 프로그래밍에서 중요한 건 협력에 관점에서 책임을 명확히 규정하고, 가능한 높은 응집도와 낮은 결합도를 가진 코드를 만드는 것(”가능한” 이라는 키워드를 붙인 이유는 응집도와 결합도를 위한 복잡도가 너무 커진다면, 다른 사람이 이해하기 어렵기 때문)
• 높은 응집도를 위해 특정 객체에서 타입을 분리할 수 있으며, 다형성 을 활용
• 타입을 새롭게 추가한다고 해서, 기존 객체에 영향을 주어선 안된다(OCP)