[오브젝트] 챕터 2 - 객체지향 프로그래밍

무조건 유연한 설계도, 무조건 읽기 쉬운 코드도 정답이 아니라고 합니다.

올바른 구현이라는 망령에 시달린 것 같습니다. 상황에 따라서 트레이드 오프를 적절히 취사선택 하며 개발할 줄 아는 개발자가 되어야겠습니다.

아직 이 책에서 말하는 "적절한 책임"이 무엇인지는 잘 모르겠습니다

 

---

• 영화 예매 시스템
• 객체지향 프로그래밍을 향해
  • 클래스가 아닌 객체에 초점을 맞춰야 한다.
  • 어떤 객체가 필요한지 고민하라.
  • 협력하는 공동체의 일원으로 봐야 한다.
  <aside> 💡 객체, 협력으로 부터 클래스를 도출하라.
  • 요구사항과 프로그램을 객체라는 동일한 관점에서 바라볼 수 있다. (도메인을 따르는 프로그램)
  • 클래스를 구현하거나 사용할 때 가장 중요한 것은 클래스의 경계를 구분 짓는 것이다.
  • 객체는 상태와 행동을 함께 가지는 복합적인 존재
  • 스스로 판단하고 행동하는 자율적인 존재
  • 데이터와 기능을 객체 내부로 묶는 것을 캡슐화라고 한다.
  • 캡슐화의 목적 → 객체를 자율적인 존재로 만들기
  • 캡슐화의 장점
    • 클라이언트 프로그래머가 알아야 할 지식의 양이 줄어든다.
    • 클래스 작성자가 자유롭게 구현을 변경할 수 있는 폭이 넓어진다.
  • 우리는 인터페이스와 구현을 깔끔하게 분리하기 위해 노력해야 한다.
  <aside> 💡 모두 변경을 관리하기 위함이라는 사실을 기억하라.
  • 객체를 이용해 도메인의 의미를 풍부하게 표현할 수 있다. (Money 객체의 예)
  • 의미를 좀 더 명시적이고 분명하게 표현할 수 있다면 객체를 사용하여 구현하자.
  • 협업(Collaboration): 어떤 기능을 구현하기 위해서 객체 사이에 이뤄지는 상호작용
  • 객체지향 프로그램을 작성하기 위해서...
    1. 협력 관점에서 어떤 객체가 필여한지 결정
    2. 객체의 공통 상태와 행위를 구현하기 위해 클래스를 작성한다.
  • 객체는 다른 객체의 인터페이스에 따라 행동을 요청한다.
  • 요청 받은 객체는 알아서 처리한 후 응답한다.
    • 수신된 메시지를 처리하는 자신만의 벙법을 메서드라고 한다.
  • 메시지와 메서드의 구분에서부터 다형성의 개념이 출발한다.
    • 이게 우리에게 주는 의미는 무엇인가?
• </aside>
• </aside>
• 할인 요금 구하기
• 상속과 다형성
  • 상속과 다형성을 이용해 특정한 조건을 선택적으로 실행하는 방법
    • 딱 2개의 variation 만 있을 때 당신의 선택은? 다형성? 조건문? 왜?
  • 실행 수준에는 실제 구현체에 의존하지만, 코드 수준에서는 추상 클래스에 의존한다.
  • 코드의 의존성과 실행 시점의 의존성이 서로 다를 수 있다.
  • 코드의 의존성과 실행 시점의 의존성이 다르면 다를수록 코드를 이해하기 어려워진다.
    • 설계가 유연해질수록 코드를 이해하고 디버깅하기는 점점 더 어려워진다.
    • 항상 유연성과 가독성 사이에서 고민해야 한다.
  <aside> 💡 무조건 유연한 설계도, 무조건 읽기 쉬운 코드도 정답이 아니다.
  • 상속이 가치 있는 이유는 부모 클래스가 제공하는 모든 인터페이스를 자식 클래스가 물려받을 수 있기 때문이다.
    • 리스코프 치환 법칙와 일맥 상통하는 듯
      • 상위 타입의 객체를 하위 타입으로 치환해도 아무런 문제가 없어야한다.
      • 상위 타입을 사용하는 프로그램을 하위 타입 구현으로 사용해도 문제가 없어야한다.
  • 자식 클래스는 부모 클래스의 인터페이스를 모두 사용할 수 있기 때문에, 외부에서는 자식 클래스를 부모 클래스와 같은 타입으로 취급할 수 있다.
  • 업캐스팅: 자식 클래스가 부모 클래스를 대신하는 것
  • 다형성: 동일한 메시지를 전송하지만 실제로 어떤 메서드가 실행될 것인가를 메시지 수신 객체에 따라 정한다.
    • 동일한 메시지 수신에 대해서 다르게 응답할 수 있는 능력
  • 동적 바인딩: 메시지와 메서드를 실행 시점에 바인딩 하는 것
• </aside>
• 추상화와 유연성
  • 추상화의 계층만 따로 떼어 놓고 살펴보면 요구사항의 정책을 높은 수준에서 서술할 수 있다.
    • 높은 수준의 서술이 필요한가?
  • 추상화를 이용하면 설계가 좀 더 유연해진다.
    • 추상화를 통해 유연해지는 기능은 정말 유연해야할 필요가 있나?
  • 상위 정책을 기술하여 기본 애플리케이션의 협력 흐름을 기술
  • 추상화는 설계가 구체적인 상황에 결합되는 것을 방지한다.
  • 유연성이 필요한 곳은 어디일까?
• 코드 재사용
  • 상속은 캡슐화를 위반한다.
    • 자식 클래스는 부모 클래스의 구현에 의존한다.
  • 설계를 유연하지 못하게 만든다.
    • 부모 클래스 자식 클래스 사이의 관계를 컴파일 시점에 결정한다.
• 합성 (Composition)
• 객체지향 설계의 핵심은 적절한 협력을 식별하고 협력에 필요한 역할을 정의한 후에 역할을 수행할 수 있는 적절한 객체에 적절한 책임을 할당하는 것이다.
  • 적절한의 향연... 내가 생각하는 적절한의 의미는?