Fabriksmetodens designmønster er en kreativt designmønster der giver en grænseflade til at skabe objekter i en superklasse, hvilket tillader underklasser at ændre typen af ​​objekter, der vil blive oprettet. Det indkapsler objektskabelseslogik i en separat metode, der fremmer løs kobling mellem skaberen og de skabte objekter. Dette mønster er især nyttigt, når de nøjagtige typer af objekter, der skal oprettes, kan variere eller skal bestemmes under kørsel, hvilket muliggør fleksibilitet og udvidelsesmuligheder ved oprettelse af objekter.

Indholdsfortegnelse

• Hvad er fabriksmetodens designmønster?
• Hvornår skal man bruge Factory Method Design Pattern?
• Komponenter af Factory Method Design Pattern
• Eksempel på fabriksmetode designmønster
• Use Cases af Factory Method Design Pattern
• Fordele ved Factory Method Design Pattern
• Ulemper ved Factory Method Design Pattern

Hvad er fabriksmetodens designmønster?

Factory Method Design Pattern er et kreativt designmønster, der bruges i softwareudvikling for at give en grænseflade til at skabe objekter i en superklasse, mens det tillader underklasser at ændre typen af ​​objekter, der vil blive oprettet. Den indkapsler objektskabelseslogikken i en separat metode, abstraherer instansieringsprocessen og fremmer løs kobling mellem skaberen og de skabte objekter. Dette mønster muliggør fleksibilitet, udvidelse og vedligeholdelse i kodebasen ved at tillade underklasser at definere deres egen implementering af fabriksmetoden til at skabe specifikke typer objekter.

c streng i array

Hvornår skal man bruge Factory Method Design Pattern?

Brug fabriksmetodedesignmønster:

• Når du vil indkapsle objektoprettelse: Hvis du har en kompleks objektoprettelsesproces, eller hvis processen kan variere baseret på betingelser, kan indkapsling af denne logik i en fabriksmetode forenkle klientkoden og fremme genanvendelighed.
• Når du vil afkoble klientkode fra konkrete klasser: Brug af Factory Method Pattern giver dig mulighed for at skabe objekter gennem en grænseflade eller abstrakt klasse, og abstraherer de specifikke implementeringsdetaljer for de konkrete klasser fra klientkoden. Dette fremmer løs kobling og gør det lettere at ændre eller udvide systemet uden at påvirke eksisterende klientkode.
• Når du skal understøtte flere produktvarianter: Hvis din applikation skal skabe forskellige varianter af et produkt, eller hvis nye typer produkter kan blive introduceret i fremtiden, giver Factory Method Pattern en fleksibel måde at imødekomme disse variationer ved at definere fabriksmetoder for hver produkttype.
• Når du ønsker at understøtte tilpasning eller konfiguration: Fabrikker kan bruges til at indkapsle konfigurationslogik, hvilket giver klienter mulighed for at tilpasse oprettelsesprocessen ved at levere parametre eller konfigurationsmuligheder til fabriksmetoden.

Komponenter af Factory Method Design Pattern

1. Skaber

Dette er en abstrakt klasse eller en grænseflade, der erklærer fabriksmetoden. Skaberen indeholder typisk en metode, der fungerer som en fabrik til at skabe objekter. Det kan også indeholde andre metoder, der fungerer med de oprettede objekter.

2. Betonskaber

Concrete Creator-klasser er underklasser af Creator, der implementerer fabriksmetoden til at skabe specifikke typer objekter. Hver konkrete skaber er ansvarlig for at skabe et bestemt produkt.

3. Produkt

Dette er grænsefladen eller den abstrakte klasse for de objekter, som fabriksmetoden opretter. Produktet definerer den fælles grænseflade for alle objekter, som fabriksmetoden kan skabe.

kat timpf søster

4. Betonprodukt

