어떤 인스턴스를 만들지는 서브 클래스가 정한다.
확장에는 열려있고 변경에는 닫혀있는 구조로 만들어보자
저번에 Refactoring에서 했던 방식과 매우 흡사함
예제는 ship을 만드는 공장이 있고 점점 확장해 나가는 예제이다.
ship을 만드는 과정의 코드들이 한곳에 다 모여있다.(orderShip)
이렇게 코드가 작성되면 변경이 있을경우 서로에게 영향을 주며 변경이 있을때마다 코드들을 전체 수정을 해줘야한다.
좀더 서로 독립적면서 나중에 확장성을 생각하며 만들어보자.
- 둘다 하위클래스에서 공통으로 사용되는것을 미리 구현해놓는다는 공통점이 있지만 default는 하위클래스에서 바로 사용가능
- private 는 하위클래스에서 오버라이드,그리고 메서드 사용불가 라 default메서드를 통해서 접근하도록 만들어 줬다.
creator(factory) 와 product간의 관계가 느슨해야 OCP(확장에 열려있고 변경에는 닫혀있는) 에 가까워진다.
팩토리메서드 방법과 매우 흡사하지만 좀더 client에 초점을 맞춘 방법.
구체적으로 어떤 인스턴스를 사용하는지 감출수 있다.
구체적인 인스턴스를 받는 부분도 문제가 될수있다. 시간이 지남에 따라 기능이 추가됨에따라 이러한 인스턴스 또한 다양하게 바뀔가능성이 있으며 그로인해 전체적인 코드가 변경될수있다.
좀더 변경에 유연하게 바꿔보자
- 클라이언트 입장에서는 concreate 클래스를 직접호출해 인스턴스를 호출하지 않고 interface(facotry)를 통해 호출한다.
둘다 객체 만드는 과정을 추상화 했다는 점은 같지만 팩토리메서드 같은 경우는 객체를 만드는 과정에 조금더 집중해있고 추상팩토리패턴은 조금더 사용하는쪽, 클라이언트쪽의 관점에서 본다.
즉 디자인패턴은 서로서로 어느정도 비슷비슷하다. 보는 관점이 다를뿐
=> 실제 우리가 사용하는 스프링에서도 이러한 방법을 찾아볼수 있다. FactoryBean에 우리가 object를 bean으로 등록해주면 스프링에서 처리를 해주고 우리가 그 objcet를 주입해 사용하는 과정이 매우 흡사함.
=> 스프링 내부코드는 변경되지 않고 직접적인 변화부분(우리가 코드를 작성해 bean 으로 등록) 해주는 부분만 변경해주면 전체코드가 바뀌는 점을보면 지금까지 배웠던 OCP에 매우 가깝다는점을 알수있다.