객체지향의 사실과 오해

http://aeternum.egloos.com/

객체지향으로 향하는 첫 걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작함.
두번째 걸음은, 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 존재로 바라보는 것.

협력하는 객체들의 공동체

아쉽게도 실세계의 모방이라는 개념은 철학을 설명하는데 적합하지만, 유연하고 실용적인 관점에서 객체지향 분석 설계를 설명하기에는 적합하지 않다.
심지어 소프트웨어가 반영해야 하는 객관적인 실세계가 존재한다는 아이디어조차도 논란의 여지가 있는 철학적 근거를 기반으로 한다.

소프트웨어 개발자의 역활은 단순히 실세계를 소프트웨어 안으로 옮겨 담는 것이 아니라 고객과 사용자를 만족시킬 수 있는 신세계를 창조하는 것이다.

"소프트웨어 시스템이 해결하려고 하는 실제는 잘해봐야 먼 친척밖에는 되지 않는다"

협력하는 사람들

역활이라는 단어는 '책임'이라는 의미를 내포한다

사람들이 협력을 위해 특정한 역활을 맡고 역할에 적합한 책임을 수행한다는 사실은 몇 가지 중요한 개념을 제시한다.
* 여러 사람이 동일한 역할을 수행할 수 있다
* 역할은 대체 가능성을의미한다
* 책임을 수행하는 방법은 자율적으로 선택할 수 있다
* 한 사람이 동시에 여러 역할을 수행할 수 있다

역할, 책임, 협력

객체의 세계는 인간의 세계와 유사하다.
"어떤 객체도 섬이 아니다"

객체지향 설계라는 예술은 적절한 객체에게 적절한 책임을 할당하는 것에서 시작된다.
역할은 유연하고 재사용 가능한 협력관계를 구축하는데 중요한 설계요소다.

객체 공동체에 속한 객체들은 공동의 목표를 달성하기 위해 협력에 참여하지만 스스로의 결정과 판단에 따라 행동하는 자율적인 존재다.

상태와 행동을 함께 지닌 자율적인 존재

과거의 전통적인 개발 방법은 데이터와 프로세스를 엄격하게 구분한다. 이에 반해 객체지향에서는 데이터와 프로세스를 하나의 틀 안에 함께 묶어 놓음으로써 객체의 자율성을 보장한다.

메서드와 자율성

외부의 요청이 무엇인지를 표현하는 메세지와 요청을 처리하기 위한 구체적인 방법인 메서드를 분리하는것은 객체의 자율성을 높이는 핵심 메커니즘이다. 이것은 캡슐화라는 개념과도 깊은 관련이 있다.

객체 지향의 본질 : 첫번째 도시전설

어떤 객체지향 프로그래밍 언어를이야기할 때 대부분의 사람들은 클래스를 정의하는 방법과 클래스 사이의 상속에 초점을 맞춘다.

훌륭한 객체지향 설계자가 되기 위해 거쳐야 할 첫번째 도전은 코드를 담는 클래스의 관점에서 메세지를 주고받는 객체의 관점으로 사고의 중심을 전환하는 것이다.

클래스는 객체들의 협력 관계를 코드로 옮기는 도구에 불과하다. 클래스는 객체지향 세계의 도시전설이다.

클래스를 쓰지않고 객체지향? 아니지 클래스위주로 생각하지 말라는거니까. 음

이상한 나라의 객체

객체지향 페러다임은 지식을 추상화하고 추상화한 지식을 객체안에 캡슐화함으로써 실세계 문제에 내재된 복잡성을 관리하려고 한다. 객체를 발견하고 창조하는 것은 지식과 행동을 구조화하는 문제다. - 레베카 워프스브록

객체란 인간이 분명하게 인지하고 구별할 수 있는 물리적인 또는 개념적인 경계를 지닌 어떤 것이다.

아기도 객체를 인지한다고 한다
객체지향을 배울때는 유사해 보이지만 실제와 객체세계를 비교하면 이질적이다.
주문은 사람이 하지만 객체세계에서 주문은 주문객체가 한다.

앨리스 객체

