공장 모드 - 전면 설계 모드

상상해봐.자동차 판매상🚗. 갑자기 그들은 업무를 확장하고 트럭을 판매하려고 했다🚛. 당신은 최초로 주문서와 판매 시스템을 프로그래밍하여 자동차를 처리했습니다.지금 뭐 해요?트럭을 전문적으로 처리하기 위해 시스템의 대부분 업무 논리를 복제하셨습니까?
물론 빠른 승리였다.얼마 후 대리판매상은 오토바이를 판매하기 시작하기로 결정했다.
🤦 아, 아니오, 더 많은 코드가 중복됩니까?만약 주문 시스템을 변경해야 한다면, 우리는 지금 세 곳에서 업데이트를 진행해야 합니까!!?
우리는 모두 가 본 적이 있다.이런 상황이 언제 일어날지 예측하기 어렵다.그러나 이렇게 할 때 해결 방안이 처음에는 재구성이 필요할 수도 있지만, 더욱 쉽게 유지보수할 수 있는 해결 방안이 있다는 것을 알아야 한다. 특히 대리판매상이 선박을 판매하기 시작할 때!🛥️
이 문서에서는 다음과 같은 내용을 다룹니다.

💪 솔루션 - 공장 모델

🤔 언제 써야 합니까?

🤯 몇 가지 장점과 단점

❓ 그것은 전방 세계에서 어디에서 응용됩니까?

🏭 예를 하나 봅시다!

💪 하나의 솔루션 - 공장 모델

공장 모델은 일종의 창조적인 디자인 모델로 통용되는 유형의 여러 대상 간의 공공 기본 행위에 추상층을 추가했다.
클라이언트 코드는 이 층의 코드를 곧 사용할 것이니 행위 실현의 세부 사항을 알 필요가 없다. 그것이 존재하기만 하면.
만약 우리가 우리의 자동차 대리판매상이 다차 대리판매상으로 바뀐 것을 예로 들면, 우리는 자동차, 트럭, 선박 간의 공통점이 모두 차량이라는 것을 볼 수 있다.대리판매상 내의 주문 시스템은 기본 차량과 함께 사용하기만 하면 되고 처리 중인 차량의 구체적인 정보를 알 필요가 없다.
이 점을 설명하기 위해 UML 그림을 빠르게 살펴보겠습니다.

그림에서 알 수 있듯이 시스템은 Vehicle 인터페이스의 구체적인 실현을 포함한다.OrderSystem 이러한 구체적인 실현이 무엇인지 모르거나 알아야 한다. 그것은 VehicleFactory에 의존하여 필요할 때 만들어서 되돌려주기 때문에 우리의 OrderSystem를 대리판매상이 판매하고자 하는 Vehicles와 분리한다!🚀🚀🚀
그들은 현재 임의의 차량으로 확장할 수 있습니다. 우리는 Vehicle 인터페이스의 새로운 실현을 만들고 VehicleFactory를 업데이트해서 그것을 만들 수 있습니다.🔥🔥🔥

🤔 언제 써야 합니까?

이러한 모드는 위에서 설명한 경우를 제외하고 다음과 같은 경우에 적합합니다.

실행할 때나 실행할 때 코드의 특정 부분에서 처리해야 할 정확한 유형이나 의존 관계의 어떤 상황도 모릅니다.

만약에 라이브러리를 개발하고 있다면 팩토리 모드를 사용하면 개발자가 원본 코드 자체에 접근할 필요가 없는 상황에서 내부 구성 요소를 확장할 수 있는 방법을 제공할 수 있습니다!

시스템 리소스를 저장해야 하는 경우 이 모드를 사용하여 새 객체가 없는 경우 새 객체를 저장하고 새 객체가 있는 경우 새 객체를 만들지 않고 에서 읽어들일 수 있습니다.

🤯 약간의 장점과 단점

이점:

공장 사용자와 구체적인 실현 간의 긴밀한 결합을 피했다.

한 구역에서 코드를 유지하는 것을 허용함으로써 어느 정도에 단일 책임 원칙을 만족시켰다.

개방/폐쇄 원칙을 충족시켜 기존 코드를 파괴하지 않는 상황에서 새로운 구체적인 실현을 허용한다.

단점:

코드 라이브러리의 복잡성과 유지보수성을 증가시킬 수 있다. 공장마다 구체적인 실현에 많은 새로운 하위 클래스가 필요하기 때문이다

❓ 그것은 전방 세계에서 어디에서 응용됩니까?

