관련 실습 PR 링크 : https://github.com/object-nextstep21/object/pull/1
2장 객체지향 프로그래밍
OOP 를 향해
협력, 객체, 클래스
- OOP 작성할 때 클래스를 결정하고 클래스에 어떤 속성과 메서드 고민 X
- 객체에 초점을 맞출 때 가능
- 어떤 객체인지!
도메인
- 사용자의 문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야
자율적인 객체
- 객체는 상태(state)와 행동(behavior)을 함께 가지는 복합적인 존재
- 객체가 스스로 판단하고 행동하는 자율적인 존재
- 이렇게 데이터와 기능을 묶는것을 캡슐화라고 한다 이를 위해 접근 제어를 이용한다
객체의 두 부분 (seperation of interface and implementation)
- public interface
- 외부에서 접근가능하다
- 메시지로 요청하고, 응답 받는다 (다른 객체와 상호작용하는 유일한 방법)
- 클라이언트 프로그래머의 관심사다
- implementation
- 메서드 내부에서 이용 (수신된 메시지를 처리하는 자신만의 방법)
- 클래스 작성자의 관심사다
- 구분 이유
- 클래스 내/외부 명확히 경계
- 변경을 관리하여 파급 효과 제어 위함
- 메시지, 메서드 구분에서부터 다형성 개념이 출발함 (협력 관점)
협력하는 객체들의 공동체
- "예매"를 위해서 Screening, Movie, Reservation 상호작용한다
상속과 다형성
- DiscountPolicy 를 추상클래스 이용한다
- 전체적인 흐름은 정의하지만, 실제 요금을 계산하는 부분은 추상 메서드에게 위힘한다 (템플릿 메서드 패턴)
컴파일 타임 의존성, 런타임 의존성
트레이드 오프 관계임
- 컴파일 타임 의존성 : 가독성
- early binding (static binding)
- 런타임 의존성 : 유연함 (확장가능성)
- Lazny binding (dynamic binding)
- 컴파일 타임 의존성 : 가독성
런타임 의존성 사용
- 자식 클래스가 부모 클래스 대신하는것 : upcasting
- 메시지 전송은 같지만, 어떤 메서드가 실행될 것인지는 메시지를 수신하는 객체의 클래스가 뭐냐에 따라 달라짐 : 다형성
- 다형성 : 동일한 메시지 수신 시 객체의 타입에 따라 다르게 응답하는 능력
추상화와 유연성
추상화와 유연성
- 추상화 사용시 장점
- 요구사항의 정책을 높은 수준에서 서술 가능
- 설게의 유연성
- 유연한 설계
- 미사용 시 조건문을 사용하게되고, 대부분 좋지 않은 선택이다
- 추상화는 어플리케이션의 협력 흐름을 기술할 수있다.
상속과 합성
상속
- 상속은 코드 재사용이 가능하다
- 하지만 캡슐화를 위반(부모 클래스의 내부까지 알고있어야) / 유연성 저하(자식과 부모간 강결합)
합성
- 컴파일 시점에 하나의 단위로 강결합 되지 않음
- 대신 인터페이스를 통해 약하게 결합
- 여기서 합성이란
- 인터페이스에 정의된 메시지를 통해서만 코드를 재사용 하는 방법
나가며
- 객체지향에서 가장 중요한것은 애플리케이션의 기능을 구현하기 위해 참여하는 객체들의 상호작용
- 객체들은 협력에 참여하기 위해 역할을 부여받고 역할에 적절한 책임을 수행한다
3장 역할, 책임, 협력
1. 영화예매 시스템
- OOP의 제어흐름은 하나의 객체에서 통제하는것이 아니고, 다양한 객체사이에 균형되게 분배하는 것이다
- 그 방법은 메시지를 주고 받으면서 협력하는 것이다
- app 기능 구현위해 수행하는 상호작용 : 협력
- 협력에 참여하기 위해 수행하는 로직 : 책임
- 객체들이 협력안에 수행되는 책임들이 모여 객체가 수행 : 역할
2. 협력
- 메시지 전송은 객체 사이의 협력을 위해 사용가능한 유일한 커뮤니케이션 수단
협력이 설계를 위한 문맥 결정
- 협력은 행동을 결정하고, 행동은 상태를 결정한다
- 결국에는 협력이 객체가 구성하는 행동과 상태 모두 결정
- 여기서 협력은 CONTEXT 를 제공한다
- 이는 책임을 결정가능하게 한다
3. 책임 (OOP 에서 가장중요)
- 협력에 필요한 행동을 수행할 수있는 객체 찾을 때, 협력에 참여하기 위해 객체가 수행하는 '행동'을 책임이라 부른다.
- 여기서 책임이란 '객체에 의해 정의되는 응집도 있는 행위의 집합'으로, 객체가 유지해야하는 정보와 수행할 수있는 행동을 의미한다
- 협력 안에서 할당한 책임이 외부의 인터페이스와 내부의 속성을 결정한다.
- 여기서 책임이 메시지 보다 크다. (책임 > 메시지 => 책임 != 메시지)
책임 할당하는 방법
- 정보 전문가에게 할당한다 (실제 실세계 업무처럼)
- 순서
- 메시지를 전송한다 (퍼블릭 인터페이스)
- 메시지를 처리할 객체를 선택한다
- 결국 협력이 CONTEXT 에서 책임을 결정하고, 책임은 객체를 결정한다
- 이 경우 객체는 나중에 선택해야한다
- 결국 메시지가 객체를 선택하게 해야하므로
- 이렇게 할 경우 최소한의 인터페이스, 추상적 인터페이스(what O, how X) 가 가능하다
행동이 상태를 결정한다
- 기존에 나도 상태에 초점을 맞췄다.
- 캡슐화 위반을 방지하기 위해 구현결정을 미루고, 협력을 위한 CONTEXT를 먼저 고민하자
4. 역할
- 역할이란 : 책임의 집합(교체가능한 슬롯)
책임 할당 단계
- 영화를 예매할 수있는 적절한 역할은 무엇인가?
- 역할을 수행할 객체를 선택하기
- 유연하고 재사용가능한 협력이 가능해진다.
- 역할은 두종류의 객체(정액/정률)를 포괄하는 추상화
역할과 추상화
- 추상화 장점 2가지 처럼 역할을 객체의 추상화로 본다면, 중요정책을 상위수준으로 볼 수있고, 설계가 유연해진다
배우와 배역
- 하나의 배역에 여러 배우가 가능한 것 처럼 / 하나의 역할에 여러 객체가 참여 가능하다
- 하나의 배우가 서로 다른 배역 가능한 것 처럼 / 하나의 객체가 여러 협력에서 다양한 역할이 가능하다