[오브젝트 - 코드로 이해하는 객체지향 설계] 1장. 객체, 설계

소프트웨어 모듈이 가져야 하는 세 가지 기능

(모듈: 크기와 상관 없이 클래스나 패키지, 라이브러리와 같이 프로그램을 구성하는 임의의 요소)

• 첫 번째 목적: 실행 중에 제대로 동작하는 것
  • 모듈의 존재 이유
• 두 번째 목적: 변경을 위해 존재하는 것
  • 대부분의 모듈은 생명주기 동안 변경되기 때문에 간단한 작업만으로도 변경이 가능해야 함.
• 세 번째 목적: 코드를 읽는 사람과 의사소통 하는 것
  • 특별한 훈련 없이도 개발자가 쉽게 읽고 이해할 수 있어야 함.

즉, 모든 모듈은 제대로 실행돼야 하고, 변경이 용이해야 하며, 이해하기 쉬워야 한다.

변경에 취약한 코드

• 의존성(dependency)
  • 의존성이 변경과 관련돼 있다.
  • 의존성은 변경에 대한 영향을 암시한다.
  • 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체도 함께 변경될 수 있다는 사실이 내포되어있음.

애플리케이션의 기능을 구현하는 데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 것이 목표

• 객체 사이의 의존성이 과한 경우를 가리켜 결합도가 높다고 말함.
• 반대로 객체들이 합리적인 수준으로 의존할 경우에는 결합도가 낮다고 말함.

설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것이어야 한다.

설계 개선하기

• 캡슐화(encapsulation)

  • 개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것
  • 목적: 변경하기 쉬운 객체를 만드는 것
  • 캡슐화를 통해 객체 내부로의 접근을 제한하면 객체와 객체 사이의 결합도를 낮출 수 있기 때문에 설계를 좀 더 쉽게 변경할 수 있게 됨.

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

캡슐화와 응집도

• 객체 내부의 상태를 캡슐화하고 객체 간에 오직 메시지를 통해서만 상호작용하도록 만드는 것이 핵심이다.

• 밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도(cohesion)가 높다고 말한다.

• 자신의 데이터를 스스로 처리하는 자율적인 객체를 만들면 결합도를 낮출 수 있을뿐더러 응집도를 높일 수 있다.

• 객체의 응집도를 높이기 위해서는 객체 스스로 자신의 데이터를 책임져야 한다.

• 객체는 자신의 데이터를 스스로 처리하는 자율적인 존재여야 한다. 그것이 객체의 응집도를 높이는 첫걸음

절차지향과 객체지향

(예시)

수정하기 전 코드

• Theater의 enter 메서드 내에서 Audience와 TicketSeller로부터 Bag과 TicketOffice를 가져와 관람객을 입장시키는 절차를 구현.
• Audience, TicketSeller, Bag, TicketOffice는 관람객을 입장시키는 데 필요한 정보를 제공하고 모든 처리는 Theater의 enter 메서드 안에 존재했었다.
• 이 관점에서 Theater의 enter 메서드는 프로세스(Process)이며 Audience, TicketSeller, Bag, TicketOffice는 데이터(Data) 다.

프로세스와 데이터를 별도의 모듈에 위치시키는 방식을 절차적 프로그래밍이라고 부른다.

• 일반적으로 절차적 프로그래밍은 우리의 직관에 위배된다.
• 절차적 프로그래밍의 세상에서는 데이터의 변경으로 인한 영향을 지역적으로 고립시키기 어렵다는 큰 문제가 있다. ⇒ 변경하기 어려운 코드를 양산하는 경향이 있다.

변경하기 쉬운 설계는 한 번에 하나의 클래스만 변경할 수 있는 설계다.

• 절차적 프로그래밍은 프로세스가 필요한 모든 데이터에 의존해야 한다는 근본적인 문제점 때문에 변경에 취약할 수 밖에 없다.
• 해결방법 → 자신의 데이터를 스스로 처리하도록 프로세스의 적절한 단계를 Audience와 TicketSeller로 이동시키는 것

객체지향 프로그래밍(Object-Oriented Programming)

• 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍하는 방식
• 핵심: 캡슐화를 이용해 의존성을 적절히 관리함으로써 객체 사이의 결합도를 낮추는 것.

책임의 이동

• 변경 전의 절차적 설계에서는 Theater(하나의 객체)가 전체적인 작업을 도맡아 처리했다.
• 변경 후의 객체지향 설계에서는 각 객체가 자신이 맡은 일을 스스로 처리했다.

이것이 책임의 이동을 의미한다.

• 객체지향 설계에서는 각 객체에 책임이 적절하게 분배된다.
• 따라서 각 객체는 자신을 스스로 책임진다.
• 객체지향 애플리케이션은 스스로 책임을 수행하는 자율적인 객체들의 공동체를 구성함으로써 완성된다.

이러한 관점에서 객체지향 프로그래밍을 데이터와 프로세스를 하나의 단위로 통합해 놓는 방식으로 표현하기도 한다.

데이터와 데이터를 사용하는 프로세스가 별도의 객체에 위치하고 있다면 절차적 프로그래밍을 따르고 있을 확률이 높고, 데이터와 데이터를 사용하는 프로세스가 동일한 객체 안에 위치한다면 객체지향 프로그래밍 방식을 따르고 있을 확률이 높다.

객체지향 설계의 핵심은 적절한 객체에 적절한 책임을 할당하는 것

• 설계를 어렵게 만드는 것은 ‘의존성’
• 불필요한 의존성을 제거함으로써 객체 사이의 결합도를 낮춰 해결하자.
• 해당 책에서 결합도를 낮추기 위해 선택한 방법은 캡슐화하는 것이다.

불필요한 세부사항을 객체 내부로 캡슐화하는 것은 객체의 자율성을 높이고 응집도 높은 객체들의 공동체를 창조할 수 있게 한다.

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

더 개선할 수 있다

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

훌륭한 객체지향 설계란 소프트웨어를 구성하는 모든 객체들이 자율적으로 행동하는 설계

객체지향 설계

설계란 코드를 배치하는 것이다.

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