Java의 세 가지 팩토리 패턴은 무엇입니까?

Java의 세 가지 팩토리 패턴: 1. 특정 구현에 신경 쓰지 않고 객체 인스턴스를 생성하는 기능을 제공하는 간단한 팩토리 패턴 2. 팩토리 메소드 패턴 3. 일련의 관련 항목을 생성하는 방법을 제공하는 추상 팩토리 패턴 또는 상호 구체적인 클래스를 지정하지 않고 객체의 인터페이스에 의존합니다.

(추천 튜토리얼: Getting Started with Java Tutorial)

1. Simple Factory Pattern

간단한 팩토리의 정의: 구체적인 구현에 신경쓰지 않고 객체 인스턴스를 생성하는 기능을 제공합니다. 생성되는 인스턴스의 유형은 인터페이스, 추상 클래스 또는 콘크리트 클래스일 수 있습니다

자동차 인터페이스 구현

public interface Car {
    String getName();
}

Benz class

public class Benz implements Car {
    @Override
    public String getName() {
        return "Benz";
    }
}

BMW class

public class BMW implements Car {
    @Override
    public String getName() {
        return "BMW";
    }
}

간단한 팩토리 BMW는 메르세데스-벤츠를 다시 생산할 수 있다

public class SimpleFactory {
    public Car getCar(String name){
        if (name.equals("BMW")){
            return new BMW();
        }else if (name.equals("benz")){
            return new Benz();
        }else {
            System.out.println("不好意思，这个品牌的汽车生产不了");
            return null;
        }
    }
}

테스트 카테고리

public class SimpleFactoryTest {
    public static void main(String[] args){
        SimpleFactory simpleFactory = new SimpleFactory();
        Car car = simpleFactory.getCar("BMW");
        System.out.println(car.getName());
    }
}

테스트 결과

BMW

간단한 공장의 정의에 따르면 사용자는 제품만 원하고 제품 상태는 신경 쓰지 않습니다. 완벽해 보입니다. 그런데 생각해 보세요. 이 세상에 모든 것을 생산하는 공장이 있을까요?

분명히 존재하지 않습니다. 모든 자동차 브랜드에는 자체 생산 공장과 자체 생산 기술이 있습니다. 스프링 프레임워크에 매핑하면 생성해야 하는 많은 유형의 빈이 있습니다. 이를 구현하기 위해 간단한 팩토리에만 의존한다면 팩토리 클래스에 몇 개의 if..else if가 중첩되어야 합니까?

그리고 코드상으로는 자동차를 생산하면 그냥 새것으로 나오는데, 실제 작업에서는 얼마나 많은 작업이 필요한지 적재, 등록 및 기타 작업이 팩토리 클래스에 반영될지 알 수 없습니다. 관리가 혼란스럽고 불편하기 때문에 각 브랜드마다 고유한 생산 카테고리가 있어야 합니다.

우리는 헌신적이기 때문에 이때 공장방식이 등장합니다.

2. 팩토리 메소드 패턴

팩토리 인터페이스

//定义一个工厂接口，功能就是生产汽车
public interface Factory {
    Car getCar();
}

메르세데스 벤츠 공장

public class BenzFactory implements Factory {
    @Override
    public Car getCar() {
        return new Benz();
    }
}

BMW 공장

public class BMWFactory implements Factory{
    @Override
    public Car getCar() {
        return new BMW();
    }
}

테스트 클래스

public class FactoryTest {
   public static void main(String[] args){
       Factory bmwFactory = new BMWFactory();
       System.out.println(bmwFactory.getCar().getName());
       Factory benzFactory = new BenzFactory();
       System.out.println(benzFactory.getCar().getName());
   }
}

테스트 결과

BMW
Benz

에 따르면 위의 코드를 보면 서로 다른 브랜드의 자동차가 서로 다른 공장에서 생산되고 완벽해 보이는 것을 알 수 있습니다. 하지만 테스트 카테고리를 보면, 어떤 사람이 BMW 자동차를 사고 싶어할 때(판매자가 없다고 가정할 때) BMW 공장에 가서 자신을 위해 자동차를 생산해야 하고, 며칠 후에는 사고 싶어 합니다. 메르세데스-벤츠 자동차를 구입할 때 메르세데스-벤츠 공장에 가서 생산할 사람을 고용해야 하는데, 이는 의심할 여지 없이 사용자 작업의 복잡성을 증가시킵니다. 그렇다면 사용자 친화적인 방법은 없을까요? 이때 추상 팩토리 패턴이 등장했다.

3. 추상 공장 패턴

추상 공장

public abstract class AbstractFactory {

     protected abstract Car getCar();

     //这段代码就是动态配置的功能
     //固定模式的委派
     public Car getCar(String name){
        if("BMW".equalsIgnoreCase(name)){
            return new BmwFactory().getCar();
        }else if("Benz".equalsIgnoreCase(name)){
            return new BenzFactory().getCar();
        }else if("Audi".equalsIgnoreCase(name)){
            return new AudiFactory().getCar();
        }else{
            System.out.println("这个产品产不出来");
            return null;
        }
    }
}

기본 공장

public class DefaultFactory extends AbstractFactory {

    private AudiFactory defaultFactory = new AudiFactory();

    public Car getCar() {
        return defaultFactory.getCar();
    }

}

BMW 공장

public class BMWFactory extends AbstractFactory {
    @Override
    public Car getCar() {
        return new BMW();
    }
}

메르세데스-벤츠 공장

public class BenzFactory extends AbstractFactory {
    @Override    public Car getCar() {
            return new Benz();
    }
}

테스트 수업

public class AbstractFactoryTest {
    public static void main(String[] args) {
        DefaultFactory factory = new DefaultFactory();
        System.out.println(factory.getCar("Benz").getName());
    }
}

테스트 결과

Benz

위의 코드에서 볼 수 있듯이 사용자가 자동차가 필요한 경우 기본 공장으로 가서 요구사항(매개변수 전달)을 전달하기만 하면 됩니다. 제품별로 검색하지 않고도 원하는 제품을 생산할 수 있어 사용자가 편리하게 운영할 수 있습니다.

참고: 디자인 패턴을 비웃는 사람도 있고, 신처럼 존경하는 사람도 있지만 저는 그 의견에 동의합니다.

제가 대략적으로 이해한 바에 따르면, 디자인 패턴의 고전적인 점은 코드를 작성하는 사람과 코드를 호출하는 사람 모두의 고통을 해결한다는 것입니다. 서로 다른 디자인 패턴은 서로 다른 시나리오에만 적합합니다. 사용할 것인지, 사용하지 않을 것인지, 어떻게 사용할 것인지 등을 잘 고려하셔야 합니다.

하지만 사용을 위해 사용해서는 안 됩니다. 그 미묘함은 모두가 천천히 맛볼 수 있도록 남겨두시면 됩니다.

더 많은 프로그래밍 관련 지식을 보려면 프로그래밍 코스를 방문하세요! !

위 내용은 Java의 세 가지 팩토리 패턴은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!