팩토리 메소드 패턴

팩토리 메소드 패턴은 어떤 상황에 자주 쓰일까?

 

우리가 생성하는 Overloading 을 한 Constructor 는 어떠한 의미를 가지기 힘들다 예를 들면 아래와 같이 말이다.

왜? 어떤 이유로 여러개의 생성자를 만들었는지 작성자 말고는 의도를 파악하기가 힘들다.

 

좀 더 자세하게 예시를 들어서 공부해보도록 하자.

아래의 코드를 한번보자. 간단하게 배를 나타내는 클래스이다.

우리는 이제 Factory Pattern 을 통해서 고객이 이름과 이메일을 넣어 주문을 넣으면 배를 만들어주는 클래스를 만들것이다.

 

Factory Class

위와 같은 클래스는 어떤 문제가 있을까?

 

우리가 만약 상품을 추가한다고 하면 계속해서 if 문을 추가해야 하는 문제점이 발생할 것이다.

계속해서 요구사항에 따른 기존 로직의 코드의 수정이 일어날 것이고, 이는 사이드 이펙트를 발생시킬 수 있다.

즉 변경에 닫혀있지 않은 코드라는 것이다. 

 

이제는 이 코드를 별개로 분리해보자

ShipFactory 라는 Interface 를 하나 만들고 기본적으로 수행해야 할 모든것들을 orderShip() 함수에 담았다.

 

여기서 주목해야 할점은 createShip() 만 인터페이스로 남겨두었는데, 그 이유는 이걸 구현하는 측에서 createShip() 만 구현함으로 써 우리는 생성로직에 대한 직접 구현과의 의존성을 줄여낼 수 있게 되는 것이다.

위와 같은 방식으로 구현하게 되며 WhiteShip 클래스는 아래와 같은 클래스로 이루어진다.

사실 이것또한.. 내부에서 static method 로 무언가 기본배를 만드는 메소드로 빼도 좋을거 같으나, 굳이 그럴 디자인패턴 공부에서 그럴 필요는 없을거 같아 하진 않았다.

 

이젠 한번 잘 만들어지는지 테스트를 해보자.

잘 테스트가 된다.

 

Factory Method 를 통해 기존의 코드를 바꾸지 않고도, 이제 우리는 추가만으로도 쉽게 확장할 수 있게 되었다.

즉 변경에는 닫혀있고, 확장에는 열려있는 OCP 원칙을 준수한 것이다.