- 저자
- 조영호
- 출판
- 위키북스
- 출판일
- 2015.06.17
객체지향의 사실과 오해
객체지향의 목표는 실세계를 모방하는 것이 아니다. 오히려 새로운 세계를 창조하는 것이다. 소프트웨어 개발자의 역할은 단순히 실세계를 소프트웨어 안으로 옮겨 담는 것이 아니라 고객과 사용자를 만족시킬 수 있는 신세계를 창조하는 것이다.
- 21p
그것은 바로 역할, 책임, 협력이다.
-25p
역할은 대체 가능성을 의미한다.
책임을 수행하는 방법은 자율적으로 선택할 수 있다.
한 사람이 동시에 여러 역할을 수행할 수 있다.
- 28p
흔히 객체를 상태(state)와 행동(behavior)을 함께 지닌 실체라고 정의한다. 이 말은 객체가 협력에 참여하기 위해 어떤 행동을 해야 한다면 그 행동을 하는 데 필요한 상태도 함게 지니고 있어야 한다는 것을 의미한다.
- 32p
객체지향의 본질
- 객체지향이란 시스템을 상호작용하는 자율적인 객체들의 공동체로 바라보고 객체를 이용해 시스템을 분할하는 방법이다.
- 자율적인 객체란 상태와 행위를 함께 지니며 스스로 자기 자신을 책임지는 객체를 의미한다.
- 객체는 시스템의 행위를 구현하기 위해 다른 객체와 협력한다. 각 객체는 협력 내에서 정해진 역할을 수행하며 역할은 관련된 책임의 집합이다.
- 객체는 다른 객체와 협력하기 위해 메시지를 전송하고, 메시지를 수신한 객체는 메시지를 처리하는 데 적합한 메서드를 자율적으로 선택한다.
- 35p
클래스가 객체지향 프로그래밍 언어의 관점에서 매우 중요한 구성요소인 것은 분명하지만 객체지향의 핵심을 이루는 중심 개념이라고 말하기에는 무리가 있다.
- 37p
훌륭한 객체지향 설계자가 되기 위해 거쳐야 할 첫 번째 도전은 코드를 담는 클래스의 관점에서 메시지를 주고받는 객체의 관점으로 사고의 중심을 전환하는 것이다. 중요한 것은 어떤 클래스가 필요한가가 아니라 어던 객체들이 어던 메시지를 주고받으며 협력하는가다.
- 38p
하나의 개별적인 실체로 식별 가능한 물리적인 또는 개념적인 사물은 어떤 것이라도 객체가 될 수 있다. 인간의 인지 능력 안에서 개수를 셀 수 있고, 다른 사물과 구분할 수 있으며, 생성 시점을 알 수 있고, 독립적인 하나의 단위로 인식할 수 있는 모든 사물은 객체다. 객체의 다양한 특성을 효과적으로 설명하기 위해서는 객체를 상태(state), 행동(behavior), 식별자(identity)를 지닌 실체로 보는 것이 가장 효과적이다.
-47p
모든 객체의 상태는 단순한 값과 객체의 조합으로 표현할 수 있다. 이때 객체의 상태를 구성하는 모든 특징을 통틀어 객체의 프로퍼티(property)라고 한다. 앨리스의 경우 키, 위치, 음료가 앨리스의 프로퍼티가 된다.
- 50[
상태는 특정 시점에 객체가 가지고 있는 정보의 집합으로 객체의 구조적 특징을 표현한다. 객체의 상태는 객체에 존재하는 정적인 프로퍼티와 동적인 프로퍼티 값으로 구성된다. 객체의 프로퍼티는 단순한 ㄱ밧과 다른 객체를 참조하는 링크로 구분할 수 있다.
- 51p
행동이란 외부의 요청 또는 수신된 메시지에 응답하기 위해 동작하고 반응하는 활동이다. 행동의 결과로 객체는 자신의 상태를 변경하거나 다른 객체에게 메시지를 전달할 수 있다. 객체는 행동을 통해 다른 객체와의 협력에 참여하므로 행동은 외부에 가시적이어야 한다.
- 55p
이것이 캡슐화가 의미하는 것이다. 객체는 상태를 캡슐 안에 감춰둔 채 외부로 노출하지 않는다. 객체가 외부에 노출하는 것은 행동분이며, 외부에서 객체에 접근할 수 있는 유일한 방법 역시 행동뿐이다.
- 56p
일반적으로 객체의 상태를 조회하는 작업을 쿼리(query)라고 하고 객체의 상태를 변경하는 작업을 명령(command)라고 한다.
- 60p
협력의 참여에하는 훌륭한 객체 시민을 양성하기 위한 가장 중요한 덕목은 상태가 아니라 행동에 초점을 맞추는 것이다. 객체는 다른 객체와 협력하기 위해 존재한다. 객체의 행동은 객체가 협력에 참여하는 유일한 방법이다. 따라서 객체가 적합한지를 결정하는 것은 그 객체의 상태가 아니라 행동이다.
- 65p
진정한 의미에서 추상화란 현실에서 출발하되 불필요한 부분을 도려내가면서 사물의 놀라운 본질을 드러나게 하는 과정이라고 할 수 있다(Root-Bernstein 2001). 추상화의 목적은 불필요한 부분을 무시함으로써 현실에 존재하는 복잡성을 극복하는 것이다. 추상화는 복잡한 현실을 단순화하기 위해 사용하는 인간의 가장 기본적인 인지 수단이라고 할 수 있다.
- 76p
객체에 어떤 개념을 적용하는 것이 가능해서 개념 그룹의 일원이 될 때 객체를 그 개념의 인스턴스라고 한다. 따라서 객체를 다음과 같이 정의할 수도 있다. 객체란 특정한 개념을 적용할 수 있는 구체적인 사물을 의미한다. 개념이 객체에 적용됐을 때 객체를 개념의 인스턴스라고 한다.
- 84p
타입은 개념과 동일하다.
- 89p
책임의 분류
- 하는 것
- 아는 것
- 115p
책임이 협력이라는 문맥 속에서 요청을 수신하는 한 쪽의 객체 관점에서 무엇을 할 수 있는지를 나열하는 것이라면 메시지는 협력에 참여하는 두 객체 사이의 관계를 강조한 것이다.
- 117p
역할의 개념을 사용하면 유사한 협력을 추상화해서 인지 과부화를 줄일 수 있다. 또한 다양한 객체들이 협력에 참여할 수 있기 때문에 협력이 좀 더 유연해지며 다양한 객체들이 동일한 협력에 참여할 수 있기 때문에 재사용성이 높아진다.
- 126p
협력을 설계한다는 것은 설계에 참여하는 객체들이 주고받을 요청과 응답의 흐름을 결정한다는 것을 의미한다.
- 129p
- 시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 파악한다.
- 시스템 책임을 더 작은 책임으로 분할한다.
- 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다.
- 객체가 책임을 수행하는 중에 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할을 찾는다.
- 해당 객체 도는 역할에게 책임을 할당함으로써 두 객체가 협력하게 한다.
- 133p
객체지향 세계는 자율적인 객체들의 공동체라는 점을 명심하라. 객체가 자율적이기 위해서는 객체에게 할당되는 책임의 수준 역시 자율적이어야 한다.
-144p
자율적인 책임의 특징은 객체가 '어떻게' 해야하는 가가 아니라 '무엇'을 해야 하는가를 설명한다는 것이다.
- 145p
메시지는 '어떻게' 수행될 것인지는 명시하지 않는다. 메시지는 단지 오퍼레이션을 통해 '무엇'이 실행되기를 바라는지만 명시하며, 어떤 메서드를 선택할 것인지는 전적으로 수신자의 결정에 좌우된다.
- 149p
다형성이란 서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응하는 것을 의미한다. 좀 더 구체적으로 말해 서로 다른 타입에 속하는 객체들이 동일한 메시지를 수신할 경우 서로 다른 메서드를 이용해 메시지를 처리할 수 있는 메커니즘을 가리킨다.
- 150p
송신자는 오직 메시지만 바라본다. 수신자의 정확한 타입을 모르더라도 상관없다. 단지 수신자가 메시지를 이해하고 처리해 줄 것이라는 사실만 알아도 충분하다. 수신자는 메시지를 처리하기 위해 자율적으로 메서드를 선택할 수 있지만 메서드 자체는 송신자에게 노출시키지 않는다.
수신자와 송신자는 메시지라는 얇은 끈으로만 이어져 있다. 메시지를 기반으로 한 두 객체 사이의 이 낮은 결합도가 바로 설계를 유연하고 확장 가능하며 재사용 가능하게 만드는 비결이다.
- 154p
객체지향의 강력함은 클래스가 아니라 객체들이 주고받는 메시지로부터 나온다.
- 155p
what/who 사이클은 어떤 객체가 필요한지 생각하지 말고 어떤 메시지가 필요한지를 먼저 고민하라고 조언한다.
- 159p
샌디 메츠는 '묻지 말고 시켜라' 스타일이란 "메시지가 '어떻게' 해야 하는지를 지시하지 말고 '무엇'을 해야 하는지를 요청"하는 것이라고 설명한다.
- 160p
책임이 자율적일수록 객체의 응집도를 높은 상태로 유지하기가 쉬워진다.
- 176p
기능과 구조
- 구조는 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계로 표현한다.
- 기능은 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현한다.
- 184p
개념 관점, 명세 관점, 구현 관점은 동일한 코드를 바라보는 서로 다른 관점이다.
- 227p
인터페이스와 구현을 분리하라
- 228p
명세 관점과 구현 관점이 뒤섞여 여러분의 머릿속을 함부로 어지럽히지 못하게 하라. 명세 관점은 클래스의 안정적인 측면을 드러내야 한다. 구현 관점은 클래스의 불안정한 측면을 드러내야 한다. 인터페이스가 구현 세부 사항을 노출하기 시작하면 아주 작은 변동에도 전체 협력이 요동치는 취약한 설계를 얻을 수 밖에 없다.
- 228p
'Book' 카테고리의 다른 글
| [독서 기록] 모던 자바 인 액션 2장 - 동작 파라미터화 코드 전달하기 (0) | 2023.01.04 |
|---|---|
| [독서 기록] 모던 자바 인 액션 1장 자바 8, 9, 10, 11 : 무슨 일이 일어나고 있는가? (0) | 2023.01.04 |
| [독서 기록] 개발자의 글쓰기, 저자 김철수, 출판 위키북스, 2019 (1) | 2022.11.26 |
| [독서 기록] 나는 주니어 개발자다 (0) | 2022.11.22 |
| [독서 기록] 자바로 배우는 리팩토링 입문 (0) | 2022.11.22 |