1장. 객체, 설계

❐ 0. 개요

---

🌀 0-1. 들어가기 앞서

이론 vs 실무

• 소프트웨어 설계와 유지보수에 중점을 두려면 이론이 아닌 실무에 초점을 마추는 것이 효과적
• 추상적인 개념과 이론은 훌륭한 코드를 작성하는 데 필요한 도구일 뿐

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

---

🌀 1-1. 요구사항

• 이벤트에 당첨된 관람객과 그렇지 못한 관람객을 구분해야 한다.
  • 이벤트에 당첨된 관람객 : 초대장을 티켓으로 교환해야 입장할 수 있다.
  • 이벤트에 당첨되지 않은 관람객 : 티켓을 구매하고 입장할 수 있다.

🌀 1-2. V1 구현

• Chap1-theater-step01

❐ 2. 무엇이 문제인가

---

🌀 2-1. 예상을 빗나가는 코드

위 코드의 문제점

1. 관람객과 판매원이 소극장의 통제를 받는 수동적인 존재라는 점
   • 소극장에서 관람객의 가방을 뒤저서 티켓 및 초대장 여부를 확인함.
   • 즉, 이해 불가능한 코드다.
   • 이해 가능한 코드란, 그 동작이 우리의 예상에서 크게 벗어나지 않는 코드
2. 이 코드를 이해하기 위해서는 아래의 세부적인 내용을 한꺼번에 알아야 한다.
   • Theater의 enter메소드를 이해하기 위해서는 Audience가 Bag를 가지고 있어야 한다.
   • Bag안에는 amount, invitation, ticket이 들어있다.
   • TicketSeller가 TicketOffice에서 티켓을 판매한다.
   • TicketOffice 안에 돈과 티켓이 보관돼 있다.

🌀 2-2. 변경에 취약한 코드

위 코드의 문제점

1. Audience와 TicketSeller를 변경하면? Theater도 변경해야 함.
2. 만약에 Bag에 현금이 없고 카드가 있다면?

이것은 객체 사이의 의존성에 관련된 문제

• 객체 사이의 의존성을 완전히 없애는 것이 정답은 아님.
• 객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것.
• 따라서 애플리케이션의 기능을 구현하는 데 필요한 최소한의 의존성만 갖도록 해야한다.

결합도 (coupling)

• 결합도는 의존성과 관련돼 있기 때문에 결합도 역시 변경과 관련이 있다.
• 객체 사이의 의존성이 과한 경우를 가리켜 결합도가 높다고 한다.

🌀 2-3. 정리

• 의도를 정확하게 의사소통하지 못하기 때문에 코드가 이해하기 어려워졌다.
• 객체각 강격합되어 있기 때문에 변경에 취약해졌다.

❐ 3. 설계 개선하기

---

🌀 3-1. 자율성을 높이자.

• 설계를 변경하기 어려운 이유는 다른 클래스의 세부까지 마음대로 접근할 수 있기 때문이다.
• 햬결 방법은 각각의 객체가 직접 처리하는 자율적인 존재가 되도록 설계를 변경하는 것이다.

캡슐화

• 이 처럼 개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것을 캡슐화라고 한다.
• 캡슐화의 목적은 변경하기 쉬운 객체를 만드는 것이다.
• 캡슐화를 통해 객체 내부로의 접근을 제한하면 객체와 객체 사이의 결합도를 낮출 수 있다.

구현과 인터페이스

• 객체를 인터페이스와 구현으로 나누고 인터페이스만을 공개하는 것은
  객체 사이의 결헙도를 낮추고 변경하기 쉬운 코드를 작성하기 위해 따라야 하는 가장 기본적인 설계 원칙이다.

🌀 3-2. 캡슐화와 응집도

핵심

• 객체 내부의 상태를 캡슐화하고, 객체 간에 오직 메시지를 통해서만 상호작용 하게 만드는 것.
• 응집도(cohesion)이 높다라는 말의 의미는
  • 밀접하게 연관된 작업만을 수행하고, 연관성없는 작업은 다른 객체에게 위임하는 객체를 가리키는 말.
• 객체의 응집도를 높이기 위해서는 자신의 데이터를 스스로 처리하는 자율적인 존재가 되어야한다.

🌀 3-3. 절차지향과 객체지향

절차적 프로그래밍

• 프로세스와 데이터를 별도의 모듈에 위치시키는 프로그램이 방식
• 이 방식은
  • 우리의 직관에 위배된다. ➔ 원활한 의사소통이 어려움.
  • 변경에 취약함.

객체지향 프로그래밍

• 프로세스와 데이터가 동일한 모듈 내부에 위치하도록 프로그래밍하는 방식
• 이 방식은
  • 적절히 통제된 의존성과 변경 전파를 억제하는데 효과적
  • 객체 간 결합도가 낮기 때문에, 절차지향에 비해 변경에 좀 더 유연함.

🌀 3-4. 절차지향과 객체지향의 근본적인 차이는? “책임”

절차지향	객체지향
한 클래스가 독재적인 책임을 가지고 있음.	책임이 여러 객체에 분산되어 있음.

🌀 3-5. 정리 및 꼭 기억할 것

• 객제지향 설계의 핵심은 적절한 객체에 적절한 역할(책임)을 부여하는 것.
• 훌륭한 객체지향 설계란 소프트웨어를 구성하는 모든 객체들이 자율적으로 행동하는 설계를 가리킨다.
• 설계를 어렵게 만드는 것은 의존성이다.
  • 따라서, 불필요한 의존성을 제거함으로써, 객체 사이의 결합도를 낮추는 것이 중요하다.
• 불필요한 세부사항을 객체 내부로 캡슐화 함으로써,
  객체의 자율성을 높이고 응집도 높은 객체들의 공동체를 창조할 수 있다.

❐ 4. 객체지향 설계

---

🌀 4-1. 설계가 왜 필요한가

좋은 설계란?

• 요구하는 기능이 온전히 동작하면서, 변경을 매끄럽게 수용할 수 있는 설계

🌀 4-2. 객체지향 설계

훌륭한 객체지향 설계란?

• 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계
• 데이터와 프로세스를 하나의 덩어리로 모으는 것은 훌륭한 객체지향 설계의 첫 걸음