logo

TechCodeview

Mètode de fàbrica Patró de disseny

El patró de disseny del mètode de fàbrica és a patró de disseny creatiu que proporciona una interfície per crear objectes en una superclasse, permetent que les subclasses alterin el tipus d'objectes que es crearan. Encapsula la lògica de creació d'objectes en un mètode separat, promovent un acoblament fluix entre el creador i els objectes creats. Aquest patró és especialment útil quan els tipus exactes d'objectes que s'han de crear poden variar o s'han de determinar en temps d'execució, la qual cosa permet flexibilitat i extensibilitat en la creació d'objectes.

Taula de contingut



Què és el patró de disseny del mètode de fàbrica?

El Factory Method Design Pattern és un patró de disseny de creació utilitzat en enginyeria de programari per proporcionar una interfície per crear objectes en una superclasse, alhora que permet que les subclasses alterin el tipus d'objectes que es crearan. Encapsula la lògica de creació d'objectes en un mètode separat, abstraint el procés d'instanciació i promovent un acoblament fluix entre el creador i els objectes creats. Aquest patró permet flexibilitat, extensibilitat i manteniment a la base de codi, ja que permet a les subclasses definir la seva pròpia implementació del mètode de fàbrica per crear tipus específics d'objectes.

alineació de text css

Quan utilitzar el patró de disseny del mètode de fàbrica?

Utilitzeu el patró de disseny del mètode de fàbrica:

  • Quan voleu encapsular la creació d'objectes: Si teniu un procés de creació d'objectes complex o si el procés pot variar segons les condicions, encapsular aquesta lògica en un mètode de fàbrica pot simplificar el codi del client i promoure la reutilització.
  • Quan voleu desacoblar el codi de client de classes concretes: L'ús del patró del mètode de fàbrica us permet crear objectes mitjançant una interfície o classe abstracta, abstraint els detalls específics d'implementació de les classes concretes del codi del client. Això promou l'acoblament fluix i fa que sigui més fàcil modificar o ampliar el sistema sense afectar el codi de client existent.
  • Quan necessiteu suportar diverses variacions de producte: Si la vostra aplicació necessita crear diferents variacions d'un producte o si es poden introduir nous tipus de productes en el futur, el Patró del mètode de fàbrica ofereix una manera flexible d'adaptar-se a aquestes variacions definint mètodes de fàbrica per a cada tipus de producte.
  • Quan vulgueu donar suport a la personalització o la configuració: Les fàbriques es poden utilitzar per encapsular la lògica de configuració, permetent als clients personalitzar el procés de creació proporcionant paràmetres o opcions de configuració al mètode de fàbrica.

Components del patró de disseny del mètode de fàbrica

1. Creador

Aquesta és una classe abstracta o una interfície que declara el mètode de fàbrica. El creador normalment conté un mètode que serveix com a fàbrica per crear objectes. També pot contenir altres mètodes que funcionen amb els objectes creats.

2. Creador concret

Les classes de Concrete Creator són subclasses del Creator que implementen el mètode de fàbrica per crear tipus específics d'objectes. Cada Concrete Creator és responsable de crear un producte concret.

3. Producte

Aquesta és la interfície o classe abstracta per als objectes que crea el mètode de fàbrica. El Producte defineix la interfície comuna per a tots els objectes que el mètode de fàbrica pot crear.

4. Producte concret

Les classes de producte concret són els objectes reals que crea el mètode de fàbrica. Cada classe de producte concret implementa la interfície Producte o amplia la classe abstracta Producte.

descarregar youtube amb vlc

Exemple de patró de disseny del mètode de fàbrica

A continuació es mostra la declaració del problema per entendre el patró de disseny del mètode de fàbrica:

Penseu en una aplicació de programari que necessiti gestionar la creació de diversos tipus de vehicles, com ara vehicles de dues rodes, vehicles de tres rodes i vehicles de quatre rodes. Cada tipus de vehicle té les seves pròpies propietats i comportaments específics.

1. Sense patró de disseny del mètode de fàbrica

Java 
/*package whatever //do not write package name here */ import java.io.*; // Library classes abstract class Vehicle {  public abstract void printVehicle(); } class TwoWheeler extends Vehicle {  public void printVehicle() {  System.out.println('I am two wheeler');  } } class FourWheeler extends Vehicle {  public void printVehicle() {  System.out.println('I am four wheeler');  } } // Client (or user) class class Client {  private Vehicle pVehicle;  public Client(int type) {  if (type == 1) {  pVehicle = new TwoWheeler();  } else if (type == 2) {  pVehicle = new FourWheeler();  } else {  pVehicle = null;  }  }  public void cleanup() {  if (pVehicle != null) {  pVehicle = null;  }  }  public Vehicle getVehicle() {  return pVehicle;  } } // Driver program public class GFG {  public static void main(String[] args) {  Client pClient = new Client(1);  Vehicle pVehicle = pClient.getVehicle();  if (pVehicle != null) {  pVehicle.printVehicle();  }  pClient.cleanup();  } }>
Sortida 
I am two wheeler>

