팩토리 메서드 패턴
팩토리 자체는 패턴이라기 보다는 하나의 방식? 에 불과하다. 그래서 간단한 팩토리는 따로 패턴이라고 하지 않는다. 팩토리 매서드라고 부른다.
ex)
피자클래스
{
피자 생성자 (인수) {인수에 맞춰서 변수를 배치},
변수들 (토핑들, 도우 종류, 굽기, 치즈 종류 등)
}
에서. 피자 생성자만 아예 빼버리면?
클래스 Simple피자스토어(피자를 변수로 받음)
{
생성자 (피자){피자에 맞춰서 도우나, 기타 요소 삽입하는 생성자로 매핑해줌}
}
즉, 단순한 래퍼클래스에 불과하게 된다. 그래서 팩토리 메서드라고 부르고, 탬플릿 클래스 생성자 같은 느낌이다. 예전에 PerpectForwarding 할때 그거
이렇게 생성자 부분만 빼는건 생성자 매핑해서 호출하는거에 불과하고 팩토리매서드 패턴은 팩토리메서드와 결합된 하나의 Order, Create() 메소드를 제공하는 프레임 워크같은 것.
제품에 관한 상세 정보를 각 생산자에 캡슐화 한다.
바로 가시적인 장점은 캡슐화로 코드중복을 막고 가독성이 좋아짐.
새로운 구상프로덕트가 등장하면 원래는 토핑이 4가지라면 각각에 맡게 4개의 메서드가 추가되었어야 함.
또, 코드를 직접 수정했어야만 하는데, 이제는 구상크리에이터만 수정해주면 됨
→ 추상 팩토리 메서드. 아예 피자 자체의 토핑들도 구상클래스에서 붙이도록 함.
완전히 서브클래스에게 맡겨버림. 부모는 자식이 뭘 가지는지 전혀 모름
→ 팩토리 메소드는 단순. 클래스에 맞는 서브클래스에서 정해진 대로 생산해 주는 부분만 분리.
추상 팩토리 메소드는 약간 복잡. 제품 인터페이스와 구성요소 인터페이스로 만지작 해야 함.
심플한 거 쓸때, 그냥 단순한 몇 개 그룹에서 더이상 확장되지 않을 때는 팩토리 메소드 패턴
요청 사항이 늘어나거나 변경될 것 같을 때, 재료들은 한정돼 있고 구성만 바꾸고 싶을 때 추상팩토리
→ 이러면 추상함수는 오버라이딩 하지 않는다. 공통 함수처럼 쓰니까.
경우에 맞춰서 쓰자.
