[책] 오브젝트 - 1

 

오브젝트

마지막 걸음은 앞에서 설명한 개념들을 여러분이 사용하는 프로그래밍 언어라는 틀에 흐트러짐 없이 담아낼 수 있는 기술을 익히는 것이다. 《객체지향의 사실과 오해》가 첫번째 걸음과 두번째 걸음인 객체와 협력에 초점을 맞췄다면 《오브젝트: 코드로 이해하는 객체지향 설계》는 세번째와 네번째 걸음인 책임의 할당과 그 구현에 초점을 맞춘다. 이 책을 읽고 나면 객체에 적절한 역할과 책임을 부여하는 방법과 유연하면서도 요구사항에 적절한 협력을 설계하는 방법을 익히게

저자

조영호

출판

위키북스

출판일

2019.06.17

 

 

절차형 패러다임 → 객체지향 패러다임

프로그래밍 패러다임 : 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 하는 것

 

1장 객체, 설계

모든 모듈은 제대로 실행돼야 하고, 변경이 용이해야 하며, 이해하기 쉬워야 한다. (로버트 마틴)

문제가 있는 코드: 예상을 빗나가는 코드 / 변경에 취약한 코드 → 불필요한 의존성을 제거해야 한다

 

(이 책에서는 티켓 판매 어플리케이션을 설계하는 과정을 통해 설명하고 있다..)

(절차적 프로그래밍의 문제점을 설명하고 객체지향 프로그래밍으로 바꾸는 과정을 설명해준다)

 

• 캡슐화: 개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것 → 변경하기 쉬운 객체를 만든다는 것이다.
• 내부 구현을 외부에 노출하지 않고 자신의 문제를 스스로 책임지고 해결함으로써 각 객체가 자율적인 존재가 된다. → 변경 용이성 측면에서 개선이 된다

ex) 판매자가 티켓을 판매하기 위해 TicketOffice를 사용하는 모든 부분을 TicketSeller 내부로 옮기고, 관람객이 티켓을 구매하기 위해 Bag을 사용하는 모든 부분을 Audience 내부로 옮긴 것이다.

 

• 밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도가 높다고 말한다
• 각 객체는 자신의 문제를 스스로 처리한다 → 책임의 이동
• 의인화: 비록 현실에서는 수동적인 존재라고 하더라도 일단 객체지향의 세계에 들어오면 모든 것이 능동적이고 자율적인 존재로 바뀐다 (ex: 이 예시에서는 Bag이 그렇다. )

 

훌륭한 객체지향 설계란?

→ 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계다. 변경에 용이한 설계를 만드는 것이다.

 

 

사실 캡슐화가 정확히 뭔뜻인지 잘 몰랐는데 예시를 들어 자세히 설명해주셔서 캡슐화가 무엇인지 자세히 알 수 있었다.

 

 

 

2장 객체지향 프로그래밍

<객체>

1. 어떤 클래스가 필요한지를 고민하기 전에 어떤 객체들이 필요한지를 고민하라.
2. 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원으로 봐야한다.

<도메인>

도메인: 문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야

→ 도메인의 구조와 유사하게 클래스의 구조를 설정해야 한다.

 

<객체의 자율성>

클래스의 내부와 외부를 구분해야 하는 이유? 경계의 명확성이 객체의 자율성을 보장하기 때문이다.

1. 객체가 상태와 행동을 함께 가지는 복합적인 존재라는 것
2. 객체가 스스로 판단하고 행동하는 자율적인 존재라는 것

퍼블릭 인터페이스: 외부에서 접근 가능한 부분 (public으로 지정된 메서드)

구현: 외부에서는 접근 불가능하고 오직 내부에서만 접근 가능한 부분 (private 메서드, protected 메서드, 속성)

 

<프로그래머의 자유>

• 클래스 작성자 / 클라이언트 프로그래머

객체의 외부와 내부를 구분하면 클라이언트 프로그래머가 알아야할 지식이 줄어들고, 클래스 작성자가 자유롭게 구현을 변경할 수 있는 폭이 넓어진다.

 

<협력>

메시지와 메서드의 구분

• 객체가 다른 객체와 상호작용하는 것을 메시지
• 메시지를 수신한 객체는 자율적으로 메시지를 처리할 방법을 결정한다 → 이때 이 방법을 메서드라고 함.

TEMPLATE METHOD: 부모클래스에 기본적인 알고리즘의 흐름을 구현하고 중간에 필요한 처리를 자식 클래스에게 위임하는 디자인 패턴

 

<의존성>

코드의 의존성과 실행 시점의 의존성이 다르다

클래스 사이의 이존성과 객체 사이의 의존성은 다르다

• 설계가 유연해질수록 코드를 이해하고 디버깅하기는 점점 어려워진다
• 유연성을 억제하면 코드를 이해하고 디버깅하기는 쉬워지지만 재사용성과 확장 가능성은 낮아진다.

 

<상속: 차이에 의한 프로그래밍>

부모 클래스와 다른 부분만을 추가해서 새로운 클래스를 쉽게 빠르게 만드는 방법

자식클래스는 상속을 통해 부모 클래스의 인터페이스를 물려받기 때문에 부모 클래스 대신 사용될 수 있다. → 업캐스팅

 

<다형성>

• 동일한 메시지를 전송하지만 실제로 어떤 메서드가 실행될 것인지는 메시지를 수신하는 객체의 클래스가 무엇이냐에 따라 달라진다.
• 객체 타입에 따라 다르게 응답할 수 있는 능력
• 다형적인 협력에 참여하는 객체들은 모두 같은 메시지를 이해할 수 있어야함 (인터페이스가 동일해야함)
• 실행될 메서드를 컴파일 시점이 아닌 실행 시점에 결정한다 → lazy binding, dynamic binding

<추상화>

요구사항의 정책을 높은 수준에서 서술할 수 있다 / 설계가 좀 더 유연해진다.

 

<상속의 문제점>

1. 캡슐화를 위반한다
2. 설계를 유연하게 하지 못한다

<합성>

• 인터페이스에 정의된 메시지를 통해서만 코드를 재사용하는 방법
• 합성(Composition): 클래스가 다른 클래스의 객체를 포함하는 관계 → "has-a" 관계
• 상속이 가지는 두가지 문제점을 모두 해결한다.