Quins són els problemes amb el disseny anterior?

En el disseny del codi anterior:

  • Acoblament estret: La classe clientClient>instantà directament les classes concretes (TwoWheeler>iFourWheeler>) en funció del tipus d'entrada proporcionat durant la seva construcció. Això condueix a un acoblament estret entre el client i les classes concretes, fent que el codi sigui difícil de mantenir i ampliar.
  • Violació del principi de responsabilitat única (SRP): ElClient>La classe és responsable no només de determinar quin tipus de vehicle s'ha d'instanciar en funció del tipus d'entrada, sinó també de gestionar el cicle de vida de l'objecte del vehicle (p. ex., neteja). Això viola el Principi de Responsabilitat Única, que estableix que una classe només hauria de tenir una raó per canviar.
  • Escalabilitat limitada: Per afegir un nou tipus de vehicle cal modificar elClient>classe, que viola el principi d'obert-tancat. Aquest disseny no és escalable perquè no pot acomodar nous tipus de vehicles sense modificar el codi existent.

Com evitem el problema?

  • Definiu la interfície de fàbrica: Crea unVehicleFactory>interfície o classe abstracta amb un mètode per crear vehicles.
  • Implementar fàbriques de formigó: Implementar classes de fàbrica de formigó (TwoWheelerFactory>iFourWheelerFactory>) que implementen elVehicleFactory>interfície i proporcionar mètodes per crear instàncies de tipus específics de vehicles.
  • Client de refactor: Modificar elClient>classe per acceptar aVehicleFactory>instància en lloc d'instanciar directament els vehicles. El client sol·licitarà un vehicle a la fàbrica, eliminant la necessitat d'una lògica condicional basada en els tipus de vehicle.
  • Flexibilitat millorada: Amb aquest enfocament, afegir nous tipus de vehicles és tan senzill com crear una nova classe de fàbrica per al nou tipus de vehicle sense modificar el codi de client existent.

2. Amb el patró de disseny del mètode de fàbrica

Desglossem el codi en codi per components:

Factory MethodDesignPattern

1. Interfície de producte

Java 
// Product interface representing a vehicle public abstract class Vehicle {  public abstract void printVehicle(); }>

2. Productes de formigó

Java 
// Concrete product classes representing different types of vehicles public class TwoWheeler extends Vehicle {  public void printVehicle() {  System.out.println('I am two wheeler');  } } public class FourWheeler extends Vehicle {  public void printVehicle() {  System.out.println('I am four wheeler');  } }>

3. Interfície de creador (interfície de fàbrica)

Java 
// Factory interface defining the factory method public interface VehicleFactory {  Vehicle createVehicle(); }>

4. Creadors de formigó (fàbriques de formigó)

Java 
// Concrete factory class for TwoWheeler public class TwoWheelerFactory implements VehicleFactory {  public Vehicle createVehicle() {  return new TwoWheeler();  } } // Concrete factory class for FourWheeler public class FourWheelerFactory implements VehicleFactory {  public Vehicle createVehicle() {  return new FourWheeler();  } }>

Codi complet d'aquest exemple:

Java 
// Library classes abstract class Vehicle {  public abstract void printVehicle(); } class TwoWheeler extends Vehicle {  public void printVehicle() {  System.out.println('I am two wheeler');  } } class FourWheeler extends Vehicle {  public void printVehicle() {  System.out.println('I am four wheeler');  } } // Factory Interface interface VehicleFactory {  Vehicle createVehicle(); } // Concrete Factory for TwoWheeler class TwoWheelerFactory implements VehicleFactory {  public Vehicle createVehicle() {  return new TwoWheeler();  } } // Concrete Factory for FourWheeler class FourWheelerFactory implements VehicleFactory {  public Vehicle createVehicle() {  return new FourWheeler();  } } // Client class class Client {  private Vehicle pVehicle;  public Client(VehicleFactory factory) {  pVehicle = factory.createVehicle();  }  public Vehicle getVehicle() {  return pVehicle;  } } // Driver program public class GFG {  public static void main(String[] args) {  VehicleFactory twoWheelerFactory = new TwoWheelerFactory();  Client twoWheelerClient = new Client(twoWheelerFactory);  Vehicle twoWheeler = twoWheelerClient.getVehicle();  twoWheeler.printVehicle();  VehicleFactory fourWheelerFactory = new FourWheelerFactory();  Client fourWheelerClient = new Client(fourWheelerFactory);  Vehicle fourWheeler = fourWheelerClient.getVehicle();  fourWheeler.printVehicle();  } }>
Sortida 
I am two wheeler I am four wheeler>

En el codi anterior:

