2019-11-02 토요일

오브젝트

13장까지 공부 & 복습하면서 다시 정리

  • 모든 소프트웨어 모듈에는 세 가지 목적이 있다.
    1. 실행 중에 제대로 동작하는 것이다.
    2. 변경을 위해 존재하는 것이다.
    3. 코드를 읽는 사람과 의사소통하는 것이다.
  • 객체는 자율적이어야 한다.
  • 책임, 역할, 협력
  • 책임 주도 설계
  • 책임이 중요하다.
  • 정보 전문가에게 책임을 할당하라.
  • 메세지와 메서드를 구분하라.
    1. 이 클라이언트에게 필요한 메세지는? (객체간의 협력)
    2. 이 메세지를 수신할 객체는? (객체의 역할)
    3. 이 객체가 할 일은? (객체의 책임)
  • 코드가 유연해지면, 복잡도가 올라간다.
  • 유연성과 가독성을 적절하게 선택하라. (트레이드 오프)
  • 유연하게 만들고 싶다면 추상화를 해라.
  • 높은 응집도, 낮은 결합도
  • 인터페이스와 구현
  • 디미터 법칙
  • 묻지 말고 시켜라. (캡슐화)
  • CQRS
  • 컴파일, 런타임 의존성
  • What에 집중해라. How에 집중하지 말고.
  • 생성과 사용의 분리
  • 순수한 가공물에 책임을 할당하기.
  • 의존성은 Public Interface에 드러내라.
  • 유연한 설계는 유연성이 필요할 때만 옳다.
    • 우선은 직관적인 코드가 좋다.
  • 상속은 타입 계층 구현을 위해 사용하라.
  • 대부분, 상속보다는 합성이 옳다.
  • 다형성
  • 포워딩과 위임
    • 포워딩과 위임은 다른 객체에게 같은 메시지를 보낸다.
    • 위임은 컨텍스트(this, self 등)까지 전달
    • 포워딩은 그렇지 않음
  • 서브 클래싱은 중복된 코드를 야기한다.
  • 서브 타이핑을 추구하자.
  • 사전조건, 사후조건
  • 클라이언트를 생각하지 않으면, 설계는 아무런 의미가 없다.
    • 이 모든 내용은 협력이라는 컨텍스트가 없다면, 아무런 의미가 없다.
  • 설계에는 정답이 없다.
    • 규칙을 완전이 이해하고 언제 어길지를 결정해라.

객체지향의 사실과 오해

6장 정리

  • 거의 변하지 않는 비즈니스 규칙, 도메인을 기반으로 구조를 설계하라.
  • 사용자가 원하는 기능, 유스 케이스를 도메인 객체로 구현하라.

클린 코드

3장 정리

  • 함수를 작게 만들어라.
  • 함수는 딱 하나의 일만 잘하면 된다.
  • 함수 내의 모든 문장의 추상화 레벨을 같게 하라.
  • 매개변수는 적을수록 좋다.
  • 서술적인 이름