앨리스는 상태를 가지며 상태는 변경가능하다.
앨리스의 상태를 변경시키는 것은 앨리스이 행동이다.

• 행동의 결과는 상태에 의존적이며 상태를 이용해 서술할 수 있다.
• 행동의 순서가 결과에 영향을 미친다

앨리스는 어떤 상태에 있더라도 유일하게 식별 가능하다.

객체요소: 식별(identity), 상태(status), 행동(behavior)

상태

객체가 주변 환경과 상호작용에 어떻게 반응하는가는 그 시점까지 객체에 어떤일이 발생했느냐에 좌우된다.
객체

• 앨리스
• 토끼
• 음료
• 케이크
• 부채
• 버섯

---

프로퍼티 (참/거짓 같은 단순한 값들은 객체가 아니다. 독립적 의미보다 객체의 상태를 표현하기 위해 사용된다)

• 속도
• 키
• 위치

property, attribute가 헷갈린다

property는 attribute와 link(연관관계의 인스턴스)이다

---

자율적인 객체는 스스로 자신의 상태를 책임져야 한다.
객체지향의 기본 사상은 상태와 상태를 조작하기 위한 행동을 하나의 단위로 묶는 것임. 객체는 스스로의 행동에 의해서만 상태가 변경되는 것을 보장함으로써 객체의 자율성을 유지한다.

행동

상태와 행동 사이의 관계

• 객체의 행동은 상태에 영향을 받는다 (상호작용이 현재의 상태에 어떤 방식으로 의존하는가)
• 객체의 행동은 상태를 변경시킨다 (상호작용이 어떻게 현재의 상태를 변경시키는가)

---

어떤 객체도 섬이 아니다. 객체는 자신에게 주어진 책임을 완수하기 위해 다른 객체를 이용하고 다른 객체에게 서비스를 제공한다.

• 객체 자신의 상태변경
• 행동 내에서 협력하는 다른 객체에 대한 메시지 전송

---

행동

외부의 요청 또는 수신된 메시지에 응답하기 위해 동작하고 반응하는 활동이다. 행동의 결과로 객체는 자신의 상태를 변경하거나 다른 객체에게 메시지를 전달할 수 있다. 객체는 행동을 통해 다른 객체와 협력에 참여하므로 행동은 외부에 가시적이어야 한다.

---

상태를 외부에 노출시키지 않고 행동을 경계로 캡슐화하는 것은 결과적으로 객체의 자율성을 높인다. 자율적인 객체는 스스로 판단하고 스스로 결정하기 때문에 객체의 자율성이 높아질수록 객체의 지능도 높아진다. 협력에 참여하는 객체들의 지능이 높아질수록 협력은 유연하고 간결해진다. 이것이 상태를 캡슐화 하는 이유다.

식별자

객체는 식별자를 가지고 값은 식별자를 가지지 않는다. 시스템을 설계할 때는 이런 단순한 값과 객체의 차이점을 명확하게 구분하고 명시적으로 표현하는 것이 매우 중요하다.

값(value)은 숫자, 문자열 등과 같이 변하지 않는 양을 모델링 한다. 흔히 값의 상태는 변하지 않기 때문에 불변 상태(immutable state)를 가진다고 말한다.

값은 액션이 없기때문에 불변이라고 하는듯, 예를들면 1이 1스스로 2로 변한다는 것 같은

불변하기 때문에 A, B 두 값이 같다면 동등성(equality)를 가진다고 한다.

---

객체는 시간에 따라 변경되는 상태를 포함하며, 행동을 통해 상태를 변경한다(mutable state).

객체는 식별자로 A, B가 같은지 판단하며 이를 동일성(identical)이라고 한다.

상태를 기반으로 객체의 동일성을 판단 할 수 없는 이유는 시간이 흐름에 따라 객체의 상태가 변하기 때문이다.

행동이 상태를 결정한다

인터페이스가 프로퍼티 결정보다 선행되야하는 이유를 말하는 듯

객체지향에 갓 입문한 사람들이 가장 쉽게 빠지는 함정은 상태를 중심으로 객체를 바라보는 것이다. 초보자들은 먼저 객체에 필요한 사태가 무엇인지를 결정하고 그 상태에 필요한 행동을 결정한다.

