오브젝트 - 유연한 설계

[yepdi]

개방-폐쇄 원칙

• 소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다.
• 확장에 대해서 열려있다 : 애플리케이션의 요구사항이 변경될 때 이 변경에 맞게 새로운 동작을 추가해서 애플리케이션의 기능을 확장할 수 있다
• 수정에 대해 닫혀있다 : 기존의 코드를 수정하지 않고도 애플리케이션의 동작을 추가하거나 변경할 수 있다

컴파일 타임 의존성을 고정시키고 런타임 의존성을 변경하라

• 런타임 의존성 : 실행시 협력에 참여하는 개체들 사이의 관계 ex. Movie와 DiscountPolicy
• 컴파일타임 의존성 : 코드에서 드러나는 클래스들 사이의 관계 ex. Movie와 AmountDiscountPolicy , Movie와 PercentDiscountPolicy

추상화가 핵심이다

• 개방-폐쇄 원칙의 핵심은 추상화에 의존하는 것.
• 생략되지 않고 남겨지는 부분은 다양한 상황에서의 공통점을 반영한 추상화의 결과물
  • 추상화 부분은 수정에 대해 닫혀 있어야 한다
• 변하는 것과 변하지 않는 것이 무엇인지를 이해하고 이를 추상화의 목적으로 삼아야 한다

생성 사용 분리

• 소프트웨어 시스템은 응용 프로그램 객체를 제작하고 의존성을 서로 연결하는 시작 단계와 시작 단계 이후에 이어지는 실행 단계를 분리해야한다
  • 클라이언트로 컨텍스트에 대한 지식을 옮김으로써 특정 클라이언트에 결합되지 않고 독립적이다 (생성에 대한 책임을 클라이언트로)

Factory 추가하기

• 생성과 사용을 분리하기 위해 객체 생성에 특화된 객체를 Factory라고 한다 (Pure Fabrication)
• 표현적 분해 : 도메인에 존재하는 사물 또는 개념을 표현하는 객체들을 이용해 시스템을 분해하는 것
  • 모든 책임을 도메인에게 할당하면 낮은 응집도 높은 결합도 재사용성 저하와 같은 심각한 문제점에 봉착할 수 있다
• Pure Fabrication : 어떤 행동을 추가하려고 하는데 행동을 책임질 마땅한 도메인 개념이 없다면 Pure Fabrication 추가하고 이 객체에게 책임을 할당하라 (행위적 분해)
• 도메인의 본질적인 개념을 표현하는 추상화를 이용해 애플리케이션을 구축하기 시작해라.
  • 만약 도메인 개념이 만족스럽지 못하다면 인공적인 객체를 창조하라

의존성 주입

• 외부의 독립적인 객체가 인스턴스를 생성한 후 이를 전달해서 의존성을 해결하는 방법

Service Locator

• 의존성을 감추기 때문에 좋지 않은 코드

  • 코드를 이해하기 어렵고 디버깅 하기 어렵다

• 의존성 주입은 클래스의 퍼블릭 인터페이스에 명시적으로 들어난다. (코드 내부를 읽을 필요가 없음)

의존성 역전 원칙

• 추상화에 의존하라 ex. Movie가 AmounctDiscountPolicy에 의존하면 안된다 DiscountPolicy에 의존해야 한다
• 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안된다. 둘 모두 추상화에 의존해야 한다
• 추상화는 구체적인 사항에 의존해서는 안된다. 구체적인 사항은 추상화에 의존해야 한다

유연성에 대한 조언

유연한 설계는 유연성이 필요할 때만 옳다

• 유연하고 재사용 가능한 설계란 런타임 의존성과 컴파일타임 의존성의 차이를 인식하고 동일한 컴파일 타임 의존성으로부터 다양한 런타임 의존성을 만들 수 있는 코드구조
  • 하지만 복잡한 설계이다 (복잡성 수반)
  • 설계가 유연할수록 클래스 구조와 객체 구조 사이의 거리는 멀어진다
• 불필요한 유연성은 불필요한 복잡성을 낳는다
  • 단순하고 명확한 해법이 그런대로 만족스럽다면 유연성을 제거하라

협력과 책임이 중요하다

• 협력에 참여하는 객체가 다른 객체에게 어떤 메시지를 전송하는지가 중요하다
• 초보자가 자주 저지르는 실수 중 하나는 객체의 역할과 책임이 자리를 잡기 전에 너무 성급하게 객체 생성에 집중하는 것
  • 객체를 생성할 책임을 담당할 객체나 객체 생성 메커니즘을 결정하는 시점은 책임 할당의 마지막 단계로 미루기