01 티켓 판매 애플리케이션 구현하기
02 무엇이 문제인가?
소프트웨어의 모듈의 3가지 목적
- 제대로 실행되어야 한다.
- 변경이 용이해야 한다.
- 이해하기 쉬어야 한다.
예상을 빗나가는 코드
이해 가능한 코드란 동작이 예상에서 크게 벗어나지 않는 코드
- 관램객과 판매원이 극장의 통제를 받는다 → 예상에서 벗어남
- 관람객(Audience)과 판매원(TicketSeller)에 변화에 극장(Theater)에 영향을 받는다 → 변경에 취약한 코드
변경에 취약한 코드
- 의존성(dependency)
- 객체가 다른 객체 내부에 대해 알고 있다 → 객체간의 의존성 발생
- 객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것
- 최소한의 의존성만 유지하고 불필요한 의존성은 제거해야한다.
- 의존성(dependency)이 과한 경우 → 결합도(coupling)가 높다
- 설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것
03 설계 개선하기
자율성을 높이자
- 캡슐화(encapsulation)
- 객체 내부의 세부적인 사항을 감춰라
- 객체를 인터페이스(interface)와 구현(implementation)으로 나누고 인터페이스만을 공개
- 결합도를 낮추고 변경하기 쉬운 코드를 작성하기 위한 기본적인 설계 원칙
- 내부 구현을 외부에 노출하지 않고 자신의 문제를 스스로 책임지고 해결하게 한다.
무엇이 개선됐는가?
어떻게 한 것인가?
자신의 문제를 스스로 해결하도록 코드를 변경
캡슐화와 응집도
밀접하게 연관된 작업만 수행하고 연관성 없는 작업은 다른 객체에게 위임한다 → 응집도(cohesion)가 높다
절차 지향과 객체지향
- 객체지향 프로그래밍(Object-Oriented Programming)
- 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍하는 방식
- 객체지향 설계의 핵심
- 캡슐화를 이용해 의존성을 적절히 관리함으로써 객체 사이의 결합도를 낮추는 것
책임의 이동
- 자신을 스스로 책임지도록 책임을 이동한다.
- 데이터와 데이터를 사용하는 프로세스가 동일한 객체 안에 위치한다면 객체지향 프로그래밍 방식을 따르고 있을 확률이 높다.
- 객체가 가지는 데이터 보다는 객체에 어떤 책임을 할당할 것이냐에 초점을 맞춰야 한다.
- 결합도를 낮추자 → 캡슐화 → 캡슐화를 통해 객체의 자율성을 높이고 응집도 높은 객체들의 공동체를 만들 수 있다.
더 개선할 수 있다
- 기능을 설계하는 방법은 한가지 이상일 수 있다.
- 설계는 트레이드오프의 산물이다.(모든 사람을 만족시 킬 수 있는 설계는 없다)
그래 거지말이다!
- 현실에서 수동적이라도 객체지향의 세계에 들어오면 모든 것이 능동적이고 자율적인 존재로 바뀐다. → 의인화
- 훌륭한 객체지향 설계란 모든 객체들이 자율적으로 행동하는 설계
04 객체지향 설계
설계가 왜 필요한가
- 설계는 코드 작성의 일부
- 좋은 설계란?
- 요구하는 기능을 온전히 수행
- 변경을 매끄럽게 수용할 수 있는 설계
객체지향 설계
- 객체지향 프로그래밍 → 변경에 더 수월하게 대응할 수 있는 가능성을 높여준다
- 변경 가능한 코드란 이해하기 쉬운 코드 → 객체지향은 우리가 세상에 예상하는 방식대로 객체가 행동하는 것을 보장하여 코드를 좀 더 쉽게 이해하도록 한다.
- 훌륭한 객체지향 설계란 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계
꾸준히 나아가자 🐢