상태를 먼저 결정할 경우

• 캡슐화가 저해된다. 상태에 초점을 맞추면 상태가 공용 인터페이스에 그대로 노출되어버릴 확율이 높아진다.
• 객체를 협력자가 아닌 고립된 섬으로 만든다. 협력이라는 문맥에서 벗어난다.
• 객체의 재사용성이 저하된다. 상태에 초점을 맞추면 다양한 협력에 참여하기 어렵다.

행동을 결정한 후에야 행동에 필요한 정보가 무엇인지를 고려하게 되며 이 과정에서 필요한 상태가 결정된다. 따라서 먼저 객체의 행동을 결정하고 그 후에 행동에 적절한 상태를 선택하게 된다.

은유와 객체

객체지향이란 현실 세계의 모방: 두번째 도시전설

흔히 객체지향을 현실의 추상화라고 하는데, 그 안에는 현실 세계를 모방해서 단순화한다는 의미가 숨어있다. 여기서 추상화(abstraction)란 실제의 사물에서 자신이 원하는 특성만 취하고 필요없는 부분을 추려 핵심만 표현하는 행위를 말한다. 이런 관점에서 현실세계를 면밀히 관찰하고 그 안에 존재하는 실제 객체들의 특징을 간추리고 요약해서 소프트웨어 객체로 추상화할 수 있는 능력이 중요하다는 생각이 자리잡고 있다.

그러나 안타갑게도 객체지향 세계는 현실 세계의 단순한 모방이 아니다. 소프트웨어의 상품은 실제 세계의 상품이 하지 못하는 가격 계산과 같은행동을 스스로 수행할 수 있다. 이것은 소프트웨어 상품이 실제 세계의 상품을 단순화하거나 추상화한 것이 아니라 특성이 전혀 다른 어떤 것임을 의미한다.

의인화(anthropomorphism)

실제 세계와 객체지향의 가장 큰 차이점은 현실에서는 수동적인 개념이 객체지향에서는 능동적으로 변한다는 것이다.

소프트 웨어객체가 현실 객체의 부분적인 특징을 모방하는 것이 아니라 현실 객체가 가지지 못한 추가적인 능력을 보유하게 된다.

소프트웨어 안에 구축되는 객체지향 세계는 현실을 모방한 것이 아니다. 현실 모습을 조금 참조할 뿐 궁극적인 목적은 현실과 전혀 다른 새로운 세계를 창조하는 것이다. 또한 객체지향의 세계는 현실의 추상화가 아니다. 오히려 객체지향 세계의 거리는 현실 속의 객체보다 더 많은 특징과 능력을 보유한 객체들로 넘쳐난다.

은유(metaphor)

전통적인 객체지향 조언은 현실 세계의 객체를 자세히 관찰하고 그중에서 소프트웨어 객체에 적합한 속성만 추려내라는 것이다. 안타깝게도 이 조언은 소프트웨어를 개발하는 데 실제적인 도움을 주지 못한다. 오히려 객체지향 애플리케이션이 현실의 구조를 정확하게 반영해야 한다는 오해만 심어줄 뿐이다.

정확한 관계는 은유라고 볼 수 있다. 따라서 소프트웨어 객체에 대한 현실 객체의 은유를 효과적으로 사용할 경우 표현적 차이를 줄일 수 있으며, 이해하기 쉽고 유지보수가 용이한 소프트웨어를 만들 수 있다.

아... 이게 제일 중요한데 왜 이해가 안되지 이상한 나라에서 토끼는 빠르게 달릴수 있다는 것을 예상할 수 있다. 이건 작가가 현실속의 객체를 바탕으로 은유를 통해 이상한 나라의 객체를 묘사하고 있기 때문이다. 작가가 토끼를 추상화 한것이 아니다. 은유한것. 때문에 실제 세계와 동일한 토끼가 아닌 작가의 글속의 토끼로 재탄생 되었다.

이상한 나라를 창조하라

