유연한 설계
개방 폐쇄 원칙
Open Close Princle(OCP)
소프트웨어 개체는 확장에 열려있어야 하고, 수정에 대해서는 닫혀 있어야 한다.
확장에 대해 열려있다 : 기능 추가가 자유로워야 함
수정에 닫혀 있다 : 기존 '코드' 를 수정하지 않고도 애플리케이션의 동작을 추가하거나 변경할 수 있다.
컴파일 타임의 의존성을 고정시키고, 런타임 의존성을 변경하라
핵심은 추상화에 의존하는 것
핵심적인 부분만 남기고 불필요한 부분은 생략함으로써 복잡성을 극복하는 기법
추상화를 사용하면 생략된 부분을 문맥에 적합하게 채워 넣을 수 있어 좋은 설계가 된다.
모든 요소가 추상화에 의존해야 한다.
구체적인 것에 의존한다면 어지간하면 코드의 수정이 필요해진다.
올바른 추상화가 필요하다.
추상화가 수정에 수정에 닫혀 있을 수 있는 이유는 변경하지 않을 부분을 잘 선택해서 결정하고, 올바른 추상화를 선택했기 때문
Movie 내부에서 구체 클래스의 인스턴스를 생성해서는 안 된다
동일한 클래스 내에서 객체의 생성, 사용이라는 2가지 목적을 가지고 있으면 안된다
생성과 사용을 분리해야 한다.
Factory 추가하는 방법으로 분리할 수 있다.
GRASP패턴. 가장 전문가에게 맡겨라
Factory는 도메인 모델에 속하지 않고, 순수하게 기술적인 영역만을 의미한다.
표현적 분해, 행위적 분해
표현적 분해
사물, 개념을 표현하는 객체를 이용해 시스템을 분해하는 것
행위적 분해
도메인 모델은 출발점임
모든 도메인 개념을 표현하는 객체에게 책임을 할당하는 것만으로는 부족함
낮은 응집도, 높은 결합도, 재사용성 저하같은 것이 있음. 이때 가공의 객체를 Pure Fabrication(순수 가공물) 이라고 함
어떤 행동을 추가하고자 하는데, 대상이 안 보이면 Pure Fabrication을 추가하고, 책임을 할당해라
보통 이렇게행위적 분해로 작동한다.
보통 Information expert 패턴을 기준으로 세팅했을 때 결과가 마음에 들지 않는다면 이를 Pure Fabrication 으로 추가한다.
객체지향이 실세계의 모방이라는 말은 옳지 않다.
의존성 주입
사용하는 책임만 있는데, 이를 해결하는 것을 의존성 주입이라고 한다. 생성자 주입, setter주입, 메서드 주입(method call injection)
setter 주입= property injection
숨겨진 의존성은 나쁘다.
service locator를 통해서 의존성 을 해결할 수도 있다
서비스가 누구인지, 어디에 있는지를 몰라도 되게 해준다.
단점은 의존성이 숨어있어서 전혀 알 수가 없다.
의존성이 숨어있으면 모킹도 힘들다. 서로 상태가 공유되기에, 고립되어야 한다는 원칙 역시 적용이 불가능하다
depth가 깊어지거나, 의존성 지원 프레임워크 사용 불가능 할 때는 service Locator를 사용하는 것이 좋을 수 있다.
추상화와 의존성 역전
객체 간의 협력이 존재할 때 그 협력의 본질을 담고 있는 것은 상위 수준의 정책
상위 수준에 변경에 의해 하위 수준이 변경되는 것은 납득될 수 있지만, 반대는 안된다.
상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안 된다. 둘다 추상화에 의존해야 한다.
추상화는 구체적인 사항에 의존해서는 안 된다 구체적인 사항은 추상화에 의존해야 한다.
이때 패키지도 함께 고려해야 한다.
재사용 하기 위해서 패키지가 같이 배포되어야 한다.
이때 Movie와, DiscountPolicy라는 인터페이스가 같은 패키지에
Amount DiscountPolicy, Percent DiscountPolicy 가 같은 패키지에 있다면
Movie는 Movie나 DiscountPolicy 라는 인터페이스 자체가 변경될 때만 재배포 되고, 아래는 상위 수준의 하위 수준에 변경에 엮이기에 문제가 없다.
유연한 설계는 유연성이 필요할 때만 옳다.
유연하고, 재사용 가능한 설계 : 런타임 의존성과, 컴파이랕임 의존성의 차이를 인식하고 동일한 컴파일타임 의존성으로부터 다양한 런타임 의존성을 만들 수 있는 코드 구조를 의미함.
변경하기 쉽고, 확장하기 쉬운 구조의 단점은 단순함과 명확함이 없어질 가능성이 높다.
유연한 설계 이면에는 복잡한 설계라는 의미가 숨어있다.
유연한 설계=> 복잡한 설계. 파악하기 어렵다.
유연성은 복잡성을 수반한다.
클래스 구조가 동적인 구조와는 다르다는 것
생성하고 변경하는 부분들을 다 찾아봐야 한다.
불필요한 유연성은 불필요한 복잡성을 낳기에, 진짜 필요한 순간에만 잘 사용해야 한다.
가장 마지막에 생성 책임을 넘긴다.
최대한 미룬다면 그게 최고가 된다.
