객체지향의 사실과 오해 정리 - 짧은 키워드 중심으로

p5

객체지향으로 향하는 첫 걸음은 클래스가 아니라 객체를 바라보는 것에서 시작한다.

두 번째 걸음은 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 존재로 바라보는 것

세 번째 걸음은 협력에 참여하는 객체들에게 얼마나 적절한 역할과 책임을 부여할 수 있느냐에 달림

마지막 걸음은 프로그래밍 언어라는 틀에 흐트러짐 없이 담아낼 수 있는 기술을 익히는 것

 

p35

객체지향이란 시스템을 상호작용하는 자율적인 객체들의 공동체로 바라보고 객체를 이용해 시스템을 분할하는 방법

자율적인 객체란 상태와 행위를 함께 지니며 스스로 자기 자신을 책임지는 객체

객체는 시스템의 행위를 구현하기 위해 다른 객체와 협력. 각 객체는 협력 내에서 정해진 역할을 수행하며 역할은 관련된 책임의 집합.

객체는 다른 객체와 협력하기 위해 메시지를 전송하고, 메시지를 수신한 객체는 메시지를 처리하는 데 적합한 메서드를 자율적으로 선택한다.

 

p51

객체의 상태는 특정 시점에 객체가 가지고 있는 정보의 집합. 객체의 구조적 특징을 표현함.

정적인 프로퍼티와 동적인 프로퍼티 값으로 구성됨. 

 

p54

객체가 다른 객체와 메시지를 통해서만 의사소통할 수 있다는 것을 기억하라

 

p55

행동이란 외부의 요청 또는 수신된 메시지에 응답하기 위해 동작하고 반응하는 활동.

행동의 결과로 객체는 자신의 상태를 변경하거나 다른 객체에게 메시지를 전달할 수 있다. 

객체는 행동을 통해 다른 객체와의 협력에 참여하므로 행동은 외부에 가시적이어야 한다.

 

p56

객체가 외부에 노출하는 것은 행동뿐이며, 객체에 접근할 수 있는 유일한 방법 역시 행동뿐이다.

 

p66

행동이 상태를 결정한다.

 

p67

현실 객체와 소프트웨어 객체의 차이점은 현실 속에서는 수동적인 존재가 소프트웨어 객체로 구현될 때는 능동적으로 변한다는 것

 

p84

객체란 특정한 개념을 적용할 수 있는 구체적인 사물을 의미한다. 개념이 객체에 적용됐을 때 객체를 개념의 인스턴스라고 한다.

 

p87

분류란 객체에 특정한 개념을 적용하는 작업이다. 객체에 특정한 개념을 적용하기로 결심했을 때 우리는 그 객체를 특정한 집합의 멤버로 분류하고 있는 것이다.

 

p93

결론적으로 객체의 타입을 결정하는 것은 객체의 행동뿐이다.

다형성이란 동일한 요청에 대해 서로 다른 방식으로 응답할 수 있는 능력을 말함

객체가 외부에 제공해야 하는 행동을 먼저 생각해야 한다.

 

p104

타입을 구현하는 가장 보편적인 방법은 클래스를 이용하는 것이다.

 

p109

개별적인 객체의 행동이나 상태가 아니라 객체들 간의 협력에 집중하라

 

p159

어떤 객체가 필요한지를 생각하지 말고 어떤 메시지가 필요한지를 먼저 고민하라

 

p164

객체지향에서 모든 상호작용은 메시지를 통해서만 이뤄져야 하며 자기 자신과의 상호작용 역시 예외가 아니다.

 

p166

책임은 객체가 메시지를 수신했을 때 수행해야 하는 객체의 행동이며, 공용 인터페이스를 구성하는 것은 객체가 외부로부터 수신할 수 있는 메시지의 목록이다.

메서드란 메시지를 수신했을 때 책임을 수행하는 방법을 의미한다.

 

p167

객체지향적 사고 방식을 이해하기 위해서 중요한 3가지

1. 좀 더 추상적인 인터페이스

2. 최소 인터페이스

3. 인터페이스와 구현 간에 차이가 있다는 것을 인식

 

p168

내부 구조와 작동 방식을 가리키는 고유의 용어는 구현이다.

행동은 메시지를 수신했을 때만 실행되는 일종의 메시지 처리 방법이다. 메서드라고 한다.

 

p169

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

객체 설계의 핵심은 객체를 두 개의 분리된 요소로 분할해 설계하는 것이다. 바로 외부에 공개되는 인터페이스와 내부에 감춰지는 구현이다.

분리 이유는 소프트웨어는 항상 변경되기 때문이다. 안전지대가 객체의 내부인 구현이고 위험 지대가 객체의 외부인 공용 인터페이스다.

 