객체지향 설계자로서 우리의 목적은 현실을 모방하는 것이 아니다. 단지 이상한 나라를 창조하기만 하면 된다. 현실을 닮아야 한다는 어떤 제약이나 구속도 없다. 창조한 객체의 특성을 상기시킬 수 있다면 현실 속의 객체의 이름을 이용해 객체를 묘사하라. 그렇지 않다면 깔끔하게 현실을 무시하고 자유롭게 새로운 세계를 창조하면 됨.

타입과 추상화

일단 컴퓨터를 조작하는 것이 추상화를 구축하고, 조작하고, 추론하는 것에 관한 모든것이라는 것을 깨닫고 나면 (훌륭한) 컴퓨터 프로그램을 작성하기 위한 중요한 전제 조건은 추상화를 정확하게 다루는 능력이라는 것이 명확해진다. - 키스 테블린(Keith Devlin)

추상화를 통한 복잡성 극복

진정한 의미에서 추상화란 현실에서 출발하되 불필요한 부분을 도려내가면서 사물의 놀라운 본질을 드러나게 하는 과정이라고 할 수 있다. - Root Bernstein

추상화는 복잡한 현실을 단순화하기 위해 사용하는 인간의 가장 기본적인 인지 수단이라고 할 수 있다.

현상은 복잡하다. 법칙은 단순하다. 버릴 게 무엇인지 알아내라 - 리처드 파이만

복잡성을 다루기 위해 추상화는 두 차원에서 이뤄진다 - Kramer

• 첫 번째 차원은 구체적인 사물들 간의 공통점은 취하고 차이점은 버리는 일반화를 통해 단순하게 만드는 것
• 두 번째 차원은 중요한 부분을 강조하기 위해 불필요한 세부사항을 제거함으로써 단순하게 만드는 것

객체 지향과 추상화

기껏해야 트럼프에 불과해
이처럼 공통점을 기반으로 객체들을 묶기 위한 그릇을 개념(concept)이라고 한다. 개념이란 일반적으로 우리가 인식하고 있는 다양한 사물이나 객체에 적용할 수 있는 아이디어나 관념을 뜻한다.

일반적으로 객체의 분류 장치로서 개념을 이야기할 때는 아래의 세가지 관점을 함께 언급한다 - Martin, Larman

• 심볼(symbol) : 개념을 가리키는 간략한 이름이나 명칭 (트럼프)
• 내연(intension) : 개념의 완전한 정의를 나타내며 내연의 의미를 이용해 객체가 개념에 속하는지 여부를 확인 할 수 있다. (몸이 납짝하고.. 트럼트 특징)
• 외연(extension) : 개념에 속하는 모든 객체들의 집합(set)

---

분류는 객체지향의 가장 중요한 개념이다. 어떤 객체를 어떤 개념으로 분류할지가 객체지향의 품질을 결정한다.

타입

타입은 개념과 동일하다. 따라서 타입이란 우리가 인식하고 있는 다양한 사물이나 객체에 적용할 수 있는 아이디어나 관념을 의미한다. 어떤 객체에 타입을 적용할 수 있을 때 그 객체를 타입의 인스턴스라고 한다. 타입의 인스턴스는 타입을 구성하는 외연의 객체 집합의 일원이 된다.

---

우리는 객체를 일종의 데이터처럼 사용한다. 따라서 객체를 타입에 따라 분류하고 그 타입에 이름을 붙이는 것은 결국 프로그램에서 사용할 새로운 데이터 타입을 선언하는 것과 같다.

프로그래밍에서 객체지향을 적용할때 그 타입은(프로그래밍) 데이터가 아니라 행동에 의해 결정된다. 흔히 캡슐화라고 하는것은 이처럼 행동위주의 타입설계와 타입선정에서 배제되는 데이터는 행동뒤로 숨기기 위함이다. 데이터가 캡슐화를 뚥고 밖으로 나온다면 인터페이스가 오염되며 분류체계는 위험에 노출되고 유연하지 못하게 된다.

타입의 계층

