Java 디자인 패턴의 팩토리 패턴 소개(코드 예)-java지도 시간-php.cn

Java 디자인 패턴의 팩토리 패턴 소개(코드 예)

不言

풀어 주다： 2018-09-12 15:54:24

원래의

1851명이 탐색했습니다.

이 기사는 Java 디자인 패턴(코드 예제)에서 팩토리 패턴을 소개하며, 도움이 필요한 친구들이 참고할 수 있기를 바랍니다.

머리말

이전 글에서는 싱글턴 패턴에 대해 알아보고, 싱글턴 패턴을 만드는 여러 가지 방법과 최적의 방법을 소개했습니다. 본 글에서는 디자인 패턴 중 팩토리 패턴을 소개하고 있는데, 크게 단순 팩토리 패턴, 팩토리 메소드, 추상 팩토리 패턴으로 나누어진다.

간단한 팩토리 패턴

간단한 팩토리 패턴은 생성 패턴으로, 정적 팩토리 메서드 패턴이라고도 합니다. 단순 팩토리 패턴은 팩토리 객체를 사용하여 생성할 제품 클래스 인스턴스를 결정합니다. 호출은 필요한 유형을 팩토리 클래스에 알려주기만 하면 되며, 팩토리 클래스는 제품 클래스 팩토리의 필수 하위 클래스를 반환합니다. 팩토리 패턴 중 가장 간단한 패턴이라고 할 수 있습니다.

예를 들어, 우리는 컴퓨터에서 게임을 하는 경우가 많습니다. 컴퓨터에 어떤 게임을 하고 싶은지 알려주기만 하면 컴퓨터가 게임을 열어줄 것입니다.
다음 코드에서 그에 따라 설명할 수 있습니다.

먼저 게임 플레이 방법을 포함하는 게임 일반 클래스 인터페이스를 생성한 다음 각 게임 클래스가 이 클래스를 상속하고 이 클래스의 메서드를 구현한 다음 마지막으로 다양한 게임에 따라 객체를 생성하는 엔지니어링 클래스를 생성합니다.
그러면 구현된 코드는 다음과 같습니다.

코드 예:

    private static final String LOL="LOL"; 
    private static final String DNF="DNF"; 
    
    public static void main(String[] args) {
        Game game= ComputerFactory.playGame(LOL);
        Game game2= ComputerFactory.playGame(DNF);
        game.play();
        game2.play();
    }
}

interface Game{
    void play();
}

class LOL implements Game{
    @Override
    public void play() {
        System.out.println("正在玩LOL...");
    }   
}

class DNF implements Game{
    @Override
    public void play() {
        System.out.println("正在玩DNF...");
    }   
}


class ComputerFactory{
    private static final String LOL="LOL"; 
    private static final String DNF="DNF"; 
     public static Game playGame(String game){
         if(LOL.equalsIgnoreCase(game)){
             return new LOL();
         }else if(DNF.equalsIgnoreCase(game)){
             return new DNF();
         }
         return null;
     }

로그인 후 복사

출력 결과:

正在玩LOL...
正在玩DNF...

로그인 후 복사

간단한 팩토리 패턴을 사용하여 이 기능을 구현한 후 게임의 인스턴스화를 넣는 것을 알 수 있습니다. 클래스를 팩토리 클래스에 구현하면 객체 생성의 세부 정보가 숨겨지므로 재생 방법을 알 필요가 없으며 팩토리 클래스를 호출하는 방법만 알면 됩니다. 그리고 팩토리 클래스에서 전달한 타입 값만 변경하면 되므로 전환이 편리합니다.
하지만 문제도 발견했습니다. 새로운 게임 클래스를 추가해야 한다면 새로운 인터페이스를 정의한 다음 팩토리 클래스에 판단 브랜치를 추가해야 합니다. 금액이 크면 더 번거로울 것입니다. 그리고 이것은 또한 개방 폐쇄 원칙에도 위배됩니다.

Factory Method Pattern

Factory Method Pattern은 Java에서 가장 일반적으로 사용되는 디자인 패턴 중 하나이며 생성 패턴입니다. 객체를 생성하기 위한 인터페이스를 정의하고 해당 하위 클래스가 인스턴스화할 팩토리 클래스를 결정하도록 합니다. 팩토리 패턴은 하위 클래스가 나올 때까지 생성 프로세스를 지연시킵니다.

간단한 팩토리 패턴에서 우리는 하위 클래스를 추가할 때 팩토리 클래스에 판단 분기도 추가해야 한다는 점을 발견했는데, 이는 개방형 폐쇄 원칙을 위반하는 것입니다. 팩토리 메소드 패턴은 주로 이 문제를 해결합니다.

여기에 있는 각 게임이 자체 게임 팩토리 클래스로 구현된다는 점을 제외하면 위의 게임 플레이 예가 여기서도 계속 사용됩니다. 주요 차이점은 하나가 아닌 여러 개의 팩토리 클래스가 있어 결합 정도가 줄어든다는 점입니다. 새로운 게임 클래스를 추가하는 경우 팩토리 클래스만 추가하면 되며 개방형 폐쇄 원칙이 완벽하게 준수됩니다.

위 코드를 변경하면 해당 코드는 다음과 같이 구현됩니다.

코드 예시:

