[Book] 오브젝트 - 01. 객체, 설계 (Object Oriented)

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

교재에서 제공한 코드를 Swift 로 번역한 코드

// MARK: - 최초 코드

---

02 무엇이 문제인가

 

예상을 빗나가는 코드

`Audience`와 `TicketSeller`가 `Theater`의 통제를 받는 수동적인 존재

우리 상식과 다르게 동작 -> 코드 이해하기 어렵다

가장 큰 문제 `Audience`와 `TicketSeller` 변경시 `Theater` 변경해야함

 

변경에 취약한코드

가방 없거나, 현금아닌 신용카드 등 다양한 가정이 깨지면 코드가 흔들림 (객체 사이의 의존성 문제)

의존성 Dependency : 어떤 객체가 변경될 때 그 객체에서 의존하는 다른 객체도 함께 변경될 수 있음

객체 사이의 "의존성이 과하다 결합도(coupling) 높다" ,  "의존성 적다 결합도가 낮다"

---

03 설계 개선하기

`Theater` 가 `Audience`의 `Bag`과 `TicketSeller`에 직접 접근하기 때문

`Audience`와 `TicketSeller`를 자율적인 존재로 만들면 되는 것

 

자율성을 높이자

// MARK: - Refactoring (1차)

 

캡슐화 (Encapsulation) : 개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것

 

독립적으로 변경 용이성이 개선됨

객체의 자율성을 높이는 방향으로 개선됨

 

캡슐화와 응집도

객체 내부 상태를 캡슐화 하고 객체간에 메시지로 상호작용

응집도 (Cohesion)가 높다 : 밀접하게 연관된 작업만 수행하고 연관성 없는 작업은 다른 객체에 위임하는 객체

객체는 자신의 데이터를 스스로 처리하는 자율적인 존재여야 함

 

훌륭한 객체 지향 설계의 핵심은 캡슐화를 이용해 의존성을 적절히 관리함으로써 객체 사이의 결합도를 낮추는 것

 

책임의 이동 (Shift of Resposibility)

각 객체는 자신을 스스로 책임

 

더 개선할 수 있다

// MARK: - Refactoring (2차)

동일한 기능은 한가지 이상의 방법으로 설계할 수 있기 때문에 결국 설계는 트레이드오프의 산물이다.

---

04 객체지향 설계

데이터와 프로세스를 하나의 덩어리로 모으는 것은 훌륭한 객체지향 설계로 가는 첫걸음일 뿐

> struct를 데이터로 class를 프로세스로 이용하는게 옳을까?

---

간단하지만 응집도, 결합도가 어떤 의미를 가지는 지

객체간의 의존도를 어떻게 고민해야하는지 배울 수 있는 챕터였다

 

코드보기 Github

iOS-Swift 관점으로 교재를 공부하고 생각을 남기는 목적입니다.
Reference By: 오브젝트

오브젝트: 코드로 이해하는 객체지향 설계