팩토리 메소드 패턴

팩토리 메소드 패턴

팩토리 메소드 패턴은 생성 디자인 패턴 중 하나로, 객체 생성을 위한 인터페이스를 제공하고 자식 클래스들이 생성될 객체의 유형을 정하도록 하는 디자인 패턴입니다.

팩토리 메소드 패턴을 사용해야 하는 이유

문제

우리가 물류 관리 앱을 개발하고 있다고 가정해봅니다. 처음 개발을 시작할 땐 트럭 운송 기능만 필요했기 때문에 대부분의 코드가 트럭 클래스에 맞춰집니다. 하지만 사업이 발전하고 트럭 뿐만 아니라 해상 운송 기능이나 항공 운송 기능도 추가해야 될 경우, 매번 새로운 클래스를 만들고 트럭에 맞춰 짜여있던 모든 코드들도 수정해야합니다.

해결

팩토리 메소드 패턴은 객체 생성을 공장(Factory) 클래스로 캡슐화 처리하여 대신 생성합니다. 직접 new 연산자를 통해 객체를 생성하는 것이 아니라, 객체들을 도맡아 생성하는 공장 클래스를 만들고, 이를 상속하는 자식 공장 클래스들의 메소드에서 여러가지 제품 객체 생성을 각각 책임 지는 것입니다.

팩토리 메소드 패턴을 통해 우리는 전체적인 코드를 손보는 대신, 새로운 자식 클래스를 생성하는 것만으로 객체를 추가할 수 있습니다.

팩토리 메소드 패턴의 장점

• 생성자와 구현 객체의 강한 결합을 피할 수 있습니다

• 개방/폐쇄 원칙을 준수합니다

  • 기존 코드를 수정하지 않고 새로운 유형의 객체를 프로그램에 도입할 수 있습니다.

• 단일 책임 원칙을 준수합니다

  • 객체 생성에 관련된 코드를 따로 부서화하여 코드를 더 쉽게 유지관리할 수 있습니다.

팩토리 메소드 패턴의 단점

• 오히려 코드가 더 복잡해질 수 있습니다.

  • 패턴을 구현하기 위해 많은 새로운 자식 클래스들을 도입해야 합니다.

활용

아래 예시는 어떻게 팩토리 메서드가 클라이언트 코드를 구상 UI 클래스들과 결합하지 않고도 크로스 플랫폼 UI 요소들을 생성할 수 있는지를 보여줍니다.

위의 Dialog 클래스는 여러 UI 요소들을 사용하여 Dialog를 렌더링합니다. 다양한 운영 체제에서 이러한 요소들은 약간씩 다르게 보일 수 있지만 여전히 같은 Dialog여야합니다. 비슷한 예로, 윈도우에서의 Button 또한 리눅스에서도 여전히 버튼이어야 합니다.

팩토리 메소드가 적용되면, 우린 대화 상자 코드를 각 운영 체제를 위하여 반복해서 재작성할 필요가 없습니다. Dialog 클래스 내에서 버튼을 생성하는 팩토리 메소드를 선언하고 해당하는 플랫폼의 버튼들을 반환하는 Dialog의 자식 클래스를 생성할 수 있습니다. Dialog로부터 코드 대부분을 상속 받는 자식 클래스는 Dialog에서 미리 선언된 메소드를 오버라이딩함으로써 해당하는 플랫폼의 버튼들도 렌더링할 수 있습니다.

_{참고 문헌}

• https://refactoring.guru/ko/design-patterns/factory-method
• https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-%ED%8C%A9%ED%86%A0%EB%A6%AC-%EB%A9%94%EC%84%9C%EB%93%9CFactory-Method-%ED%8C%A8%ED%84%B4-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EB%B0%B0%EC%9B%8C%EB%B3%B4%EC%9E%90#%ED%8C%A9%ED%86%A0%EB%A6%AC_%EB%A9%94%EC%84%9C%EB%93%9C_%ED%8C%A8%ED%84%B4%EC%9D%84_%EC%A0%81%EC%9A%A9%ED%95%9C_%EC%BD%94%EB%93%9C_%E2%9C%94%EF%B8%8F