객체지향의 사실과 오해

부제: 역할, 책임, 협력 관점에서 본 객체지향

1장 협력하는 객체들의 공동체

• 객체 지향에 대한 입문, 안내의 느낌

- 객체란 현실 세계에 존재하는 사물에 대한 추상화
=> 아니다, 실세계의 모방은 소프트웨어에서는 이루어 질 수 없다. 오히려 객체를 통해 새로운 세계를 창조하는 것이다
이때 객체는 스스로 생각하고, 결정할 수 있어야 한다.

객체의 특성
1. 객체는 충분히 '협력적'이어야 한다. 다른 객체들과의 상호작용이 가능해야 한다
2. 객체가 충분히 '자율적'이어야 한다.

클래스는 객체지향을 이루는 중요한 도구이다.but 핵심 개념은 아니다
핵심은 적절한 책임을 수행하는 역할 간의 유연하고 견고한 협력 관계를 구축하는 것 

2장 이상한 나라의 객체

객체는 상태, 행동, 식별자를 가진다
=> 상태, 행동(메서드), 식별자(변수명)

객체는 자율적인 객체다. 서로 간의 상태에 간섭할 수 없다.
스스로의 행동으로서만 상태가 변경되는 것을 보장함으로써 자율성을 유지시켜 주어야 한다.

캡슐화 => 객체가 외부에 노출하는 것은 행동뿐, 외부에서 객체에 접근할 수 있는 유일한 방법도 역시 행동뿐

객체지향적 사고는 상태보다는 행동을 먼저 정하고 파생되는 상태를 다루어야 한다.
=> 커피를 파는데 먼저 판단하여 부자재들을 다 구매하는것이 아니라
커피를 파는것을 결정하고 그에 따른 행동들이 결정 되고 이 행동들을 구성하기 위한 부자재들이 결정되는 순서가 안전하다
로 이해했다

3장 타입과 추상화

소프트웨어의 세계는 너무나 디테일하고 복잡하다 => 추상화의 필요성 대두

행동의 중요성 => 어떤 객체가 어떤 타입에 속하는지를 결정하는 것은 객체가 수행하는 행동이다. 동일한 행동을 수행한다면 객체들은 동일한 타입이다.
캡슐화 => 객체의 내부적인 표현은 외부로부터 철저하게 감춰진다

객체지향에서 중요한 것은 객체의 상태, 상태를 변경하는 행위
클래스는 타입을 구현하기 위해 프로그래밍 언어에서 제공하는 구현 메커니즘일 뿐

4장 역할,책임,협력

5장에 가기 위해 빌드업 하는 부분

5장 책임과 메시지

객체지향 어플리케이션을 설계하는 가장 널리 알려진 방법을 책임-주도 설계라고 부르는 이유는
적절한 책임의 선택이 전체 설계의 방향을 결정하기 때문이다.

협력에 참여하는 객체가 얼마나 자율적인지가 어플리케이션의 품질을 결정한다.
=> 책임을 잘 나눴고 역할이 분명하다면 한 곳의 변화가 다른 곳에 영향을 끼치지 않게 할 수 있다.
하나의 거대한 프로그램을 잘게 쪼갤 수 있고 변경 및 확장에도 유연해질 수 있으니 좋은 품질이라고 판단되어지는 것 같다

다형성
다른 타입의 객체가 동일한 메시지에 다르게 반응할 수 있다.
=> 하나의 메시지를 재사용할 수 있을것 같다 / 객체들의 다양한 방향으로의 확장이 가능해질 것 같다 / 서로 다른 객체들이 같은 책임을 가지게 된다

메시지!메시지!메시지!

6장 객체 지도

객체지향 접근방법은 자주 변경되지 않는 안정적인 객체 구조를 바탕으로 시스템 기능을 객체 간의 책임으로 분배한다.
객체지향은 객체의 구조에 집중하고 기능이 객체의 구조를 따르게 만든다.
시스템 기능은 더 작은 책임으로 분할되고 적절한 객체에게 분배되기 때문에 기능이 변경되더라도 객체간의 구조는 그대로 유지된다
=> 객체 구조를 기반으로의 시스템 설계가 변화에 유연하고 안정된 이유!!!!

도메인 모델은 도메인에 대한 사용자 모델, 디자인 모델, 시스템 이미지를 포괄하도록 추상화한 소프트웨어 모델이다. 
도메인 모델은 소프트웨어에 대한 멘탈 모델이다
=> 도메인 모델은 안정적이다. 도메인 모델은 사용자가 서비스에 바라는 요구들을 담아낸다. 이것은 즉 서비스의 본질을 의미한다
서비스의 생명주기 내에 본질은 변화할 가능성이 매우 적다. 이러한 본질을 기반으로 객체의 역할, 책임, 행동을 정의한다면
안정적이고 변화에 유연하게 어플리케이션을 구성할 수 있다

변경에 유연한 소프트웨어를 만들기 위해서는 유스케이스에 정리된 시스템의 기능을 도메인 모델을 기반으로 한 객체들의 책임으로 분배해야 한다.

도메인 모델을 구성하는 개념은 비즈니스가 없어지거나 완전히 개편되지 않는 한 안정적으로 유지된다.
도메인 모델을 구성하는 개념간의 관계는 비즈니스 규칙을 기반으로 하기 때문에 비즈니스 정책이 크게 변경되지 않는 한 안정적으로 유지된다.

7장 함께 모으기

소프트웨어는 항상 변한다. 설계는 변경을 위해 존재한다.
여러 개의 클래스로 기능을 분할하고 클래스 안에서 인터페이스와 구현을 분리하는 이유는 변경이 발생했을 때 코드를 좀 더 수월하게 수정하길 간절히 원하기 때문이다.

인터페이스와 구현을 분리하라
인터페이스가 구현 세부 사항을 노출하기 시작하는 순간 작은 변동에도 전체가 요동친다.
프로그래머의 입장에서 가장 많이 접하게 되는 것은 코드이므로 구현 관점을 가장 빈번하게 사용하겠지만 
실제로 훌륭한 설계를 결정하는 측면은 명세 관점인 객체의 인터페이스다.
명세 관점이 설계를 주도하게 하면 설계의 품질이이 향상될 수 있다는 사실을 기억하라.

클래스를 봤을때 명세 관점과 구현 관점으로 나눠볼 수 있어야 한다.