Wilkyway

01. 데이터 중심의 영화 예매 시스템

○ 데이터를 준비하자

○ 영화를 예매하자

02. 설계 트레이드오프

○ 캡슐화

· 객체를 사용하면 변경 가능성이 높은 부분은 내부에 숨기고(구현) 외부에는 상대적으로 안정적인 부분만 공개함으로써(인터페이스) 변경의 여파를 통제할 수 있다.

○ 응집도와 결합도

· 응집도: 모듈 내의 요소들이 하나의 목적을 위해 긴밀하게 협력한다면 높은 응집도

· 결합도: 어떤 모듈이 다른 모듈에 대해 꼭 필요한 지식만 알고 있다면 두 모듈은 낮은 결합도를 가진다. 

클래스의 구현이 아닌 인터페이스에 의존하도록 코드를 작성해야 낮은 결합도를 얻을 수 있다.

03. 데이터 중심의 영화 예매 시스템의 문제점

○ 캡슐화 위반

○ 높은 결합도

○ 낮은 응집도

단일책임원칙(SRP: Single Responsibility Principle)

04. 자율적인 객체를 향해

○ 캡슐화를 지켜라

○ 스스로 자신의 데이터를 책임지는 객체

· 질문1: 어떤 데이터를 포함해야 하는가?

- 이 객체가 어떤 데이터를 포함해야 하는가?

- 이 객체가 데이터에 대해 수행해야 하는 오퍼레이션은 무엇인가?

· 질문2: 데이터를 처리하기 위해 어떤 오퍼레이션이 필요한가?

05. 하지만 여전히 부족하다.

○ 캡슐화 위반

캡슐화의 진정한 의미: 구현과 관련된 것이라면 변하는 어떤 것이든 감추는 것.

○ 높은 결합도

유연한 설계를 위해서는 캡슐화를 설계의 첫 번째 목표로 삼아야 한다.

○ 낮은 응집도

06. 데이터 중심 설계의 문제점

○ 데이터 중심 설계는 객체의 행동보다는 상태에 초점을 맞춘다

· 데이터 중심의 설계는 너무 이른 시기에 데이터에 대해 고민하기 때문에 캡슐화에 실패하게 된다. => 변경에 취약한 코드

○ 데이터 중심 설계는 객체를 고립시킨 채 오퍼레이션을 정의하도록 만든다

01. 협력

- 영화 예매 시스템 돌아보기

협력: 기능 구현을 위한 상호작용

책임: 협력에 참여하기 위해 수행하는 로직

역할: 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 역할을 구성한다.

- 협력

객체가 메시지를 처리할 방법을 스스로 선택한다.(자율적 존재)

자율적 존재가 되기 위해서는 자신이 알고있는 정보를 이용해 직접 요금을 계산해야 한다. (캡슐화)

메시지를 처리하던 중에 직접 처리할 수 없는 정보나 행동이 필요한 경우 또다른 객체에게 도움을 요청한다.

- 협력이 설계를 위한 문맥을 결정한다.

객체의 행동을 결정하는 것은 객체가 참여하고 있는 협력이다.

협력이 바뀌면 객체가 제공해야하는 행동 역시 바뀌어야 한다.

협력 -> 행동 -> 상태

협력이 일종의 문맥(Context)를 제공한다.

02. 책임

- 책임이란 무엇인가

책임의 구분

   - 무엇을 알고있는가?

      : 사적인 정보에 관해 아는 것

      : 관련된 객체에 관해 아는 것

      : 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것

   - 무엇을 할 수 있는가?

      : 객체를 생성하거나 계산을 수행하는 등의 스스로 하는 것

      : 다른 객체의 행동을 시작시키는 것

      : 다른 객체의 활동을 제어하고 조절하는 것

책임은 객체가 수행할 수 있는 행동을 종합적이고 간략하게 서술하기 때문에

메시지보다 추상적이고 개념적으로도 더 크다.

CRC카드(Candidate, Responsibility, Collaborator): 인덱스 카드를 후보라고 생각하기 시작하면 자연스럽게 인덱스 카드의 구현에 대한 세부적인 결정은 미루고 책임과 협력에 집중할 수 있게 된다.

- 책임 할당

수행할 정보 전문가를 찾는 과정.

- 책임 주도 설계

RDD(책임 주도 설계): 협력을 설계하기 위해서는 책임에 초점을..

    - 메시지가 객체를 결정한다.

      : 객체가 최소한의 인터페이스를 가질 수 있게 된다.

      : 추상적인 인터페이스를 가질 수 있게 된다. 

    - 행동이 상태를 결정한다.

      객체의 상태가 아니라 행동이 중요하다.

03. 역할

- 역할과 협력

역할: 책임의 집합

- 유연하고 재사용 가능한 협력

동일한 책임을 수행하는 역할을 기반으로 두 개의 협력(AmountDiscountPolicy, PercentDiscountPolicy)을 하나로 통합할 수 있다. 중복 코드 제거가 가능해진다. => 추상화(추상 클래스 or 인터페이스)

- 객체 대 역할

· 책임을 수행하는 대상이 한 종류라면 간단하게 객체로 간주. 여러 종류의 객체들이 참여할 수 있다면 역할.

- 역할과 추상화

