[Object] 객체와 설계

객체와 설계

객체지향적 사고와 프로그래밍을 위해 Object라는 책을 읽고 정리하는 과정입니다.
코드의 경우 Github 커밋에 대한 링크를 이용합니다.

before code: Github commit
after code: Github commit

영화관의 티켓 판매를 예시로 하는 코드이다.

예상을 빗나가는 코드

• 이해 가능한 코드: 동작이 예상에서 크게 벗어나지 않는 코드.
• 예상을 빗나가는 코드란 이해 가능한 코드가 아니라는 것이다.
• before code Theater의 enter 메서드
  • 각각의 객체 내에서 해야할 것 같은 행위들이 모두 enter 메서드 내에서 진행된다.

변경에 취약한 코드

• 의존성: 변경에 대한 영향을 암시한다.
  • 어떤 객체가 변경될 때 그 개체에게 의존하는 다른 객체도 함께 변경될 수 있다.
• 변경에 취약한 코드란 의존성이 과할 때 나타나는 것
• 객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것이다.
  • 애플리케이션의 기능을 구현하는 데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거해야 한다.
• 결합도가 높다: 객체 사이의 의존성이 과하다.
  • 두 객체 사이의 결합도가 높으면 높을수록 함께 변경될 확률도 높아지기 때문에 변경하기 어려워진다.
• 예를 들어 Audience의 코드가 변경되어야 할 때, Theater의 enter메서드로 인해 전혀 관련없는 Theater 클래스의 코드도 변경되어야 한다.

자율성을 높이자

• 캡슐화: 개념적, 물리적으로 객체 내부의 세부적인 사항을 감추는 것
  • 캡슐화의 목적은 변경하기 쉬운 객체를 만드는 것이다.
  • 캡슐화를 통해 객체 내부로의 접근을 제한하면 객체와 객체 사이의 결합도를 낮출 수 있기 때문에 설계를 더 쉽게 변경할 수 있다.
• 응집도가 높다: 밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임할 때
  • 객체의 응집도를 높이기 위해서는 객체 스스로 자신의 데이터를 책임져야 한다.
• 객체는 자율적인 존재가 되도록 설계해야 한다.

캡슐화는 가급적 setter 메서드를 사용하지 않는 것과 같다고 생각했다.
객체 내의 내부 구현을 외부에 노출하지 않고, 자신의 문제를 직접 책임지고 해결함으로써 자율적인 존재가 된다.

절차지향과 객체지향

• 절차적 프로그래밍: 프로세스와 데이터를 별도의 모듈에 위치하는 방식
  • 기존의 코드에서 Teater의 enter메서드는 프로세스(Process)이며, 나머지 객체는 데이터(Data)이다.
• 객체지향 프로그래밍: 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍 하는 방식
  • 변경된 코드에서 모든 객체는 프로세스이며, 데이터이다.
  • 훌륭한 객체지향 설계의 핵심은 캡슐화를 이용해 의존성을 적절히 관리함으로써 객체 사이의 결합도를 낮추는 것이다.

책임의 이동

• 절차지향과 객체지향 사이의 근본적인 차이를 만드는 것이 책임의 이동이다.
• 기존의 코드에서 Theater은 모든 책임이 집중되어 있다.
• 변경된 코드를 통해 Theater에 있던 책임은 다음 객체로 넘어가 책임이 이동된다.
• 따라서 각 객체는 자신을 스스로 책임진다.

훌륭한 객체지향 설계란?

불필요한 세부사항을 캡슐화하는 자율적인 객체들이 낮은 결합도와 높은 응집도를 가지고 협력하도록 최소한의 의존성만을 남기는 것

1. 불필요한 의존성을 제거하여
2. 객체 사이의 결합도를 낮춘다.
3. 결합도를 낮추기 위해 캡슐화를 이용하고
4. 캡슐화 하는 것은 자율성을 높이고 응집도 높은 객체를 만드는 것이다.

결과적으로

• 이러한 방식의 의존성 제거는 마지막에 가서 완전하게 제거되지 않는다.

1. 어떤 기능을 설게하는 방법은 한 가지 이상일 수 있다.
2. 동일한 기능을 한 가지 이상의 방법으로 설계할 수 있기 때문에 결국 설계는 트레이드오프의 산물이다.
3. 어떤 경우에도 모든 사람들을 만족시킬 수 있는 설계를 만들 수는 없다.