llarg a int java
  • Vehicle> serveix com a interfície del producte, definint el mètode comú printVehicle()> que tots els productes concrets han d'implementar.
  • TwoWheeler> i FourWheeler> són classes de productes concrets que representen diferents tipus de vehicles, implementant el printVehicle()> mètode.
  • VehicleFactory> actua com a interfície Creator (Factory Interface) amb un mètode createVehicle()> que representa el mètode de fàbrica.
  • TwoWheelerFactory> i FourWheelerFactory> són classes de creadors concrets (Fàbriques de formigó) que implementen el VehicleFactory> interfície per crear instàncies de tipus específics de vehicles.

Casos d'ús del patró de disseny del mètode de fàbrica

A continuació es mostren algunes aplicacions habituals del patró Factory Method Design:

  • Marcs de creació:
    • JDBC (Java Database Connectivity) utilitza àmpliament les fàbriques per crear connexions, declaracions i conjunts de resultats. Els marcs d'injecció de dependència com Spring i Guice depenen molt de les fàbriques per crear i gestionar beans.
  • Kits d'eines GUI:
    • Swing i JavaFX utilitzen fàbriques per crear components d'interfície d'usuari com botons, camps de text i etiquetes, cosa que permet la personalització i la flexibilitat en el disseny de la interfície d'usuari.
  • Marcs de registre:
    • Els marcs de registre com Log4j i Logback utilitzen fàbriques per crear registradors amb diferents configuracions, cosa que permet controlar els nivells de registre i les destinacions de sortida.
  • Serialització i deserialització:
    • Els marcs de serialització d'objectes sovint utilitzen fàbriques per crear objectes a partir de dades serialitzades, donant suport a diferents formats de serialització i versions.
  • Sistemes de connectors:
    • Els sistemes basats en connectors sovint utilitzen fàbriques per carregar i crear instàncies de connectors de forma dinàmica, cosa que permet l'extensibilitat i la personalització.
  • Desenvolupament del joc:
    • Els motors de joc sovint utilitzen fàbriques per crear diferents tipus d'objectes, personatges i nivells de joc, promovent l'organització i la flexibilitat del codi.
  • Desenvolupament web:
    • Els marcs web de vegades utilitzen fàbriques per crear components de visualització, controladors i serveis, la qual cosa permet la modularitat i la provabilitat a les aplicacions web.

Avantatges del patró de disseny del mètode de fàbrica

Els avantatges del patró de disseny del mètode de fàbrica són:

tipus d'aprenentatge automàtic
  • Desacoblament: Separa la lògica de creació d'objectes del codi de client que utilitza aquests objectes. Això fa que el codi sigui més flexible i fàcil de mantenir perquè els canvis al procés de creació no requereixen modificacions al codi del client.
  • Extensibilitat: És fàcil introduir nous tipus de producte sense canviar el codi del client. Només cal que creeu una nova subclasse de Concrete Creator i implementeu el mètode de fàbrica per produir el nou producte.
  • Testabilitat: Simplifica les proves d'unitats, ja que us permet burlar-vos o eliminar la creació de productes durant les proves. Podeu provar diferents implementacions de productes de manera aïllada sense dependre de la creació real d'objectes.
  • Reutilitzabilitat del codi: El mètode de fàbrica es pot reutilitzar en diferents parts de l'aplicació on es necessita la creació d'objectes. Això promou la centralització i la reutilització de la lògica de creació d'objectes.
  • Encapsulació: Oculta les classes de producte concretes del codi del client, fent que el codi sigui menys dependent d'implementacions específiques. Això millora el manteniment i redueix l'acoblament.

Desavantatges del patró de disseny del mètode de fàbrica

Els inconvenients del patró de disseny del mètode de fàbrica són:

  • Augment de la complexitat: Introdueix classes i interfícies addicionals, afegint una capa d'abstracció que pot fer que el codi sigui més complex d'entendre i mantenir, especialment per a aquells que no estan familiaritzats amb el patró.
  • Càrrec: L'ús de polimorfisme i unió dinàmica pot afectar lleugerament el rendiment, tot i que sovint és insignificant en la majoria d'aplicacions.
  • Acoblament estret dins de les jerarquies de productes: Els creadors de formigó encara estan estretament vinculats als seus productes de formigó corresponents. Els canvis a un sovint requereixen canvis a l'altre.
  • Dependència de subclasses concretes: El codi del client encara depèn de la classe Creator abstracta, que requereix el coneixement de les seves subclasses concretes per fer trucades de mètodes de fàbrica correctes.
  • Potencial d'ús excessiu: És important utilitzar el patró del mètode de fàbrica amb criteri per evitar una enginyeria excessiva de l'aplicació. La creació simple d'objectes sovint es pot gestionar directament sense necessitat d'una fàbrica.
  • Reptes de prova: Provar la lògica de fàbrica en si pot ser més complex.