객체가 가져야 할 상태와 메서드 구현은 객체 내부에 속한다. 객체 외부에 영향을 미치는 변경은 객체의 공용 인터페이스를 수정할 때 뿐이다.

 

p170

구현을 외부로부터 감추는 것을 캡슐화라고 한다. 정보 은닉이라고 부르기도 한다.

 

p171

객체의 공용 인터페이스는 외부에서 전송 가능한 메시지의 집합이다.

 

p172

객체지향은 내부와 외부를 명확하게 구분하는 객체들로 구성된 협력 공동체다.

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

 

p174

1. 자율적인 책임은 협력을 단순하게 만든다.

2. 자율적인 책임은 외부와 내부를 명확하게 분리한다

3. 책임이 자율적일 경우 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않는다

4. 자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다

5. 객체가 수행하는 책임들이 자율적일수록 객체의 역할을 이해하기 쉬워진다 책임이 자율적일수록 객체의 응집도를 높은 상태로 유지하기가 쉬워진다.

 

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

 

p180

 

기능을 중심으로 구조를 종속시키는 접근법은 범용적이지 않고 재사용이 불가능하며 변경에 취약한 모델을 낳게 된다.

안정적인 구조를 중심으로 기능을 종속시키는 접근법은 범용적이고 재사용 가능하며 변경에 유연하게 대처할 수 있는 모델을 만든다.

 

자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하라

 

p181

기능 측면의 설계는 제품이 사용자를 위해 무엇을 할 수 있는지에 초점을 맞춘다. 구조 측면의 설계는 제품의 형태가 어떠해야 하는지에 초점을 맞춘다.

 

p182

훌륭한 설계자는 사용자가 만족할 수 있는 훌륭한 기능을 제공하는 동시에 예측 불가능한 요구사항 변경에 유연하게 대처할 수 있는 안정적인 구조를 제공하는 능력을 갖춰야 한다

 

설계를 하는 목적은 나중에 설계하는 것을 허용하는 것

 

p184

구조는 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계로 표현한다

기능은 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현한다

 

p185

사용자가 프로그램을 사용하는 대상 분야를 도메인이라고 한다

모델이란 대상을 단순화해서 표현한 것

 

p187

도메인 모델은 소프트웨어에 대한 멘탈 모델이다.

 

p189

도메인 모델의 핵심은 사용자가 도메인을 바라보는 관점을 반영해 소프트웨어를 설계하고 구현하는 것이다.

 

p194

유스케이스의 특성

1. 유스케이스는 사용자와 시스템 간의 상호작용을 보여주는 텍스트다

2. 유스케이스는 하나의 시나리오가 아니라 여러 시나리오들의 집합이다

3. 유스케이스는 단순한 피처 목록과 다르다. 이야기를 통해 연관된 기능들을 함께 묶을 수 있다

4. 유스케이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 한다.

5. 유스케이스는 내부 설계와 관련된 정보를 포함하지 않는다

 

p196

유스케이스는 단지 기능적 요구사항을 사용자의 목표라는 문맥을 중심으로 묶기 위한 정리 기법일 뿐

유스케이스는 객체의 구조나 책임에 대한 어떤 정보도 제공하지 않는다

 

도메인 모델은 안정적인 구조를 개념화하기 위해, 유스케이스는 불안정한 기능을 서술하기 위해 사용되는 도구

 

p202

크기와 상관없이 모든 객체는 메시지를 전송하거나 수신할 수 있고 메시지에 응답하기 위해 자율적으로 메서드를 선택할 수 있다.

 

p206

도메인 모델은 사람들의 머릿속에 들어있는 공유된 멘탈 모델이다.

사람들이 동일한 용어와 동일한 개념을 이용해 의사소통하고 코드로부터 도메인 모델을 유추할 수 있게 하는 것이 도메인 모델의 진정한 목표다

 

p212

상태와 무관하게 동일하게 행동할 수 있는 객체들은 동일한 타입으로 분류할 수 있다

 

p214

협력이란 적절한 객체에게 적절한 책임을 할당하는 것이다

 

객체지향의 첫번째 목표는 훌륭한 협력을 설계하는 것

메시지를 먼저 선택하고 그 후에 메시지를 수신하기에 적절한 객체를 선택해야 한다

 

p222

설계 작업은 구현을 위한 스케치 단계

최대한 빨리 코드로 구현해서 설계가 구현 가능한지 판단해야 한다

 

객체가 어떤 책임을 수행해야 하는지를 결정한 다음 책임을 수행하는 데 필요한 객체의 속성을 결정하라

 

p226

소프트웨어는 항상 변한다. 설계는 변경을 위해 존재한다