[디자인 패턴] 팩토리 메소드 패턴

[원본 링크]

팩토리(Factory) 메소드 패턴은 말 그대로 공장처럼 무언가를 찍어내는 것을 표현한 패턴이다.

가령, 과일 인터페이스 IFruit를 두고 Apple, Banana, ...등의 구상 클래스들을 쭉 뽑아낸다고 치자.

이러한 발상과, 코드 자체는 객체지향 원칙에 위반될 것이 하등 없다.

하지만 저 구상 객체들을 생성해서 사용한다 치자.

잘 돌아가는 걸 볼 수 있다. 사실 이 자체로는 큰 문제가 없다.
다만, 저 생성 작업 자체가 구현에 맞춰 생성을 행하는 것이라는 점이, 코드의 결합도를 증가시킨다는 것이다.

만약 생성자의 형태가 바뀐다면 어떻게 할 것인가?
저 생성문이 존재하던 코드를 전부 손봐야 할 것이다.

생성 작업을 별개의 팩토리 클래스에 떠넘겨 역할을 분리하는 것이 바로 팩토리 메서드 패턴이다.

기존의 구현체들을 냅두고 팩토리 메서드를 짜보자.
팩토리 클래스를 두고, 팩토리 메서드는 정적 메서드로 구현.
그리고 객체를 생성해 인터페이스 타입으로 반환한다.
팩토리 메서드의 이름은 관례적으로 create나 make 등으로 짓곤 한다.

이러면

마찬가지로 잘 돈다.

하지만 객체의 생성 작업이 팩토리 클래스 안에 캡슐화되어있다는 것이 다를 뿐이다.
객체 생성 후 추가적으로 설정할 것이 있다면 저기서 할 수도 있다.

근데 위의 팩토리는 작지 않은 단점이 있다.
새로운 구상 클래스가 추가될때마다 메서드도 늘어나게 된다는 것인데...
이건 어쩔 수 없는 팩토리 패턴 자체의 고질적인 한계점이다.

메서드를 늘리고 싶지 않다면 메서드를 하나로 합치고, 열거체로 타입을 식별해서 생성하게 할 수도 있다.

이렇게.

저기서 식별용 인자를 열거 대신 문자열로 바꾼다면,
클래스를 추가할 때마다 열거도 추가해야 하는 불편함을 덜 수 있을 것이다.
하지만 유연성이 약간 증가하는 대신 텍스트를 잘못 치면 오류가 발생하는 위험이 있다...

여튼 그렇다.


참조
[헤드퍼스트 디자인 패턴]
[클린 소프트웨어]
https://ko.wikipedia.org/wiki/%ED%8C%A9%ED%86%A0%EB%A6%AC_%EB%A9%94%EC%84%9C%EB%93%9C_%ED%8C%A8%ED%84%B4