디자인 모델 - 쉽 지 않 은 공장 모델

머리말
지난 몇 시간 동안 우 리 는 하나의 모델 을 강 의 했 는데 오늘 우 리 는 또 다른 자주 사용 하 는 창설 형 모델 인 공장 모델 (Factory Design Pattern) 을 다시 이야기 했다.
일반적인 상황 에서 공장 모델 은 세 가지 더욱 세분 화 된 유형 으로 나 뉜 다. 간단 한 공장, 공장 방법 과 추상 적 인 공장 이다.실제로 이 세 가지 우리 가 가장 자주 사용 하 는 것 은 첫 번 째 간단 한 공장 과 공장 방법 모델 이다.추상 적 인 공장 의 원 리 는 약간 복잡 해서 실제 프로젝트 에서 상대 적 으로 자주 사용 되 지 않 는 다.그래서 오늘 우리 가 주로 설명 하 는 중점 은 앞의 두 가지 공장 모델 이다.
단순 공장 (Simple Factory)

//        ，           
abstract class Product{
    public abstract void Show();
}

//        （       ），         

//     A
class  ProductA extends  Product{
    @Override
    public void Show() {
        System.out.println("      A");
    }
}

//     B
class  ProductB extends  Product{

    @Override
    public void Show() {
        System.out.println("      C");
    }
}

//      ，                              
class  Factory {
    public static Product Manufacture(String ProductName){
//     switch          ；
//                            。
        switch (ProductName){
            case "A":
                return new ProductA();
            case "B":
                return new ProductB();
            default:
                return null;

        }
    }
}

위 에 있 는 간단 한 공장 의 실현 방법 을 볼 수 있 습 니 다. 만약 에 우리 가 새로운 제품 을 추가 하려 면 Factory 의 코드 로 바 꿔 야 합 니 다. 이것 은 개폐 원칙 에 위반 되 는 것 이 아 닙 니까?실제로 새로운 제품 을 자주 추가 해 야 하 는 것 이 아니라면 가끔 씩 팩 토리 코드 를 수정 하 는 것 도 개폐 원칙 에 조금 맞지 않 고 충분히 받 아들 일 수 있다.
그 밖 에 Factory 에 if 분기 판단 논리 가 있 는데 다 중 또는 다른 디자인 모델 로 대체 해 야 하 는 것 이 아 닙 니까?실제로 if 분기 가 많 지 않 으 면 코드 에 if 분기 가 있어 도 충분히 받 아들 일 수 있 습 니 다.다 중 또는 디자인 모델 을 사용 하여 if 분기 판단 논 리 를 대체 하 는 것 도 단점 이 없 는 것 이 아 닙 니 다. 코드 의 확장 성 을 향상 시 키 고 개폐 원칙 에 더욱 부합 되 지만 클래스 의 개 수 를 증가 하여 코드 의 가 독성 을 희생 합 니 다.
요약 하면 간단 한 공장 모델 의 코드 실현 에 있어 if 분기 판단 논리 가 여러 군데 있 고 개폐 원칙 에 어 긋 나 지만 확장 성과 가 독성 을 저울질 한다. 이런 코드 실현 은 대부분 상황 에서 (예 를 들 어 제품 을 자주 추가 하지 않 아 도 되 고 제품 도 많 지 않다) 문제 가 없다.
공장 방법 (공장 방법)

//       ，           
abstract class IFactory{
    public abstract Product Manufacture();
}

//  A  -   A   
class  FactoryA extends IFactory{
    @Override
    public Product Manufacture() {
        return new ProductA();
    }
}

//  B  -   B   
class  FactoryB extends IFactory{
    @Override
    public Product Manufacture() {
        return new ProductB();
    }
}

실제로 이것 이 공장 방법 모델 의 전형 적 인 코드 실현 이다.이렇게 하면 우리 가 하나의 제품 을 추가 할 때 IFactory 인 터 페 이 스 를 실현 한 Factory 류 만 추가 하면 된다.그래서 공장 방법 모델 은 단순 공장 모델 보다 개폐 원칙 에 더 부합된다.
완벽 해 보이 지만 여기 에는 작은 문제 가 있 습 니 다. 간단 한 공장 은 귀 찮 은 if 판단 을 공장 류 에서 사용자 에 게 넘 겼 습 니 다. 뭐라고 해 야 합 니까?다음 코드 를 보 겠 습 니 다.

//      
public class FactoryPattern {
    public static void main(String[] args){
        //     A
        Product mFactoryA = load("A");
        mFactoryA.Manufacture().Show();

        //     B
        Product mFactoryB = load("A");
        mFactoryB.Manufacture().Show();
    }
    
    

  public IFactory load(String factoryType) {

    IFactory factory = null;
    if ("A".equalsIgnoreCase(factoryType)) {
      factory = new FactoryA();
    } else if ("B".equalsIgnoreCase(factoryType)) {
      factory = new FactoryB();
    } else {
      throw new InvalidRuleConfigException("factoryType is not supported: " + factoryType);
    }

    return factory;
  }
}

