객체 지향의 사실과 오해
객체 지향의 사실과 오해를 읽으면서 객체 지향이 무엇인가에 대해서 다시 생각해보는 좋은 계기가 됬던것 같다.
객체 지향이 단순히 모든것을 객체로 풀어냈고 객체간의 상호작용을 하는 과정이라고 생각 했다면 단순히 그 것을 뛰어넘어 객체지향적 프로그래밍에 대한 생각을 심도있게 다룬 책이었다.
Chapter 03
객체생성에 관한 내부적인 상황을 먼저 파악해야 한다.
객체의 행위 자체에 집중하고 행동자체에 집중하여 관계를 파악하고 객체를 정의 해야 한다.
객체생성의 중심은 “행위” , “동작” 을 중심으로 생성해야 한다.
Chapter 04
A객체와 B 객체의 협력위주 input, output을 생가가여 서로의 책임위주의 설계를 진행해야 한다.
OOP의 가장중요한 핵심은 충분히 자율적인 동시에 충분히 협력적인 객체를 창조하는 것이다. 이것이 바로 “책임주도 설계“ 를 의미한다.
책임을 여러 객체가 수행할 수 있다면 객체가 아는 핵심적 역할로 대체하고 클래스가 아닌 인터페이스로 설계해야 한다.
Chapter 05
책임주도 설계
객체의 행위결정이 객체 자체의 속성이 아니다.
책임주도 설계의 관점에서는 어떤 객체가 어떤 특성을 가지고 있다고 해서 반드시 그와 관련된 행위를 수행 할 것이라고 가정하지 않는다.
인터페이스와 구현의 분리 법칙
객체 외부에 노출되는 인터페이스와 객체 내부에 숨겨지는 구현을 명확하게 분리해서 고려해야 한다.
객체 설계의 핵심은 ”두 개의 분리된 요소로 분할 설계해야 한다“ 즉, 인터페이스와 구현의 분리 법칙을 의미한다.
구현 : 내부적인 캡슐화 부분
인터페이스 : 외부 객체간의 통신 부분
왜 이런 설계 방식을 지켜야 하는가?
소프트웨어는 항상 변경이된다. 어떤 객체의 수정이 다른 객체에 영향을 준다는 것은 모든 설계가 엮여 있다는 뜻이고 이것은 객체지향적 설계와는 거리가 멀다.
Chapter 06
기능 설계와 구조 설계
훌륭한 기능이 훌륭한 소프트웨어를 만드는 충분 조건이라면 훌륭한 구조는 훌륭한 소프트웨어를 만드는필요조건이다.
훌륭한 기능을 메세지라고 한다면 훌륭한 구조는 객체가 가지고 있는 행위다.
객체를 기반으로 책임과 역할을 식별한다.
메세지를 기반으로 객체들의 협력관계를 구현한다.
안정적인 객체는 구조 변경을 수용할 수 있는 유연한 소프트웨어다.
구조는 사용자나 이해관계자들이 도메인에 관해 생성하는 개념과 개념들 간의 관계이고 가능은 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행이로 표현할 수 있다.
안정적인 재료가 구조, 유즈 케이스, 도메인 모델링 과 같은 UML 기술이라면 불안정한 재료는 기능, 사용자와 사용자 간의 “상호작용”이라고 할 수 있다.
*유스케이스의 활용
유스케이스의 행위에는 특정 인터페이스에 대한 정보가 포함되면 안된다.
예를 들어서 B를 통해서 A를 실행한다 라는 표현은 B라는 인터페이스에 대한 정보를 드러내게 된다. 즉 A를 실행한다 와 같은 행위에 대한 정보만 포함하여 내부 설계에 대한 관련 정보를 제공하지 않아야 하며 유스케이스는 객체지향의 설계와 크게 연관되어있지 않다. 시스템을 통해 어떻게 상호작용 할 수 있는지를 표현할 수 만 있다면 괜찮다.
Chapter 07
설계하고 구현하기
협력을 설계할 때 객체가 메시지를 선택하는 것이 아니고 메시지가 객체를 선택 할 수 있도록 해야 한다.
행위를 중심으로 설계하도록 해야 한다.
하지만 협력을 구성하는 단계에서 너무 많은 시간을 보내는 것은 옳지 않다.
너무 많은 시간을 협력구성의 단계에서 소비하기 보다는 적당한 시기에 구현하고 설계의 이상이 있는지를 확인하는 것이 옳다.
실제로 상호작용을 해보지 않은채 인터페이스의 모습을 정확히 예측하는 것은 불가능에 가깝기 때문에 협력구성을 위해 너무 많은 시간을 낭비하는 것은 효율적인 과정이 아니다.