Factory 패턴에 관해 궁금한 것이 있습니다.

Question

우선 패턴이라하긴 뭐하지만 Simple Factory 같은 경우 단지 객체의 생성을 도맡는 클래스 즉 공장을 하나운영하는 것으로 알고 있습니다. 그렇게되면 해당 클래스에게 객체의 생성을 맡겨 여기저기서 사용하기 때문에 코드의 중복을 막을 수 있다고 하더라구요.그런데 Factory Method Pattern 같은 경우 Simple Factory에서 객체를 생성하는 부분을 객체의 타입?별로 여러개의 서브 클래스로 나누고, 해당 서브 클래스에서 객체 생성을 하게끔 시키는 것이라고 공부했고 제가 이해한바로는 아래의 예시와 같습니다.ex) Vehicle 추상 클래스: Car, Bus, Train.. Car : RedCar, GreenCar... Bus : RedBus ..... Train ... VehicleFactory 추상 클래스 : CarMaker, BusMaker, TrainMaker.. 해당 상태에서 객체 생성은 VehicleFactory에게 요청하되 어떠한 객체를 요청했냐에 따라서생성을 CarMaker, BusMaker, TrainMaker 에서 도맡게 되는 구조. 제 생각에는 이러한 구조는 그저 VehicleFactory 클래스 하나만 운영할때와 즉 VehicleFactory 에서 타입에 따라 car, bus ,train을 모두 분기문으로 처리하여 생성해 리턴하는 구조와 크게 다를바가 없어 보입니다.그저 난무하는 If-else 분기문을 서브클래스로 나누어서 추후에 유지보수시 서브클래스만 수정/추가/삭제하는 정도?... 여러 포스팅을 읽어보니 코드의 중복을 막고 일관성이 생기며 의존성 뒤집기 원칙, 유연성이 증가한다는데 실제로 적용해보지 못해서인지 제 머리로는 Simple Factory를 Factory Method로 변경하는 것이 어떤 부분에서 크게 이득일 취하는 구조인지 모르겠습니다. 모자란 글 읽어주셔서 감사합니다.

으리으리 · Accepted Answer

제 나름 정리한 것은 1. 단순 생성만 담당할 것이면 Simple Factory로, 하나의 factory class 두고 하나의 create method(파라미터는 어떤 type을 생성할 지 지정하는 파라미터 포함)으로 시작2. 이후, 생성과 관련된 steps가 존재하고 그것들을 모아서 처리하다보니 Factory Method로 전환- instance를 생성(1)하고는 DB에 생성한 instance을 등록(2)하는 절차를 모든 type마다 처리과정이 필요하다면, Simple Factory에서 코드 중복이 발생- 생성(1)하고 DB에 등록(2)하는 것은 모든 type마다 동일하게 반드시 해줘야 한다면 abstract factory에서 해당 과정을 final로 선언해 subclass에서도 동일하게 이용하게 두면서, subclass 내부에서 수정 못하게 강제성 줄 수 있음- Template Method를 익히고 다시 Factory Method를 보면 도움될 듯 합니다.3. 생성하고자하는 classes들의 관계가 너무 많아지면, Factory Method에서 Abstract factory로 전환

대빵 · Answer

제네릭을 써서 파라미터도 받은 타입을 객체로 생성해서 리턴하면 될듯 합니다.

으리으리 · Answer

Factory Comparison (refactoring.guru) 여기서 4,5번을 참고하시면 도움 될 것 같습니다.

Factory 패턴에 관해 궁금한 것이 있습니다.

3개의 답변

Q&A 목록