놀랍게도 Angular는 모듈 공급자 중에서 공장을 사용할 수 있도록 허락했다.개발자는 공장을 이용하여 모듈에 의존 관계를 제공할 수 있으며 프로그램이 실행될 때까지 필요한 정보를 제공할 때 공장이 매우 유용하다.
Angular Docs forFactory Providers에서 자세한 내용을 확인할 수 있습니다.

🏭 예를 하나 봅시다!

프런트엔드의 좋은 예는 플랫폼 간 UI입니다.
대화상자를 표시하는 크로스플랫폼 프로그램이 있다고 상상해 보세요.프로그램 자체가 대화상자를 렌더링하고 숨길 수 있도록 허용해야 합니다.이 대화상자는 모바일 프로그램에서 데스크톱과 다르게 나타날 수 있습니다.그러나 기능은 같아야 한다.응용 프로그램은 공장에서 실행할 때 정확한 대화상자를 만들 수 있습니다.
이 예에서는 TypeScript를 사용하여 aDialog, aMobileDialog와 aDesktopDialog의 두 가지 구현을 만들 것입니다.응용 프로그램은 사용자 프록시 문자열을 사용하여 데스크톱이나 모바일 장치에서 응용 프로그램을 볼 수 있는지 확인하고, 공장을 사용하여 정확한 대화상자를 만들 것입니다.
참고: 일반적으로 응답 대화 상자를 개발하는 것이 더 이상적이지만 Factory 모드를 보여 주는 예입니다.
먼저 기본 대화상자 인터페이스를 만듭니다

interface Dialog {
    template: string;
    title: string;
    message: string;
    visible: boolean;

    hide(): void;
    render(title: string, message: string): string;
}

이 인터페이스는 어떤 구체적인 실현도 따를 수 있는 흔한 행위와 상태를 정의한다.
다음과 같은 구체적인 실현을 만듭니다.

class MobileDialog implements Dialog {
    title: string;
    message: string;
    visible = false;

    template = `
        <div class="mobile-dialog">
            <h2>${this.title};</h2>
            <p class="dialog-content">
              ${this.message}
            </p>
        </div>
    `;

    hide() {
        this.visible = false;
    }

    render(title: string, message: string) {
        this.title = title;
        this.message = message;
        this.visible = true;

        return this.template;
    }
}

class DesktopDialog implements Dialog {
    title: string;
    message: string;
    visible = false;

    template = `
        <div class="desktop-dialog">
            <h1>${this.title};</h1>
            <hr>
            <p class="dialog-content">
              ${this.message}
            </p>
        </div>
    `;

    hide() {
        this.visible = false;
    }

    render(title: string, message: string) {
        this.title = title;
        this.message = message;
        this.visible = true;

        return this.template;
    }
}

이 기능은 약간의 미세한 변화만 있을 뿐입니다. 추상류가 이런 상황에 더 적합하다고 생각할 수 있습니다. 왜냐하면 render와 hide 방법은 같기 때문입니다.이 예에서 우리는 이 인터페이스를 계속 사용할 것이다.
이제 우리는 우리의 공장을 창설해야 한다.

class DialogFactory {
    createDialog(type: 'mobile' | 'desktop'): Dialog {
        if (type === 'mobile') {
            return new MobileDialog();
        } else {
            return new DesktopDialog();
        }
    }
}

우리 공장은 type를 채택한 후에 창립Dialog의 정확한 실현을 실현할 것이다.
마지막으로, 우리의 응용 프로그램은 우리의 공장을 소모해야 한다.

class App {
    dialog: Dialog;
    factory = new DialogFactory();

    render() {
        this.dialog = this.factory.createDialog(isMobile() ? 'mobile' : 'desktop');
        if (this.dialog.visible) {
            this.dialog.render('Hello World', 'Message here');
        }
    }
}

위의 코드를 보면 응용 프로그램이 구체적인 실현을 알 필요가 없다는 것을 알 수 있다. 반면에 논리는 DialogFactory의 책임이다.
이 코드 예제가 Factory 모드와 프런트엔드 세계에서의 잠재적 용도를 설명하는 데 도움이 되었으면 합니다.
개인적으로 저는 이런 모델의 개념과 장점을 이해하지만 그 실현에 필요한 계승에 대한 관심과 의존을 좋아하지 않습니다.
이 모델의 어떤 다른 예나 당신 자신의 관점을 마음대로 토론해 주십시오. 왜냐하면 나는 아직 결정하지 않았기 때문입니다.
질문이 있으시면 언제든지 아래 질문이나 트위터에 연락 주세요.