Factory Method -suunnittelumalli on a luova suunnittelukuvio joka tarjoaa käyttöliittymän superluokan objektien luomiseen, jolloin alaluokat voivat muuttaa luotavien objektien tyyppiä. Se kapseloi objektin luomislogiikan erilliseen menetelmään, mikä edistää löysää kytkentää luojan ja luotujen objektien välillä. Tämä malli on erityisen hyödyllinen, kun luotavien objektien tarkat tyypit voivat vaihdella tai ne on määritettävä ajon aikana, mikä mahdollistaa joustavuuden ja laajennettavuuden objektien luomisessa.

Sisällysluettelo

• Mikä on Factory Method -suunnittelumalli?
• Milloin käyttää Factory Method -suunnittelumallia?
• Factory Method Design Patternin komponentit
• Tehdasmenetelmän suunnittelumalliesimerkki
• Tehdasmenetelmän suunnittelumallin käyttötapaukset
• Tehdasmenetelmän suunnittelumallin edut
• Tehdasmenetelmän suunnittelumallin haitat

Mikä on Factory Method -suunnittelumalli?

Factory Method Design Pattern on luova suunnittelumalli, jota käytetään ohjelmistosuunnittelussa tarjoamaan käyttöliittymä superluokan objektien luomiseen samalla, kun alaluokat voivat muuttaa luotavien objektien tyyppiä. Se kapseloi objektin luomislogiikan erilliseen menetelmään, abstraktii instantiaatioprosessin ja edistää löysää kytkentää luojan ja luotujen objektien välillä. Tämä malli mahdollistaa koodikannan joustavuuden, laajennettavuuden ja ylläpidettävyyden sallimalla alaluokkien määritellä oman tehdasmetodin toteutuksensa tietyntyyppisten objektien luomiseksi.

kumoa viimeinen sitoumus

Milloin käyttää Factory Method -suunnittelumallia?

Käytä tehdasmenetelmän suunnittelumallia:

• Kun haluat kapseloida objektin luomisen: Jos sinulla on monimutkainen objektin luontiprosessi tai jos prosessi voi vaihdella olosuhteiden mukaan, tämän logiikan kapselointi tehdasmenetelmään voi yksinkertaistaa asiakaskoodia ja edistää uudelleenkäytettävyyttä.
• Kun haluat irrottaa asiakaskoodin konkreettisista luokista: Factory Method Pattern -mallin avulla voit luoda objekteja käyttöliittymän tai abstraktin luokan kautta, jolloin konkreettisten luokkien erityiset toteutustiedot poistetaan asiakaskoodista. Tämä edistää löysää kytkentää ja helpottaa järjestelmän muokkaamista tai laajentamista vaikuttamatta olemassa olevaan asiakaskoodiin.
• Kun sinun on tuettava useita tuotemuunnelmia: Jos sovelluksessasi on luotava tuotteista erilaisia ​​muunnelmia tai jos uusia tuotetyyppejä voidaan ottaa käyttöön tulevaisuudessa, Factory Method Pattern tarjoaa joustavan tavan mukauttaa nämä muunnelmat määrittelemällä tehdasmenetelmät kullekin tuotetyypille.
• Kun haluat tukea mukauttamista tai määritystä: Tehtaita voidaan käyttää konfigurointilogiikan kapseloimiseen, jolloin asiakkaat voivat mukauttaa luontiprosessia tarjoamalla parametreja tai konfigurointivaihtoehtoja tehdasmenetelmään.

Factory Method Design Patternin komponentit

1. Luoja

Tämä on abstrakti luokka tai rajapinta, joka ilmoittaa tehdasmetodin. Luoja sisältää tyypillisesti menetelmän, joka toimii tehtaana objektien luomiseen. Se voi sisältää myös muita menetelmiä, jotka toimivat luotujen objektien kanssa.

2. Betonin luoja

Concrete Creator -luokat ovat Creatorin alaluokkia, jotka toteuttavat tehdasmenetelmän tietyntyyppisten objektien luomiseen. Jokainen Concrete Creator on vastuussa tietyn tuotteen luomisesta.

3. Tuote

Tämä on rajapinta tai abstrakti luokka tehdasmetodin luomille objekteille. Tuote määrittää yhteisen rajapinnan kaikille objekteille, jotka tehdasmenetelmä voi luoda.

4. Betonituote

Konkreettiset tuoteluokat ovat todellisia objekteja, jotka tehdasmenetelmä luo. Jokainen betonituoteluokka toteuttaa tuoterajapinnan tai laajentaa tuotteen abstraktia luokkaa.

kuinka lajitella arraylist javassa