Betonproduktklasser er de faktiske objekter, som fabriksmetoden skaber. Hver konkrete produktklasse implementerer produktgrænsefladen eller udvider produktabstraktklassen.

Eksempel på fabriksmetode designmønster

Nedenfor er problemformuleringen for at forstå Factory Method Design Pattern:

Overvej en softwareapplikation, der skal håndtere oprettelsen af ​​forskellige typer køretøjer, såsom tohjulede, trehjulede og firehjulede. Hver type køretøj har sine egne specifikke egenskaber og adfærd.

1. Uden fabriksmetode designmønster

/*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>

Hvad er problemerne med ovenstående design?

I ovenstående kodedesign:

• Tæt kobling: KlientklassenClient>instansierer direkte de konkrete klasser (TwoWheeler>ogFourWheeler>) baseret på inputtypen, der blev angivet under konstruktionen. Dette fører til tæt kobling mellem bygherren og betonklasserne, hvilket gør koden svær at vedligeholde og udvide.
• Overtrædelse af princippet om enkelt ansvar (SRP): DetClient>klasse er ikke kun ansvarlig for at bestemme, hvilken type køretøj der skal instantieres baseret på inputtypen, men også for at styre køretøjsobjektets livscyklus (f.eks. oprydning). Dette er i strid med Single Responsibility Princippet, som siger, at en klasse kun skal have én grund til at ændre sig.
• Begrænset skalerbarhed: Tilføjelse af en ny type køretøj kræver ændring afClient>klasse, hvilket overtræder Open-Closed Princippet. Dette design er ikke skalerbart, fordi det ikke kan rumme nye typer køretøjer uden at ændre eksisterende kode.

Hvordan undgår vi problemet?

• Definer fabriksgrænseflade: Lave enVehicleFactory>grænseflade eller abstrakt klasse med en metode til at skabe køretøjer.
• Implementer betonfabrikker: Implementer betonfabriksklasser (TwoWheelerFactory>ogFourWheelerFactory>), der implementererVehicleFactory>grænseflade og levere metoder til at skabe forekomster af specifikke typer køretøjer.
• Refactor klient: RedigerClient>klasse for at acceptere enVehicleFactory>eksempel i stedet for direkte at instantiere køretøjer. Kunden vil anmode om et køretøj fra fabrikken, hvilket eliminerer behovet for betinget logik baseret på køretøjstyper.
• Forbedret fleksibilitet: Med denne tilgang er det lige så enkelt at tilføje nye typer køretøjer som at oprette en ny fabriksklasse for den nye køretøjstype uden at ændre eksisterende kundekode.

2. Med fabriksmetodedesignmønster

Lad os opdele koden i komponentmæssig kode:

1. Produktgrænseflade

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

2. Betonprodukter

// 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. Creator Interface (fabriksgrænseflade)

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

4. Betonskabere (betonfabrikker)

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

Komplet kode for dette eksempel:

// 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>

I ovenstående kode:

java får den aktuelle dato

• Vehicle> fungerer som produktgrænsefladen, der definerer den fælles metode printVehicle()> som alle konkrete produkter skal implementere.
• TwoWheeler> og FourWheeler> er konkrete produktklasser, der repræsenterer forskellige typer køretøjer, der implementerer printVehicle()> metode.
• VehicleFactory> fungerer som Creator-grænsefladen (Factory Interface) med en metode createVehicle()> repræsenterer fabriksmetoden.
• TwoWheelerFactory> og FourWheelerFactory> er betonskaberklasser (Betonfabrikker), der implementerer VehicleFactory> grænseflade til at oprette forekomster af specifikke typer køretøjer.

Use Cases af Factory Method Design Pattern

Her er nogle almindelige anvendelser af Factory Method Design-mønsteret:

• Kreative rammer:
  • JDBC (Java Database Connectivity) bruger fabrikker i vid udstrækning til at skabe forbindelser, udsagn og resultatsæt. Afhængighedsinjektionsrammer som Spring og Guice er stærkt afhængige af fabrikker til at skabe og administrere bønner.
• GUI-værktøjssæt:
  • Swing og JavaFX bruger fabrikker til at skabe UI-komponenter som knapper, tekstfelter og etiketter, hvilket giver mulighed for tilpasning og fleksibilitet i UI-design.
• Logningsrammer:
  • Logningsrammer som Log4j og Logback bruger fabrikker til at skabe loggere med forskellige konfigurationer, hvilket muliggør kontrol over logningsniveauer og outputdestinationer.
• Serialisering og deserialisering:
  • Objektserialiseringsrammer bruger ofte fabrikker til at skabe objekter ud fra serialiserede data, der understøtter forskellige serialiseringsformater og versionering.
• Plugin-systemer:
  • Plugin-baserede systemer bruger ofte fabrikker til at indlæse og skabe plugin-forekomster dynamisk, hvilket giver mulighed for udvidelse og tilpasning.
• Spiludvikling:
  • Spilmotorer bruger ofte fabrikker til at skabe forskellige typer spilobjekter, karakterer og niveauer, hvilket fremmer kodeorganisering og fleksibilitet.
• Web-udvikling:
  • Webframeworks bruger nogle gange fabrikker til at skabe visningskomponenter, controllere og tjenester, hvilket muliggør modularitet og testbarhed i webapplikationer.

Fordele ved Factory Method Design Pattern

Fordelene ved Factory Method Design Pattern er:

kabine algoritme

• Afkobling: Det adskiller objektoprettelseslogik fra klientkoden, der bruger disse objekter. Dette gør koden mere fleksibel og vedligeholdelig, fordi ændringer i oprettelsesprocessen ikke kræver ændringer af klientkoden.
• Udvidelsesmuligheder: Det er nemt at introducere nye produkttyper uden at ændre klientkoden. Du skal blot oprette en ny Concrete Creator-underklasse og implementere fabriksmetoden til at producere det nye produkt.
• Testbarhed: Det forenkler enhedstestning ved at give dig mulighed for at håne eller udligne produktskabelse under test. Du kan teste forskellige produktimplementeringer isoleret uden at stole på faktisk oprettelse af objekter.
• Genanvendelighed af kode: Fabriksmetoden kan genbruges i forskellige dele af applikationen, hvor det er nødvendigt at oprette objekter. Dette fremmer centralisering og genbrug af objektskabelseslogik.
• Indkapsling: Det skjuler de konkrete produktklasser fra klientkoden, hvilket gør koden mindre afhængig af specifikke implementeringer. Dette forbedrer vedligeholdelsesevnen og reducerer koblingen.

Ulemper ved Factory Method Design Pattern

Ulemperne ved Factory Method Design Pattern er:

• Øget kompleksitet: Det introducerer yderligere klasser og grænseflader og tilføjer et lag af abstraktion, der kan gøre koden mere kompleks at forstå og vedligeholde, især for dem, der ikke er bekendt med mønsteret.
• Overhead: Brugen af ​​polymorfi og dynamisk binding kan påvirke ydeevnen lidt, selvom dette ofte er ubetydeligt i de fleste applikationer.
• Tæt kobling inden for produkthierarkier: Betonskabere er stadig tæt knyttet til deres tilsvarende betonprodukter. Ændringer i den ene kræver ofte ændringer i den anden.
• Afhængighed af konkrete underklasser: Klientkoden afhænger stadig af den abstrakte Creator-klasse, der kræver viden om dens konkrete underklasser for at foretage korrekte fabriksmetodekald.
• Potentiale for overforbrug: Det er vigtigt at bruge Factory Method-mønsteret med omtanke for at undgå at overkonstruere applikationen. Enkel oprettelse af objekter kan ofte håndteres direkte uden behov for en fabrik.
• Test udfordringer: Test af selve fabrikslogikken kan være mere kompleks.