타입을 계층으로 나눌때 예를들면 abstract(super type) 과 상속받는 class(sub type), 이 처럼 분류하기 위해서는 일반화와 특수화 과정이 필요하고 행동을 일반화 된것이 abstract 특수화 된것이 상속받는 class라고 볼수있다.

정적 모델

객체는 시간이 지남에 따라 상태가 변한다. 이것을 추적하며 상태를 계산한다면 힘들것... 이다. 여기에 객체를 타입형태로 추상화 하고 타입을 시간에 무관한 불변한 모습으로 생각한다면 복잡성을 줄일 수 있다.

---

다시 도시전설을 언급하지만 class가 타입은 아니다. class 는 단지 타입을 구현할 수 있는 메커니즘 중 하나일 뿐.

역할, 책임, 협력

경제학적으로 사람은 자기에게 가장 유리한 결정을 한다고 한다. 하지만 실험적으로 꼭 그런것만은 아니며 제안자와 수락자 사이의 협력관계에 따라 결정이 달라진다.

객체의 세계에서도 협력이라는 문맥이 객체의 행동 방식을 결정한다. 초보자는 협력이라는 문맥을 고려하지 않은 채 객체가 가져야할 상태와 행동부터 고민하기 시작한다.

어떤 협력에 참여하는지가 객체에 필요한 행동을 결정하고, 필요한 행동이 객체의 상태를 결정한다.

협력

재판을 협력의 예로 들었다.

책임

객체지향 개발에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어 객체에 할당하는 것 - Larman
책임을 어떻게 구현할 것인가 하는 문제는 객체와 책임이 제자리를 잡은 후에 고려해도 늦지 않다.

책임이란

• 객체가 알아야 하는 정보와 객체가 수행할 수 있는 행위에 대한 개략적으로 서술한 문장이다.
• 무었을 알고 있는가와 무엇을 할 수 있는가로 구성되다.
• 객체지향 설계의 품질을 결정하는 가장 중요한 요소이다.
• 초반에는 어떤 객체가 어떤 책임을 가지고 어떤 방식으로 서로 협력해야하는지에 대한 개요를 아는것안으로도 충분하다.

역활

책임의 집합이 의미하는 것 재사용 가능하고 유연한 객체지향 설계를 낳는 매우 중요한 구성요소임

역활은 책임을 의미하는 인테페이스를 가진 어떤 객체로도 서로 교환될 수 있다는걸 말하는듯 판사라는 자리에 왕이든 왕비든 역활을 대신할 수 있는 책임을 가진 객체가 들어가기만 하면 된다

역활이 협력을 추상적으로 만들 수있는 이유는 역활 자체가 객체의 추상화이기 때문이다.
역활의 대체 가능성은 행위 호환성을 의밓고 행위 호환성은 동일한 책임의 수행을 의미한다.

객체의 모양을 결정하는 협력

객체가 존재하는 이유는 행위를 수행하며 협력에 참여하기 위해서다.

객체를 섬으로 보고 어떤데이터가 필요하고 어떤 클래스로 구현해야 하는지 고민하는 것은 올바르지 않은 것. 객체에 대한 고민은 협력안에서 해야한다. 클래스와 데이터는 책임(행동)을 결정한 후에 해야한다.

객체지향 시스템에서 가장 중요한 것은 충분히 자율적인 동시에 충분히 협력적인 객체를 창조하는 것

객체지향 설계 기법

책임-주도 설계
디자인 패턴
테스트-주도 개발

이 세가지 topic stack 카테고리에서 정리하자

책임과 메시지

훌륭하고 성장 가능한 시스템을 만들기 위한 핵심은 모듈 내부의 속성과 행동이 어떤가보다는 모듈이 어떻게 커뮤니케이션하는가에 달려있다.
사건에 대한 목겨자가 많을수록 개인이 느끼는 책임감은 적어진다. 그에반해 보고할 책임이 명확하게 주어진 경우에는 신속하게 위기 상황을 해결하려고 노력한다.

명확한 책임을 가진 객체가 협력에 참여해야한다

역활과 책임이 흐릿할 수록 발작을 일으키는 객체를 도와줄 어떤 협력자도 찾지 못할 것이다.

자율적인 책임