위의 코드 실현 을 보면 공장 류 대상 의 생 성 논 리 는 load () 함수 에 결합 되 어 우리 의 최초의 코드 버 전과 매우 비슷 하 다.만약 에 우리 의 업무 수요 가 읽 은 프로필 에 따라 해당 하 는 제품 을 만 드 는 것 이 라면 간단 한 공장 모델 이 든 방법 공장 모델 이 든 상소 한 if 판단 은 없 앨 수 없다 (그래서 GoF 의 라 는 책 에서 간단 한 공장 모델 을 공장 방법 모델 의 특례 로 간주한다).
추상 공장 (추상 공장)
간단 한 공장, 공장 방법 을 말 하고 우 리 는 추상 적 인 공장 모델 을 다시 보 았 다.추상 적 인 공장 모델 의 응용 장면 은 비교적 특수 하 다. 앞의 두 가지 상용 이 없고 우리 가 배 우 는 중점 이 아니다. 우리 가 간단하게 이해 하면 된다.
우리 가 있 는 이곳 에는 필요 한 장면 이 하나 있 는데, 공장 이 하나 있 는데, 그 는 주로 용기 와 금 형 을 생산 한다.용기 와 금 형 아래 에는 또 여러 종류 가 있다.다음 과 같다.

//   
ContainerProductA 
ContainerProductB

//  
MouldProductA
MouldProductB

이런 특수 한 장면 에 대해 공장 방법 으로 계속 실현 한다 면 우 리 는 모든 제품 에 대해 공장 류 를 만들어 야 한다. 즉, 4 개의 공장 류 를 만들어 야 한다.만약 우리 가 미래 에 다른 유형의 생산 제품 (예 를 들 어 컵) 을 추가 해 야 한다 면 2 개의 공장 류 를 더 대응 해 야 한다.과도 한 유형 도 시스템 을 유지 하기 어렵 다 는 것 을 잘 알 고 있다.이 문 제 는 어떻게 해결 해 야 합 니까?
추상 적 인 공장 은 바로 이런 매우 특수 한 장면 을 겨냥 하여 탄생 한 것 이다.우 리 는 한 공장 으로 하여 금 하나의 제품 대상 만 만 드 는 것 이 아니 라 여러 종류의 대상 (용기, 금 형, 컵 등) 을 만 드 는 것 을 책임 지게 할 수 있다.이렇게 하면 공장 류 의 개 수 를 효과적으로 줄 일 수 있다.구체 적 인 코드 는 다음 과 같다.

//       ，           
abstract class Factory{
   public abstract Product ManufactureContainer();
    public abstract Product ManufactureMould();
}

//         ，           ；
abstract class AbstractProduct{
    public abstract void Show();
}

//       
abstract class ContainerProduct extends AbstractProduct{
    @Override
    public abstract void Show();
}

//       
abstract class MouldProduct extends AbstractProduct{
    @Override
    public abstract void Show();
}

//    A 
class ContainerProductA extends ContainerProduct{
    @Override
    public void Show() {
        System.out.println("        A");
    }
}

//    B 
class ContainerProductB extends ContainerProduct{
    @Override
    public void Show() {
        System.out.println("        B");
    }
}

//    A 
class MouldProductA extends MouldProduct{

    @Override
    public void Show() {
        System.out.println("        A");
    }
}

//    B 
class MouldProductB extends MouldProduct{

    @Override
    public void Show() {
        System.out.println("        B");
    }
}

//A  -     +    
class FactoryA extends Factory{

    @Override
    public Product ManufactureContainer() {
        return new ContainerProductA();
    }

    @Override
    public Product ManufactureMould() {
        return new MouldProductA();
    }
}

//B  -     +    
class FactoryB extends Factory{

    @Override
    public Product ManufactureContainer() {
        return new ContainerProductB();
    }

    @Override
    public Product ManufactureMould() {
        return new MouldProductB();
    }
}

총결산
여기 서 세 가지 공장 모델 중에서 간단 한 공장 과 공장 방법 이 비교적 자주 사용 되 고 추상 적 인 공장 의 응용 장면 이 비교적 특수 하기 때문에 거의 사용 되 지 않 는 다. 사실은 알 아 보면 된다.
창설 논리 가 비교적 복잡 하고 '큰 프로젝트' 일 때 우 리 는 공장 모델 을 사용 하고 대상 을 봉인 하 는 창설 과정 을 고려 하여 대상 의 창설 과 사용 을 분리 한다.무엇이 논 리 를 만 드 는 것 이 비교적 복잡 합 니까?

코드 에 if - else 분기 판단 이 존재 하면 동태 적 으로 서로 다른 유형 에 따라 서로 다른 대상 을 만 듭 니 다.이러한 상황 에 대해 우 리 는 공장 모델 을 사용 하여 이 커 다란 if - else 생 성 대상 의 코드 를 추출 하여 공장 류 에 넣 는 것 을 고려 합 니 다.

또 하나의 상황 은 대상 의 설립 이 매우 복잡 하 다 는 것 이다. 우 리 는 공장 류 의 방식 으로 대상 의 설립 디 테 일 (건설 자 모델 도 이런 문 제 를 해결 하 는 것) 을 차단 할 수 있다. 이런 상황 에서 우 리 는 공장 모델 을 사용 하여 대상 의 설립 과정 을 공장 류 에 밀봉 하 는 것 도 고려 할 수 있다

.
첫 번 째 상황 에 대해 모든 대상 의 창설 논리 가 비교적 간단 할 때 간단 한 공장 모델 을 사용 하여 여러 대상 의 창설 논 리 를 하나의 공장 클래스 에 넣 는 것 을 추천한다.
모든 대상 의 창설 논리 가 비교적 복잡 할 때 너무 방대 한 간단 한 공장 류 를 설계 하 는 것 을 피하 기 위해 공장 방법 모델 을 추천 하고 창설 논 리 를 더욱 세밀 하 게 나 누 어 각 대상 의 창설 논 리 를 각자 의 공장 류 에 독립 시킨다.
아니면 그 말 은 디자인 모델 을 사용 하기 위해 디자인 모델 을 사용 하지 마라. 디자인 모델 은 모두 해당 하 는 사용 장면 에서 탄생 한 것 이다.