오늘 배운 내용 2022년 5월 11일

Factory
Propósito
Problema
Solução
Estrutura
Implementação
Referencias

공장

프로포지토

Fornecer uma interface para criar objetos em uma superclasse, mas permitir que as subclasses alterem o tipo de objetos que serão criados

문제a

Se você tem um código muito acoplado a uma á uma classe em especifico, caso um dia exact adicionar uma outra classe vai ter problemas, por exemplo, uma empresa de logistica que usa somente caminhões, e o sistema está fortemente acoplado a classe de caminhão, caso algum dia queira ser implementada a classe navio isso vai gerar uma refatoração gigantesca no código

솔루션

O padrão factory sugere substituir as chamadas diretas de construção de objetos, nesse caso caminhão para um método factory e ai esse factory vai ficar responsavel por criar e retornar os objetos que nesse caso chamamos de produtos



Nesse exemplo do site refactoring guru, podemos ver que temos uma classeLogistics que contem um métodocreateTransport que é uma factory, as classesRoadLogistics eSeaLogistics implementam essa classe Logistics e modificam ocreateTransport para retornar um caminhão e um návio 리스펙티바멘테

제한 사항은 하위 클래스로 존재하며 제품마다 다른 종류의 반환 유형이 있으며 인터페이스와 인터페이스를 구현합니다. Isso ajuda para que quando o cliente faça uma chamada ele apenas precisa saber qual a interface desses produtos e pode tratar todos da mesma forma pois ele sabe que todos vão ter os mesmos métodos

에스트루투라

O Produto는 인터페이스를 구현 대상으로 선언합니다

.

O produto concreto A e B são diferentes implementações da interface Produto

A classe Creator tem um método factory que cria um produto do tipo Produto
(Apesar do nome a principal responsabilidade da classe creator não é criar produtos)

Criadores concretos sobescrevem a classe Creator para retornar diferente produtos no seus metodos factory

구현

abstract class Creator {
    public abstract factoryMethod(): Product;
    public someOperation(): string {
        const product = this.factoryMethod();
        console.log(product.opertation());
    }
}

class ConcreteCreator1 extends Creator {
    public factoryMethod(): Product {
        return new ConcreteProduct1();
    }
}

class ConcreteCreator2 extends Creator {
    public factoryMethod(): Product {
        return new ConcreteProduct2();
    }
}

os concrete creators vão extender o Creator e mudar apenas o método factory

interface Product {
    operation(): string;
}

class ConcreteProduct1 implements Product {
    public operation(): string {
        return '{Result of the ConcreteProduct1}';
    }
}

class ConcreteProduct2 implements Product {
    public operation(): string {
        return '{Result of the ConcreteProduct2}';
    }
}

function clientCode(creator: Creator) {
    console.log(creator.someOperation());
}

a partir dai o clientCode precisa apenas receber qualquer classe que extende o creator e ele tem certeza que essa classe vai ter o método someOperation que pode fazer coisas diferentes como por exemplo o no exemplo do barco e caminhão ambos podem ter o método delivery que funcionam de formas diferentes mas isso não import para oclientCode

참조

https://refactoring.guru/pt-br/design-patterns/factory-method