Modelul de proiectare al metodei din fabrică este a model de design creațional care oferă o interfață pentru crearea de obiecte într-o superclasă, permițând subclaselor să modifice tipul de obiecte care vor fi create. Acesta încapsulează logica creării obiectelor într-o metodă separată, promovând cuplarea liberă între creator și obiectele create. Acest model este deosebit de util atunci când tipurile exacte de obiecte care urmează să fie create pot varia sau trebuie determinate în timpul execuției, permițând flexibilitate și extensibilitate în crearea obiectelor.

Cuprins

• Care este modelul de proiectare a metodei din fabrică?
• Când să utilizați Factory Method Design Pattern?
• Componentele modelului de proiectare a metodei fabricii
• Exemplu de model de proiectare a metodei din fabrică
• Cazuri de utilizare ale modelului de proiectare a metodei din fabrică
• Avantajele modelului de proiectare a metodei fabricii
• Dezavantajele modelului de proiectare a metodei fabricii

Ce este modelul de proiectare a metodei din fabrică?

Modelul de proiectare al metodei Factory este un model de design creațional utilizat în ingineria software pentru a oferi o interfață pentru crearea de obiecte într-o superclasă, permițând în același timp subclaselor să modifice tipul de obiecte care vor fi create. Acesta încapsulează logica creării obiectului într-o metodă separată, abstragând procesul de instanțiere și promovând cuplarea liberă între creator și obiectele create. Acest model permite flexibilitatea, extensibilitatea și mentenabilitatea în baza de cod, permițând subclaselor să-și definească propria implementare a metodei din fabrică pentru a crea tipuri specifice de obiecte.

imagine de reducere

Când să utilizați Factory Method Design Pattern?

Utilizați modelul de proiectare al metodei din fabrică:

• Când doriți să încapsulați crearea de obiecte: Dacă aveți un proces complex de creare a obiectelor sau dacă procesul poate varia în funcție de condiții, încapsularea acestei logici într-o metodă din fabrică poate simplifica codul clientului și poate promova reutilizarea.
• Când doriți să decuplați codul client de clase concrete: Utilizarea Factory Method Pattern vă permite să creați obiecte printr-o interfață sau o clasă abstractă, eliminând detaliile specifice de implementare ale claselor concrete din codul clientului. Acest lucru promovează cuplarea slabă și facilitează modificarea sau extinderea sistemului fără a afecta codul client existent.
• Când trebuie să acceptați mai multe variante de produs: Dacă aplicația dvs. trebuie să creeze diferite variații ale unui produs sau dacă pot fi introduse noi tipuri de produse în viitor, modelul de metodă din fabrică oferă o modalitate flexibilă de a adapta aceste variații prin definirea metodelor din fabrică pentru fiecare tip de produs.
• Când doriți să acceptați personalizarea sau configurarea: Fabricile pot fi folosite pentru a încapsula logica de configurare, permițând clienților să personalizeze procesul de creare prin furnizarea de parametri sau opțiuni de configurare metodei din fabrică.

Componentele modelului de proiectare a metodei fabricii

1. Creator

Aceasta este o clasă abstractă sau o interfață care declară metoda din fabrică. Creatorul conține de obicei o metodă care servește ca o fabrică pentru crearea de obiecte. Poate conține și alte metode care funcționează cu obiectele create.

limbajul de bază java

2. Creator de beton

Clasele Concrete Creator sunt subclase ale Creatorului care implementează metoda fabrică pentru a crea tipuri specifice de obiecte. Fiecare Creator de Beton este responsabil pentru crearea unui anumit produs.

3. Produs

Aceasta este interfața sau clasa abstractă pentru obiectele pe care le creează metoda din fabrică. Produsul definește interfața comună pentru toate obiectele pe care le poate crea metoda din fabrică.

4. Produs de beton

Clasele de produse concrete sunt obiectele reale pe care le creează metoda fabricii. Fiecare clasă Produs concret implementează interfața Product sau extinde clasa abstract Product.