Tehdasmenetelmän suunnittelumalliesimerkki

Alla on ongelmanselvitys tehdasmenetelmän suunnittelumallin ymmärtämiseksi:

Harkitse ohjelmistosovellusta, jonka täytyy käsitellä erityyppisten ajoneuvojen, kuten Two Wheelers, Three Wheelers ja Four Wheelers, luomista. Jokaisella ajoneuvotyypillä on omat ominaisuutensa ja käyttäytymisensä.

1. Ilman tehdasmenetelmää

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

Mitä ongelmia yllä olevassa suunnittelussa on?

Yllä olevassa koodisuunnittelussa:

• Tiukka kytkentä: AsiakasluokkaClient>instantoi suoraan konkreettiset luokat (TwoWheeler>jaFourWheeler>) sen rakentamisen aikana annetun syöttötyypin perusteella. Tämä johtaa tiiviiseen kytkentään asiakkaan ja konkreettisten luokkien välillä, mikä tekee koodin ylläpidosta ja laajentamisesta vaikeaa.
• Yhden vastuun periaatteen (SRP) rikkominen: TheClient>luokka ei ole vastuussa vain sen määrittämisestä, minkä tyyppinen ajoneuvo instantoi syöttötyypin perusteella, vaan myös ajoneuvoobjektin elinkaaren hallinnasta (esim. Tämä rikkoo yhden vastuun periaatetta, jonka mukaan luokalla saa olla vain yksi syy muuttua.
• Rajoitettu skaalautuvuus: Uuden ajoneuvotyypin lisääminen vaatii muutostaClient>luokassa, mikä rikkoo Open-Closed -periaatetta. Tämä rakenne ei ole skaalautuva, koska se ei sovi uudentyyppisiin ajoneuvoihin muuttamatta olemassa olevaa koodia.

Miten vältämme ongelman?

• Määritä tehdasliittymä: LuoVehicleFactory>käyttöliittymä tai abstrakti luokka menetelmällä ajoneuvojen luomiseksi.
• Betonitehtaiden toteuttaminen: Toteuta betonitehdasluokat (TwoWheelerFactory>jaFourWheelerFactory>), jotka toteuttavatVehicleFactory>käyttöliittymä ja tarjota menetelmiä tietyntyyppisten ajoneuvojen esiintymien luomiseen.
• Refaktorin asiakas: MuokkaaClient>luokka hyväksyä aVehicleFactory>esimerkiksi ajoneuvojen suoraan luomisen sijaan. Asiakas pyytää ajoneuvon tehtaalta, jolloin ei tarvita ajoneuvotyyppeihin perustuvaa ehdollista logiikkaa.
• Parannettu joustavuus: Tällä lähestymistavalla uudentyyppisten ajoneuvojen lisääminen on yhtä helppoa kuin uuden tehdasluokan luominen uudelle ajoneuvotyypille ilman, että olemassa olevaa asiakaskoodia muutetaan.

2. Tehdasmenetelmällä suunnittelukuvio

Jaetaan koodi komponenttikohtaiseen koodiin:

1. Tuotteen käyttöliittymä

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

2. Betonituotteet

// 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. Luojan käyttöliittymä (tehdaskäyttöliittymä)

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

4. Betonintekijät (betonitehtaat)

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

Tämän esimerkin täydellinen koodi:

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

Yllä olevassa koodissa:

merkkijono päivämäärään

• Vehicle> toimii tuotteen käyttöliittymänä, joka määrittelee yhteisen menetelmän printVehicle()> että kaikkien betonituotteiden on toteutettava.
• TwoWheeler> ja FourWheeler> ovat erityyppisiä ajoneuvoja edustavia konkreettisia tuoteluokkia, jotka toteuttavat printVehicle()> menetelmä.
• VehicleFactory> toimii Creator-liittymänä (Factory Interface) menetelmän kanssa createVehicle()> edustaa tehdasmenetelmää.
• TwoWheelerFactory> ja FourWheelerFactory> ovat konkreettisia luojaluokkia (Concrete Factories), jotka toteuttavat VehicleFactory> käyttöliittymä tietyntyyppisten ajoneuvojen esiintymien luomiseen.

Tehdasmenetelmän suunnittelumallin käyttötapaukset

Tässä on joitain yleisiä tehdasmenetelmän suunnittelun sovelluksia:

• Creative Frameworks:
  • JDBC (Java Database Connectivity) käyttää tehtaita laajasti yhteyksien, lausekkeiden ja tulosjoukkojen luomiseen. Riippuvuusinjektiokehykset, kuten Spring ja Guice, luottavat voimakkaasti tehtaisiin papujen luomisessa ja hallinnassa.
• GUI-työkalusarjat:
  • Swing ja JavaFX käyttävät tehtaita käyttöliittymäkomponenttien, kuten painikkeiden, tekstikenttien ja tarrojen, luomiseen, mikä mahdollistaa räätälöinnin ja joustavuuden käyttöliittymäsuunnittelussa.
• Kirjauskehykset:
  • Lokikehykset, kuten Log4j ja Logback, käyttävät tehtaita eri kokoonpanoilla varustettujen loggerien luomiseen, mikä mahdollistaa kirjaustasojen ja tulostuskohteiden hallinnan.
• Serialisointi ja deserialisointi:
  • Objektien serialisointikehykset käyttävät usein tehtaita objektien luomiseen sarjoitetusta tiedosta, jotka tukevat erilaisia ​​serialisointimuotoja ja versiointia.
• Plugin-järjestelmät:
  • Plugin-pohjaiset järjestelmät käyttävät usein tehtaita laajennusinstanssien lataamiseen ja luomiseen dynaamisesti, mikä mahdollistaa laajennettavuuden ja mukauttamisen.
• Pelikehitys:
  • Pelimoottorit käyttävät usein tehtaita luodakseen erilaisia ​​peliobjekteja, hahmoja ja tasoja, mikä edistää koodin järjestämistä ja joustavuutta.
• Verkkokehitys:
  • Web-kehykset käyttävät joskus tehtaita näkymäkomponenttien, ohjaimien ja palvelujen luomiseen, mikä mahdollistaa modulaarisuuden ja testattavuuden verkkosovelluksissa.

Tehdasmenetelmän suunnittelumallin edut

Factory Method Design Patternin edut ovat:

binäärihaun algoritmi

• Irrottaminen: Se erottaa objektien luontilogiikan kyseisiä objekteja käyttävästä asiakaskoodista. Tämä tekee koodista joustavamman ja ylläpidettävämmän, koska luontiprosessin muutokset eivät vaadi muutoksia asiakaskoodiin.
• Laajennettavuus: Uusia tuotetyyppejä on helppo ottaa käyttöön asiakaskoodia muuttamatta. Sinun tarvitsee vain luoda uusi Concrete Creator -alaluokka ja ottaa käyttöön tehdasmenetelmä uuden tuotteen valmistamiseksi.
• Testattavuus: Se yksinkertaistaa yksikkötestausta sallimalla tuotteen luomisen pilkkaamisen tai tyrkyttämisen testien aikana. Voit testata eri tuotetoteutuksia erikseen luottamatta varsinaiseen objektien luomiseen.
• Koodin uudelleenkäyttö: Tehdasmenetelmää voidaan käyttää uudelleen sovelluksen eri osissa, joissa objektin luomista tarvitaan. Tämä edistää objektien luontilogiikan keskittämistä ja uudelleenkäyttöä.
• Kapselointi: Se piilottaa konkreettiset tuoteluokat asiakaskoodilta, mikä tekee koodista vähemmän riippuvaisen tietyistä toteutuksista. Tämä parantaa huollettavuutta ja vähentää kytkentää.

Tehdasmenetelmän suunnittelumallin haitat

Factory Method Design Patternin haitat ovat:

• Lisääntynyt monimutkaisuus: Se esittelee lisää luokkia ja käyttöliittymiä ja lisää abstraktiokerroksen, joka voi tehdä koodista monimutkaisempaa ymmärtää ja ylläpitää, erityisesti niille, jotka eivät tunne kuviota.
• Yleiskustannukset: Polymorfismin ja dynaamisen sitomisen käyttö voi hieman vaikuttaa suorituskykyyn, vaikka tämä on usein merkityksetöntä useimmissa sovelluksissa.
• Tiivis kytkentä tuotehierarkioiden sisällä: Concrete Creators on edelleen tiiviisti kytketty vastaaviin betonituotteisiinsa. Muutokset toiseen edellyttävät usein muutoksia toiseen.
• Riippuvuus betonin alaluokista: Asiakaskoodi riippuu edelleen abstraktista Creator-luokasta, mikä vaatii sen konkreettisten alaluokkien tuntemusta oikeiden tehdasmetodekutsujen tekemiseksi.
• Ylikäytön mahdollisuus: On tärkeää käyttää Factory Method -mallia harkiten, jotta vältetään sovelluksen liiallinen suunnittelu. Yksinkertainen objektin luominen voidaan usein hoitaa suoraan ilman tehdasta.
• Testauksen haasteet: Itse tehdaslogiikan testaus voi olla monimutkaisempaa.