· 세부사항에 억눌리지 않고도 상위 수준의 정책을 쉽고 간단하게 표현할 수 있다.

· 설계를 유연하게 만들 수 있다. (역할은 슬롯과 같다.)

- 배우와 배역

· 역할은 객체의 페르소나. 동일한 역할을 수행하는 하나 이상의 객체들이 존재

1. 영화 예매 시스템

2. 객체지향 프로그래밍을 향해

- 협력, 객체, 클래스

   · 어떤 객체들이 필요한지 (어떤 클래스가 필요한지 보다) 먼저 고민하라.

   · 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원으로 봐야 한다.

- 자율적인 객체(상태는 숨기고 행동만 외부에 공개)

   · 캡슐화: 데이터와 기능을 객체 내부로 함께 묶는 것

   · 접근제어: public protected, private 등 접근 수정자 제공

      · public interface: 외부에서 접근 가능한 부분

      · implementation(구현): 외부 접근 불가, 내부만 접근 가능

- 프로그래머의 자유

   · 클라이언트 프로그래머에게 필요한 부분만 공개하여, 불필요한 접근을 방지한다.

   . 클라이언트 프로그래머가 알아야 할 지식의 양이 줄어든다.(내부 구현)

   · public 영역을 변경하지 않는 범위 내에서 코드 수정이 자유로움.

   => 인터페이스와 구현을 깔끔하게 분리하기 위해 노력 필요

- 협력하는 객체들의 공동체

- 협력에 관한 짧은 이야기

3. 할인 요금 구하기

- 할인 요금 계산을 위한 협력 시작하기

- 할인 정책과 할인 조건

   · Template Method 패턴: 부모 클래스에 기본적인 알고리즘 구현, 중간에 필요한 처리를 자식 클래스에게 위임.

   . 오버라이딩: 메서드 이름 동일, 파라미터 동일

   . 오버로딩: 메서드 이름 동일, 파라미터 상이 => 각각의 메서드가 공존하고, 파라미터에 따라 다른 메서드 호출.

4. 상속과 다형성

- 컴파일 시간 의존성과 실행 시간 의존성

   · 코드의 의존성과 실행시점의 의존성이 다를 수 있다.

   · 두가지가 다를 경우 코드를 이해하기 어려워짐 => 더 유연해지고 확장 가능해짐 (트레이드오프 필요)

- 차이에 의한 프로그래밍

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

- 상속과 인터페이스

   · 상속이 가치있는 이유는 부모 클래스가 제공하는 모든 인터페이스를 자식 클래스가 물려받을 수 있기 때문

    => 업캐스팅 가능

   · 다형성

      => Movie는 동일한 메시지를 전송하지만, 실제 실행되는 메서드는 메시지를 수신하는 객체의 클래스에 의존

          (실행시간 의존성)

      => 지연바인딩(Lazy binding) or 동적 바인딩(dynamic binding)

            <=> 초기바인딩(early binding) or 정적바인딩(static binding)

      => 구현 상속 / 인터페이스 상속: 단순 코드(구현) 만 재사용할 목적으로 상속을 하면 변경에 취약한 코드 생산

            => 인터페이스 상속을 추구해야 함.

5. 추상화와 유연성

- 추상화의 힘

  · 요구정책을 높은 수준에서 서술할 수 있다.

  · 설계가 좀 더 유연해진다. 기존 구조를 수정하지 않고도 새로운 기능을 쉽게 만들 수 있다.

   => 유연성이 필요한 곳에 추상화를 사용하라.

- 유연한 설계

- 추상 클래스와 인터페이스 트레이드오프

- 코드 재사용

- 상속

  · 캡슐화를 위반한다.

  · 유연하지 않다. 

- 합성

  · 인터페이스에 정의된 메시지를 통해서만 코드를 재사용하는 방법

1. 티켓판매 애플리케이션 구현하기

2. 무엇이 문제인가

- 모든 모듈은 제대로 실행돼야 한다(o)

- 변경이 용이해야 한다(x) => 과한 의존성 => 결합도가 높다.

- 이해하기 쉬워야 한다(x)

3. 설계 개선하기

- 자율성을 높이자

   · 모든 객체가 자율적인 존재가 되도록 설계를 변경(TicketSeller, Audience 등)

   · 캡슐화 : 객체 내부의 세부적인 사항을 감추는 것 => 객체 사이의 결합도를 낮춤 => 설계 변경이 쉬워짐.

- 절차지향과 객체지향

   · 절차지향:  프로세스와 데이터를 별도의 모듈에 위치시키는 방식

   · 객체지향: 프로세스와 데이터를 동일한 모듈 내부에 위치시키는 방식. 어떤 책임을 할당할 것이냐에 초점을 맞춤

- 책임의 이동

   · 기존: 책임이 Theater에 집중됨

   · 변경: 책임이 ticketSeller, ticketOffice, audienct 에게 적절히 분배됨.

- 의인화

   · 모든 객체들이 자율적으로 행동하는 설계.

4. 객체지향 설계

- 좋은 설계: 오늘의 요구하는 기능을 온전히 수행하면서, 내일의 변경을 매끄럽게 수용할 수 있는 설계.

- 자율성 <- 결합도 낮춤 <- 캡슐화

         ㄴ<- 책임 분배 <- 의인화(자율적으로 행동)