팩토리 패턴 - 여러 팩토리를 갖고있는 것이 좋은 생각입니까?

Question

버튼을 눌렀을 때 수행 할 특정 작업을 사용자가 지정할 수 있도록하는 시스템을 설계 중입니다. 수행 할 작업을 모든 종류의 작업에 할당 할 수 있습니다. 그래서 나는 "ButtonTask"라는 추상 기본 클래스를 가지고 있으며, 다른 모든 태스크는이베이스로부터 상속 받아 수행해야 할 작업을 구현해야한다. 이 방법으로 다형성을 사용하여 모든 세부 사항을 추상화 할 수 있습니다. 실제로 어떤 유형인지 신경 쓰지 않고도 "PerformTask"를 호출합니다. 여태까지는 그런대로 잘됐다.

실제 작업 자체는 다른 방법으로 설정할 수 있습니다. 사용자는 UI 메뉴를 사용하여 작업을 변경할 수 있으며 파일에서 작업을 읽을 수 있으며 작업은 네트워크 메시지를 통해 원격으로 설정할 수 있습니다.

현재 네트워크 메시지를 기반으로 올바른 파생 형식을 만들고 기본 형식에 대한 포인터를 반환하는 팩토리 함수가 있습니다. 문제는 UI 메뉴와 파일 읽기가 본질적으로 서로 다르므로 객체 생성을위한 자체 factory 메소드가 필요하다고 느끼는 것입니다. 이런 종류의 문제에 대해 여러 공장을 갖는 것이 일반적으로 좋은 생각입니까? 나는이 문제를 둘러싼 또 다른 방법을 생각할 수는 없지만 할 수있는 일이 더 낫다.

Answer 1

여러 팩터 리 방법을 구현하는 유일한 이유는 호출자가 일부 속성을 지정하고 다른 값을 기본값으로 설정하는 등의 초기 속성 집합을 사용하여 객체를 만들 수 있기를 원할 때입니다. 복수의 public 생성자을 가지는 것에 상당합니다.

작업이 시작된 방식 (GUI, 네트워크 등)과 관련이 없다는 생각이들 경우 별도의 팩토리 메서드가 필요하지 않습니다. 대신 공장의 의무 중 하나는 바로이 추상화를 달성하는 것이라고 말하고 싶습니다. 즉, 코드의 세 부분으로 된 동일한 팩토리를 호출하는 것이 좋습니다. 그러나 팩토리 메소드를 정적으로 만들거나 팩토리를 싱글 톤 객체로 만드는 것이 좋습니다.

반면에 특정 작업이 네트워크 및 기타 GUI에서만 시작될 수 있고 세 가지 방법으로 몇 가지 작업 만 시작할 수있는 상황이 있다면 그 작업을 다시 생각해 볼 가치가 있습니다. 조금 디자인해라. 그런 다음 CommonTask, GuiTask, NetworkTask, FileTask와 같은 다른 수준의 추상 Task 클래스를 추가하고 ButtonTask 대신 해당 팩토리를 가져야합니다. 이것은 분명히 더 복잡하며 가치가 있는지 여부는 작업 클래스 수와 코드 구조에 따라 다릅니다.

피할 수있는 것은 공장 사용자가 공장에서받을 수있는 ButtonTask의 특정 하위 클래스를 알고있는 상황입니다. 그것은 "거짓 기본 클래스"상황입니다. 즉, 기본 클래스가 하위 클래스의 전체 집합을 실제로 추상화 한 것이 아니며 위에서 설명한대로 추가 하위 클래스를 추가하여 기본 클래스를 벗어납니다.

이외에도 ButtonTask의 이름을 바꾸는 것이 좋습니다. 그것은 단지 이름에서 GUI 전용 작업처럼 들립니다.