Skip to main content

1. 객체, 설계

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

티켓 판매 애플리케이션


02. 무엇이 문제인가#

  • 소프트웨어의 모듈은 세가지 목적이 있습니다.
    • 실행 중에 제대로 동작
    • 변경을 위해 존재
    • 코드를 읽는 사람과 의사소통

예상을 빗나가는 코드#

  • 이해 가능한 코드란 그 동작이 우리의 예상에서 크게 벗어나지 않는 코드입니다.
  • 코드의 많은 세부사항은 모두에게 큰 부담을 줍니다.

변경에 취약한 코드#

  • 큰 문제는 변경에 취약합니다.
  • 이는 객체 사이의 의존성(dependency) 과 관련된 문제입니다.
  • 객체 사이의 의존성이 과한 경우, 결합도(coupling) 가 높다고 합니다. 따라서 이를 낮추는 것이 필요합니다.

03. 설계 개선하기#

  • 객체를 자율적인 존재로 바꿉니다.

자율성을 높이자#

  • 개념적이나 물리적으로 객체 내부의 세부사항을 감추는 것을 캡슐화(encapsulation) 이라고 합니다.
  • 캡슐화를 개선한 후에 가장 크게 달라진 점은 내부 구현을 외부에 노출하지 않고 자신의 문제를 스스로 책임지고 해결한다는 것입니다.

무엇이 개선됐는가#

  • 수정된 코드는 변경 용이성의 측면에서도 확실히 개선됐다고 말할 수 있습니다.

어떻게 한 것인가#

  • 직관에 따라 코드를 변경이 용이하고 이해 가능하도록 수정했습니다.

캡슐화와 응집도#

  • 객체 내우의 상태를 캡슐화하고 객체 간에 오직 메시지를 통해서만 상호작용하도록 만드는 것입니다.
  • 밀접하게 연관된 작엄만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도(cohesion) 가 높다고 합니다.

절차지향과 객체지향#

  • 프로세스와 데이터를 별도의 모듈에 위치시키는 방식을 절차적 프로그래밍(Procedural Programming) 이라고 말합니다.
  • 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍하는 방식을 객체지향 프로그래밍(Object-Oriented Programming) 이라고 부릅니다.

책임의 이동#

  • 근본적인 차이를 만드는 것은 책임의 이동(shift of responsibility) 입니다.
  • 하나의 객체에 몰려있던 책임이 개별 객체로 가는 것을 책임의 이동이라고 합니다.
  • 객체 지향에서는 자신을 스스로 책임집니다.
  • 설계를 어렵게 만드는 것은 의존성입니다. 해결방법은 불필요한 의존성을 제거함으로써 객체 사이의 결합도를 낮추는 것입니다.
    • 이를 캡슐화해야하고, 객체의 자율성을 높이고 응집도 높은 객체들의 공동체가 중요합니다.

더 개선할 수 있다#

  • 설계는 균형의 예슐입니다.
  • 훌륭한 설계는 적절한 트레이드오프의 결과물입니다.

그래, 거짓말이다!#

  • 객체지향의 세계에 등어오면 모든 것이 능동적이고 자율적인 존재가 됩니다.
  • 능동적이고 자율적인 존재로 소프트웨어 객체를 설계하는 원칙을 의인화(anthropomorphism) 이라고 부릅니다.

04. 객체지향 설계#

설계가 왜 필요한가#

  • 설계란 코드를 배치하는 것입니다.
  • 변경을 수용할 수 있는 설계가 중요한 이유
    • 요구사항이 항상 변경되기 때문입니다.
    • 코드를 변경할 때 버그가 추가될 가능성이 높기 때문입니다.

객체지향 설계#

  • 진정으로 원하는 코드는 변경에 유연하게 대응할 수 있는 코드입니다.
  • 훌륭한 객체지향 설계란 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계입니다.
Edit this page
Last updated on