    private static final String LOL="LOL"; 
    private static final String DNF="DNF"; 
    private static final String WOW="WOW"; 

    public static void main(String[] args) {

        Game game3=new LOLFactory().playGame(LOL);
        Game game4=new DNFFactory().playGame(DNF);
        Game game5=new WOWFactory().playGame(WOW);
        game3.play();
        game4.play();
        game5.play();       
    }
    
interface Game{
    void play();
}


class LOL implements Game{
    @Override
    public void play() {
        System.out.println("正在玩LOL...");
    }   
}

class DNF implements Game{
    @Override
    public void play() {
        System.out.println("正在玩DNF...");
    }   
}

class WOW  implements Game{
    @Override
    public void play() {
        System.out.println("正在玩WOW...");
    }   
}


interface ComputerFactory2{
    Game playGame(String game);
}

class LOLFactory implements ComputerFactory2{
    @Override
    public Game playGame(String game) {
        return new LOL();
    }
}

class DNFFactory implements ComputerFactory2{
    @Override
    public Game playGame(String game) {
        return new DNF();
    }
}

class WOWFactory implements ComputerFactory2{
    @Override
    public Game playGame(String game) {
        return new WOW();
    }
}

로그인 후 복사

출력 결과:

正在玩LOL...
正在玩DNF...
正在玩WOW...

로그인 후 복사

팩토리 메소드 패턴을 사용하고 나면 코드가 더 명확해지고 확장성이 좋아지는 것을 볼 수 있습니다. 또한 높은 수준에서 제품을 추가하려면 팩토리 클래스만 확장하면 됩니다. 하지만 제품이 추가될 때마다 구체적인 클래스와 객체 구현 팩토리 클래스를 추가해야 하므로 시스템의 복잡성이 증가합니다.
그래서 이 모드를 사용할지 여부에 주의가 필요합니다.
이 패턴을 사용하는 전형적인 사용 사례는 데이터베이스 방언을 선택할 때 유명한 hibernate프레임워크입니다. 하지만 단순히 객체를 새로 만들면 사용할 필요가 없으며 사용하면 시스템이 더 복잡해집니다.

추상 팩토리 패턴

추상 팩토리 패턴은 슈퍼 팩토리 주변에 다른 팩토리를 만드는 것입니다. 기가팩토리는 다른 공장 중의 공장이라고도 불립니다. 이러한 유형의 디자인 패턴은 객체를 생성하는 최적의 방법을 제공하는 생성 패턴입니다. 즉, 특정 클래스를 지정하지 않고 일련의 관련되거나 상호 의존적인 개체를 생성하기 위한 인터페이스를 제공합니다.

추상 팩토리 패턴은 팩토리 메서드 패턴보다 더 복잡하고 이해하기 어렵지만 확장하기는 더 쉽습니다.
추상 팩토리 패턴은 동일한 유형의 제품 하위 카테고리를 하나의 카테고리로 그룹화하고 동일한 추상 하위 카테고리를 상속한 다음 이를 하나의 그룹으로 처리한 다음 여러 그룹을 하나의 제품군으로 그룹화합니다.
예를 들어, 위의 게임을 계속 플레이한다면 LOL 및 WOW를 PVP 유형의 게임으로 생각할 수도 있고, DNF 및 WOW를 PVE 유형의 게임으로 생각할 수도 있습니다.

그러면 해당 변경 코드는 다음과 같습니다.

코드 예:

    private static final String LOL="LOL"; 
    private static final String DNF="DNF"; 
    private static final String WOW="WOW"; 
    
    public static void main(String[] args) {

        ComputerFactory3 cf3=new PVPFactory();
        cf3.playGame().play();
        cf3.playGame2().play();
        ComputerFactory3 cf4=new PVEFactory();
        cf4.playGame().play();
        cf4.playGame2().play();         
    }       
}


interface Game{
    void play();
}


class LOL implements Game{
    @Override
    public void play() {
        System.out.println("正在玩LOL...");
    }   
}

class DNF implements Game{
    @Override
    public void play() {
        System.out.println("正在玩DNF...");
    }   
}

class WOW  implements Game{
    @Override
    public void play() {
        System.out.println("正在玩WOW...");
    }   
}


interface ComputerFactory3{
     Game playGame();
     Game playGame2();
}

class PVPFactory implements ComputerFactory3{

    @Override
    public Game playGame() {
        return new LOL();
    }

    @Override
    public Game playGame2() {
        return new WOW();
    }   
}

class PVEFactory implements ComputerFactory3{

    @Override
    public Game playGame() {
        return new DNF();
    }

    @Override
    public Game playGame2() {
        return new WOW();
    }
    
}

로그인 후 복사

출력 결과:

正在玩LOL...
正在玩WOW...
正在玩DNF...
正在玩WOW...

로그인 후 복사

在抽象工厂模式中，可以在不需要知道产品是怎么样的，只需知道是哪个工厂类就行了。我们也可以根据子类的共同的特性而将它们设计在一起，组成一个相同类型组，可以很方便的直接调用。但是相对的，产品族比较难以扩展，增加一个产品，需要增加相应的接口和实现类。例如某个品牌的手机，有不同系列，每个系列有不同的型号，如果只是增加型号的话，比较容易，但是相对的，增加某个系列就比较麻烦了。
所以我们在使用抽象工厂模式，也需要相应的结合实际场景来使用。