자신의 의지에 따라 증언할 수 있는 자유

엘리스의 재판

객체가 자율적이기 위해서는 객체에 할당되는 책임의 수준역시 자율적이어야 한다.

책임은 협력에 참여하는 의도를 명확하게 설명할 수 있는 수준안에서 추상적이어야 한다.

어떤 책임이 자율적인지르 판단하는 기준은 문맥에 따라 다르다. 이런 모호함이 객체지향 설계를 난해하면서도 매력적인 예술로 만드는 이유다.

자율적인 책임의 특징은 객체가 '어떻게'가 아니라 '무엇'을 해야하는지를 설명해야한다는 것이다.

진정한 객체지향 패러다임으로의 도약은 개별적인 객체가 아니라 메시지를 주고 받는 개체들 사이의 커뮤니케이션에 초점을 맞출 때 일어난다.

메시지가 아니라 데이터를 중심으로 객체를 설계하는 방식은 객체의 내부 구조를 객체의 일부로 만들기 때문에 자율성을 저해한다.

협력이라는 문맥 안에서 객체의 책임을 결정하는 것은 메시지다.

책임-주도 설계방법에서는 What/Who 사이클에 따라 협력에 참여할 객체를 결정하기 전에 협력에 필요한 메시지를 먼저 결정한다. 메시지가 결정된 후에야 메시지를 수실할 후보를 선택하는 것으로 초점이 이동된다.

객체는 다른 객체의 결정에 간섭하지 말아야 하며, 모든 객체는 자신의 상태를 기반으로 스스로 결정을 내려야 한다.

인터페이스를 두고 호출하는 쪽에서 이 인터페이스를 사용하며 무언가 실행하는것 하지만 누가 실행하는지는 모름 -> 묻지말고 시켜라 음 썻으면 믿어야지

객체는 다른 객체의 상태를 묻지 말아야 한다. 고민을 연기하라. 단지 필요한 메시지를 전송하기만 하고 메시지를 수신하는 객체가 스스로 메시지의 처리 방법을 결정하게 하라.

아.. 메서드 호출할때 객체유효성 검사를 호출하는 쪽에서 해야할지 아니면 실행하는 쪽에서 해야할지에 대한 답이 여기에 있네 호출하는 쪽에서 유효성 검사를 한다는건 너무 고민이 많다는 거고 그건 믿지 못하는거겠지

'묻지 말고 시켜라'스타일은 객체를 자율적으로 만들고 캡슐화를 보장하며 결합도를 낮게 유지시켜주기 때문에 설계를 유연하게 만든다.

객체 인터페이스

내가 알고있는 그것

인터페이스와 구현의 분리

• 좀 더 추상적인 인터페이스
• 최소 인터페이스
• 인터페이스와 구현 간에 차이가 있다는 점을 인식

인터페이스와 구현의 분리 원칙: separation of interface and implementation

객체의 외부와 내부르 분리하라는 것은 결국 객체의 공용 인터페이스와 구현을 명확하게 분리하라는 말과 동일하다.

훌륭한 객체란 구현을 모른 채 인터페이스만 알면 쉽게 상호작용할 수 있는 객체를 의미한다.

객체지향 공동체에서 어떤 객체를 수정했을 때 어떤 객체가 영향을 받느지를 판단하는 것은 거의 곡예에 가깝다.

객체가 가져야 할 상태와 메서드 구현은 객체 내부에 속한다. 이부분을 수정하더라도 객체 외부에 영향을 미쳐서는 안된다.

객체는 공용 인터페이스르 경계로 최대한의 자율성을 보장받을 수 있다.

객체를 자율적인 존재로 바라보는 것은 결국 객체의 내부와 외부를엄격하게 분리 한다는 것을 의미한다.

책임을 결정하는 것은 메시지라는 것을 기억하라.

객체지향의 강력함을 누리기 위한 출발점은 책임을 자율적으로 만드는 것이다.

객체지도

자율적인 객체들로 시스템을 분할하는 개체지향이 강력한 이유는 사람들이 실세계의 현상을 인지하고 이해하는 관점을 그대로 소프트웨어에 투영할 수있기 때문이다.

