오브젝트 01 ~ 04

00 - 공통

연극 - 배우 - 배역

협력 - 역할 - 객체

설계란 코드를 배치하는 것이다.

 

 

 

01 - 객체

책임의 이동이 중요하다.

책임을 올바른 위치에 놓는 것만으로도 개선이 가능하다.

자신의 데이터를 스스로 처리하는 자율적인 객체를 만들어야 결합도를 낮추고 응집도를 높일 수 있다. [26p]

외부 간섭을 배제하고 메세지를 통해서만 협력하는 자율 객체를 만들어야한다. [26p]

 

절차 지향 => 객체가 소극적인 존재

객체 지향 => 객체가 적극적인 존재

 

객체를 적극적인 존재로 만드는 법

1. 외부간섭을 줄인다.
2. 메세지를 통해서만 협력한다.

 

사설) 스프링을 사용하다보니 비즈니스 로직이라는 이유로 모든 책임이 서비스 컴포넌트로 집중이되는데, 객체 지향이라는 관점에서는 좋은 설계는 아닌 듯 싶다. 

 

 

 

02 - 객체 지향 프로그래밍

객체란 상태와 행동을 가지는 복합적인 존재다.

객체란 스스로 판단하고 행동하는 자율적인 객체다.

 

메시지란 다른 객체와 상호 작용 할 수 있는 인터페이스다.

메서드란 메시지를 처리하기 위한 자신만의 방법이다. [49p]

 

다형성을 이용하면 코드의 의존성과 실행 시점의 의존성을 달리할 수 있다. [59p]

장점 : 이를 이용하면 코드를 유연하게 하는데 도와준다.

단점 : 이를 이용하면 코드를 이해하는데는 어려워진다.

설계가 유연해질수록 재사용성은 올라가지만 코드를 이해하고 디버깅에는 어려워진다. 이는 트레이드 오프 관계다.

 

다형성을 구현하는 방법은 매우 다양하지만 메시지 응답을 위한 메서드가 컴파일 시점이 아닌 런타임 시점에 결정되게한다는 공통점이 있다.

이를 지연 바인딩, 동적 바인딩 이라고 한다. [63p]

즉 다형성은 지연 바인딩을 하게 해준다.

 

다형성 관점에서 자신과 협력하는 객체가 어떤 클래스의 인스턴스인지는 중요하지 않다.

메세지를 던질수 있고 객체가 이를 수신할 수 있다는 것이 중요하다. [61p]

 

상속은 클래스를 통해 강하게 결합되는데 비해 합성은 메세지를 이용하므로 더 느슨하게 결합된다.

따라서 재사용이라는 측면에서 본다면 상속보다는 합성이 더 좋은 방법이다. [72p]

 

 

 

03 - 역할, 책임, 협력

객체 지향 원칙을 따르는 어플리케이션의 제어흐름은 어떤 하나의 객체에 통제되지 않고 다양하 객체들 사이에 균형있게 분배되는 것이 일반적이다. [74p]

객체가 협력에 참여할 수 있는 이유는 협력에 필요한 적절한 행동을 보유하고 있기 때문이다. [76p] 

객체 지향 개발에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어에 할당 하는 것 [79p]

 

책임 할당이 중요하다.

책임을 수행할 객체를 찾아 할당하는 방식으로 협력을 설계하는 방법을 책임 주도 설계라고 한다. [83p]

객체 지향 입문자들이 가자 쉽게 빠지는 실수는 객체를 행동이 아닌 상태에 초점을 맞추는 것이고, 이를 데이터 주도 설계라고 한다. [85p]

 

협력은 역할들의 상호 작용으로 구성된다.

협력을 구상하기 위해 역할에 적합합 객체가 선택된다.

객체는 클래스를 이용해서 구현된다. [91p]

 

의역 [95p]

• 서로 다른 객체들은 동일한 역할을 수행할 수 있다.
• 하나의 객체는 다양한 협력에서 서로 다른 역할을 수행할 수 있다.

 

 

 

04 - 설계 품질과 트레이드 오프

객체란 책임의 집합이다.

객체의 상태가 아니라 객체의 행동에 초점을 맞추면 응집도를 합리적으로 낮출 수 있다.

객체를 단순 데이터 집합으로 바라보면 객체의 내부 구현을 외부에 노출시키고 결과적으로 설계가 변경에 취약해진다. [97p]

 

객체 지향 설계의 가장 중요한 원리는 불안정한 구현 세부사항을 안정적인 인터페이스 뒤로 캡슐화 하는 것이다. [109p]

유지 보수성이란 두려움 없이, 주저 없이, 저항감 없이 코드를 변경할 수 있는 능력을 말한다. [109p]

 

낮은 응집도의 문제점 [116p]

1. 변경이 가해질 때 변경과 아무 상관 없는 노드들이 영향 받게된다.
2. 책임의 위치가 잘못된 곳에 할당된다. switch, if 문이 반복해서 나오고 새로운 조건이 추가되면 새로운 분기를 또 처리해야한다.

 

사설) getter setter 를 남발하지말라 => 수동적인 객체를 만드는 주범이다.

사설) 메소드의 이름으로 데이터가 유추된다면 캡슐화가 깨졌다는 것이다..

 

데이터 중심 설계는 객체에 필요한 데이터가 무엇인가에 초점을 맞추게된다.

데이터는 구현의 일부다. 그러므로 안좋은 설계가 나오게된다. [131p]

getter / setter 는 캡슐화를 망가뜨린다.

협력이라는 문맥에서 필요한 책임을 결정하고 이를 수행할 적절한 객체를 결정하는 것이 중요하다.

올바른 객체 지향 설계의 무게 중심은 객체 내부가 아니라 외부에 맞춰져 있어야한다.[132p]