Exemplu de model de proiectare a metodei din fabrică

Mai jos este declarația problemei pentru a înțelege modelul de proiectare al metodei din fabrică:

Luați în considerare o aplicație software care trebuie să se ocupe de crearea diferitelor tipuri de vehicule, cum ar fi două roți, trei roți și patru roți. Fiecare tip de vehicul are propriile sale proprietăți și comportamente specifice.

1. Fără model de proiectare a metodei din fabrică

/*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();  } }>

I am two wheeler>

Care sunt problemele cu designul de mai sus?

În designul codului de mai sus:

• Cuplaje strânse: Clasa de clientClient>instanțiază direct clasele concrete (TwoWheeler>șiFourWheeler>) pe baza tipului de intrare furnizat în timpul construcției sale. Acest lucru duce la o cuplare strânsă între client și clasele de beton, făcând codul dificil de întreținut și extins.
• Încălcarea principiului responsabilității unice (SRP): TheClient>clasa este responsabilă nu numai pentru determinarea tipului de vehicul pe care să-l instanțieze pe baza tipului de intrare, ci și pentru gestionarea ciclului de viață al obiectului vehiculului (de exemplu, curățarea). Acest lucru încalcă principiul responsabilității unice, care prevede că o clasă ar trebui să aibă un singur motiv pentru a se schimba.
• Scalabilitate limitată: Adăugarea unui nou tip de vehicul necesită modificareaClient>clasa, care încalcă Principiul Deschis-Închis. Acest design nu este scalabil deoarece nu poate găzdui noi tipuri de vehicule fără a modifica codul existent.

Cum evităm problema?

• Definiți interfața fabricii: Creeaza oVehicleFactory>interfață sau clasă abstractă cu o metodă de creare a vehiculelor.
• Implementați fabrici de beton: Implementarea claselor de fabrica de beton (TwoWheelerFactory>șiFourWheelerFactory>) care implementeazăVehicleFactory>interfață și să ofere metode pentru a crea exemple de tipuri specifice de vehicule.
• Client refactor: ModificațiClient>clasa a accepta aVehicleFactory>instanță în loc de a instanția direct vehiculele. Clientul va solicita un vehicul din fabrică, eliminând necesitatea unei logici condiționate bazate pe tipurile de vehicule.
• Flexibilitate sporită: Cu această abordare, adăugarea de noi tipuri de vehicule este la fel de simplă ca și crearea unei noi clase de fabrică pentru noul tip de vehicul fără a modifica codul client existent.

2. Cu model de proiectare cu metoda fabricii

Să defalcăm codul în cod în funcție de componente:

1. Interfața produsului

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

2. Produse din beton

// 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. Interfața creatorului (Interfața fabricii)

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

4. Creatori de beton (Fabrici de beton)

// 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();  } }>

Cod complet al acestui exemplu:

// 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();  } }>

I am two wheeler I am four wheeler>

În codul de mai sus:

variabile globale javascript

• Vehicle> servește ca interfață de produs, definind metoda comună printVehicle()> pe care trebuie să le implementeze toate produsele din beton.
• TwoWheeler> și FourWheeler> sunt clase de produse concrete reprezentând diferite tipuri de vehicule, implementând printVehicle()> metodă.
• VehicleFactory> acționează ca interfață Creator (Factory Interface) cu o metodă createVehicle()> reprezentând metoda fabricii.
• TwoWheelerFactory> și FourWheelerFactory> sunt clase de creatori de beton (Fabrici de beton) care implementează VehicleFactory> interfață pentru a crea exemple de tipuri specifice de vehicule.

Cazuri de utilizare ale modelului de proiectare a metodei din fabrică

Iată câteva aplicații comune ale modelului Factory Method Design:

• Cadre de creație:
  • JDBC (Java Database Connectivity) folosește în mod extensiv fabrici pentru a crea conexiuni, declarații și seturi de rezultate. Cadrele de injectare a dependenței precum Spring și Guice se bazează în mare măsură pe fabrici pentru a crea și gestiona boabele.
• Truse de instrumente GUI:
  • Swing și JavaFX folosesc fabrici pentru a crea componente UI, cum ar fi butoane, câmpuri de text și etichete, permițând personalizarea și flexibilitatea în proiectarea UI.
• Cadre de înregistrare:
  • Cadrele de logare precum Log4j și Logback folosesc fabrici pentru a crea loggere cu diferite configurații, permițând controlul asupra nivelurilor de înregistrare și a destinațiilor de ieșire.
• Serializare și deserializare:
  • Cadrele de serializare a obiectelor folosesc adesea fabrici pentru a crea obiecte din date serializate, acceptând diferite formate de serializare și versiune.
• Sisteme de pluginuri:
  • Sistemele bazate pe pluginuri folosesc adesea fabrici pentru a încărca și a crea instanțe de plugin în mod dinamic, permițând extensibilitate și personalizare.
• Dezvoltarea jocului:
  • Motoarele de joc folosesc adesea fabrici pentru a crea diferite tipuri de obiecte de joc, personaje și niveluri, promovând organizarea codului și flexibilitatea.
• Dezvoltare web:
  • Cadrele web folosesc uneori fabrici pentru a crea componente de vizualizare, controlere și servicii, permițând modularitatea și testabilitatea în aplicațiile web.

Avantajele modelului de proiectare a metodei fabricii

Avantajele modelului de proiectare a metodei fabricii sunt:

găsiți în harta c++

• Decuplare: Separă logica de creare a obiectelor de codul client care utilizează acele obiecte. Acest lucru face codul mai flexibil și mai ușor de întreținut, deoarece modificările aduse procesului de creare nu necesită modificări ale codului clientului.
• Extensibilitate: Este ușor să introduceți noi tipuri de produse fără a modifica codul clientului. Trebuie pur și simplu să creați o nouă subclasă Concrete Creator și să implementați metoda din fabrică pentru a produce noul produs.
• Testabilitate: Simplifică testarea unitară, permițându-vă să bateți joc sau să împiedicați crearea de produse în timpul testelor. Puteți testa diferite implementări de produse în mod izolat, fără a vă baza pe crearea reală a obiectelor.
• Reutilizarea codului: Metoda din fabrică poate fi reutilizată în diferite părți ale aplicației unde este necesară crearea de obiecte. Acest lucru promovează centralizarea și reutilizarea logicii de creare a obiectelor.
• Încapsulare: Ascunde clasele de produse concrete din codul clientului, făcând codul mai puțin dependent de implementări specifice. Acest lucru îmbunătățește mentenabilitatea și reduce cuplarea.

Dezavantajele modelului de proiectare a metodei fabricii

Dezavantajele modelului de proiectare a metodei fabricii sunt:

• Complexitate crescută: Introduce clase și interfețe suplimentare, adăugând un strat de abstractizare care poate face codul mai complex de înțeles și întreținut, în special pentru cei care nu sunt familiarizați cu modelul.
• deasupra capului: Utilizarea polimorfismului și a legării dinamice poate afecta ușor performanța, deși acest lucru este adesea neglijabil în majoritatea aplicațiilor.
• Cuplaje strânse în cadrul ierarhiilor de produse: Creatorii de beton sunt încă strâns cuplati cu produsele lor de beton corespunzătoare. Schimbările la unul necesită adesea schimbări la celălalt.
• Dependența de subclase concrete: Codul client încă depinde de clasa abstractă Creator, necesitând cunoașterea subclaselor sale concrete pentru a efectua apeluri corecte de metodă din fabrică.
• Potențial de utilizare excesivă: Este important să folosiți modelul Factory Method în mod judicios pentru a evita suprainginerirea aplicației. Crearea simplă a obiectelor poate fi adesea gestionată direct, fără a fi nevoie de o fabrică.
• Provocări de testare: Testarea logicii fabricii în sine poate fi mai complexă.