[BOOK : 오브젝트 4장] 설계 품질과 트레이드 오프

뭐했다고 4장...

이번 주 스터디에서의 목표는 3,4장을 읽는 것이 목표였다.

 

 

주말에 시간이 많이 남아 그동안 못읽었던 책들이나 내용을 공부하는 편인데, 다음 주는... 생일이나 다른 일정들이 있기 때문에 미리 평일에 조금씩 해둬야겠다.. 

 

서론은 이쯤하고 본질적인 내용을 들어가 보도록 하자 

 

내가 생각한 이 챕터의 핵심 

• 데이터 중심적인 설계는 지향하세요! 
• 객체지향중 제일 중요한 건 책임입니다. 캡슐화 x 100 

해당 챕터에서는 3장에 내용이 이어졌었고, 해당 챕터를 읽을수록 캡슐화의 중요성과 데이터 중심적인 설계는 하지 말아라라는 게 핵심으로 보였다. 

 

데이터 중심의 영화 예매 시스템 

객체 지향 설계에서는 두가지의 방법을 이용해 시스템을 객체로 분할하는 것이 가능하다. 

• 상태 ( 데이터 )를 분할의 중심축으로 삼는 방법 
• 책임을 분할의 중심으로 삼는 방법 

데이터 중심의 관점

• 객체는 자신이 포함하고 있는 데이터를 조작하는데 필요한 오퍼레이션을 정의한다. 
• 객체의 상태에 초점을 맞춘다.

책임 중심의 관점 

• 객체는 다른 객체가 요청할 수 있는 오퍼레이션을 위해 필요한 상태를 보관한다.
• 객체의 행동에 초점을 맞춘다. 

핵심 

• 훌륭한 객체지향 설계는 데이터가 아닌 책임에 초점을 맞춰야한다. 
  • 객체의 상태는 구현에 속한다. 구현은 불안정하기 때문에 변하기 쉽고 상태를 객체 분할의 중심축으로 삼으면 구현에 관한 세부사항이 객체의 인터페이스에 스며들게 되어 캡슐화의 원칙이 무너지게 된다.
• 객체의 책임은 인터페이스에 속한다. 
  • 객체는 책임을 드러내는 안정적인 인터페이스 뒤로 책임을 수행하는 데 필요한 상태를 캡슐화함으로써 구현 변경에 대한 파장이 외부로 퍼져나가는 것을 방지한다.

 

다음 예제를 살펴보자 

 

위 설계는 데이터를 중심적으로 설계함을 눈으로 보아도 알 수 있다. 

 

그렇다면 왜 데이터 중심적으로 설계하는것이 안 좋을까?

 

데이터 중심의 영화 예매 시스템의 문제점 

• 캡슐화 위반 
• 높은 결합도
• 낮은 응집력 

 

데이터 중심의 설계는 캡슐화를 위반하고 객체의 내부 구현을 인터페이스의 일부로 만든다.

 

반면 책임 중심의 설계는 객체의 내부 구현을 안정적인 인터페이스 뒤로 캡슐화한다.

 

SOLID 중 단일 책임 원칙(Single Reponsibility Principle, SRP)에 대해 기억하는가?

 

해당 책에서는 해당 개념에 대해 다시 한번 짚어 설명하고 있었다. 

 

로버트 마틴 : 단일 책임 원칙(Single Responsibility Principle, SRP)

• 클래스는 단 한 가지의 변경 이유만 가져야 한다. 
• 단일 책임 원칙이라는 맥락에서 '책임'이라는 말이 '변경의 이유'라는 의미로 사용된다는 점
• 책임은 지금까지 역할, 책임, 협력에서의 책임과는 다르며 변경과 관련된 더 큰 개념을 가리킨다.

 

데이터 중심 설계는 객체의 행동보다는 상태에 초점을 맞추게 된다. 

• 데이터 중심 설계의 첫 질문은 "이 객체가 포함해야 하는 데이터가 무엇인가?"
• 데이터 주도 설계는 설계를 시작하는 단계부터 데이터에 관해 결정하도록 강요하기 때문에 너무 이른 시기에 내부 구현에 초점을 맞추게 한다
• 객체의 내부 구현이 객체의 인터페이스를 어지럽히고 캡슐화 실패로 응징도와 결합도에 나쁜 영향을 미치기 때문에 변경에 취약한 코드를 낳게 된다.

데이터 중심 설계는 객체를 고립시킨 채 오퍼레이션을 정의하도록 만든다.

• 객체지향 애플리케이션을 구현한다는 것은 협력하는 객체들의 공동체를 구축한다는 것이다
• 올바른 객체지향 설계의 무게 중심은 항상 객체의 내부가 아니라 외부에 맞춰져 있어야 한다.
•  데이터 중심 설계의 초점은 객체의 내부로 향한다. 
• 객체의 구현이 이미 결정된 상태에서 다른 객체와의 협력 방법을 고민하기 때문에 이미 구현된 객체의 인터페이스를 억지로 끼워 맞출 수밖에 없다.

그럼 응집도와 결합도가 뭔데? 

응집도

• 모듈에 포함된 내부 요소들이 연관돼 있는 정도를 나타낸다.
• 모듈 내의 요소들이 하나의 목적을 위해 긴밀하게 협력한다면 그 모듈은 높은 응집도를 가진다.

결합도

• 의존성의 정도를 나타낸다.
• 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타내는 척도이다.

변경과 응집도

위 그림을 살펴보면 하나의 특징을 가짐을 알 수 있다. 

• 변경의 대상과 범위가 명확해지기 때문에, 코드를 변경하기 쉬워진다. 

변경과 결합도

위 그림을 보았을 때 어떤 생각이 들었는가? 

 

해당 그림만 보더라도 확연하게 보이는 건 다음과 아마 같을 것이다.

• 결합도가 높을 때 하나의 모듈을 변경하였을 때 나머지 4개의 모듈까지 다 변경해줘야 한다. 

결론 

• 높은 결합도를 가지기보단 하나의 객체의 높은 응집력을 가지는 게 좋다.
• 이전부터 캡슐화의 중요성을 이야기하고 있는데, 책임 = 캡슐화 고로 캡슐화를 중요하게! 
• 최대한 결합을 느슨하게 
• 데이터 중심적인 설계 방법은 절차 지향으로 진행된다. 고로, 조심해야 한다.