기능설계 대 구조설계

설계의 가장 큰 도전은 기능과 구조라는 두 가지 측면을 함께 녹여 조화를 이루도록 만드는 것이다. 미래에 대비하는 가장 좋은 방법은 변경을 예측하는 것이 아니라 변경을 수용할 수있는 여지를 설계에 마련해 놓는 것이다.

두가지 재료: 기능과 구조

사용자가 프로그램을 사용하는 대상분야를 도메인이라고 한다.
도메인 모델은 단순히 다이어그램이 아니다. 도메인 모델은 이해관계자들이 바라보는 멘탈 모델이다. 멘탈 모델이란 사람들이 자기 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 대해 갖는 모형이다.
최종 코드는 사용자가 도메인을 바라보는 관점을 반영해야 한다.

표현적 차이

다시 한 번 강조하지만 소프트훼어 객체는 현실 객체에 대한 추상화가 아니다. 소프트웨어 객체와 현실 객체 사이의 관계를 가장 효과적으로 표현할 수있는 단어는 바로 은유다. 은유를 기반으로 현실세계를 재창조한다.

이처럼 소프트웨어 객체가 현실 객체를 왜곡 하더라도 소프트웨어 객체는현실 객체의 특성을 토대로 구축된다. 이처럼 소프트웨어 객체와 현실 객체 사이의 의미적 거리를 가리켜 표현적 차이 또는 의미적 차이라고 한다. 핵심은 은유를 통해 현실 객체와 소프트웨어 객체 사이의 차이를 최대한 줄이는 것이다.

불안정한 재료:기능

사용자의 목표를 달성하기 위해 사용자의 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것을 유스케이스라고 한다.

견고한 객체지향 애플리케이션을 개발하기 위해서는 사용자의 관점에서 시스템의 기능을 명시하고, 사용자와 설계자가 공유하는 안정적인 구조를 기반으로 기능을 책임으로 변환하는 체계적인 절차를 따라야 한다는 것이다.

책임 할당의 기본원칙은 책임을 수행하는 데 필요한 정보를 가진 객체에게 그 책임을 할당하는 것.

함께 모으기

코드와 모델을 밀접하게 연관시키는 것은 코드에 의미를 부여하고 모델읠 적절하게 한다 -에릭 에반슨

객체지향안에 존재하는 세가지 상호 연관된 관점

개념관점
사용자가 도메인을 바라보는 관점

명세관점
프로그래머가 객체를 협력을 하기위해 '무엇'을 할 수 있는지 초점을 맞추는 것.
"구현이 아니라 인터페이스에 대해 프로그래밍 하라"

구현관점
객체들이 책임을 수행하는 데 필요한 코드를 작성하는 것.

서평

그 동안 객체지향을 오해했던 부분에 대해 말끔히 해소했다. 저자가 말하는 도시전설이라는 부분은 평소에 왜 왜 실세계를 반영하는데 잘 맞지않지? 라는 고민에 대해 '은유'라는 설명을 하였고 즉, 실세계의 투영이 아닌 은유를 통한 재창조라고 설명을 한다.

책의 초반부에 도시전설에 대한 내용으로 약간의 통쾌?함을 느꼇다면 후반부는 객체지향을 설계하는데 있어서 어떤 관점으로 바라봐야하는지에 대해 자세하게 설명하고 있다. 특히, 역활 책임 협력을 주요하게 설명하고 이들이 없이는 제대로된 설계를 할 수 없다고 말한다. 지금까지 내가했던 설계는 위와 같지만 협력이라는 관점이 부실했던것 같다. 객체를 독립된 섬으로 보고 객체는 잘만들었지만 협력은 부족했다.

도메인주도설계에 대해서도 설명을 하고 있으며 객체의 관점에서 DDD의 필요성을 말하고 구조적인 측면과 사용자의 관점에서 많은 이득이 있다고 말한다. 현재 회사에서 도메인 주도 설계 비슷하게 하고있어서 공감하며 DDD 부분은 다른 책에서 좀 더 자세하게 살펴보는게 좋을 것 같다