logo

Tovarniška metoda Oblikovalski vzorec

Vzorec načrtovanja tovarniške metode je a ustvarjalni oblikovalski vzorec ki nudi vmesnik za ustvarjanje objektov v nadrazredu, kar omogoča podrazredom, da spremenijo vrsto predmetov, ki bodo ustvarjeni. Enkapsulira logiko ustvarjanja predmeta v ločeni metodi, ki spodbuja ohlapno povezavo med ustvarjalcem in ustvarjenimi predmeti. Ta vzorec je še posebej uporaben, kadar se točne vrste objektov, ki jih je treba ustvariti, lahko razlikujejo ali jih je treba določiti med izvajanjem, kar omogoča prilagodljivost in razširljivost pri ustvarjanju objektov.

Kazalo



Kaj je vzorec načrtovanja tovarniške metode?

Vzorec načrtovanja tovarniške metode je vzorec ustvarjanja, ki se uporablja v programskem inženirstvu za zagotavljanje vmesnika za ustvarjanje objektov v nadrazredu, hkrati pa omogoča podrazredom, da spremenijo vrsto predmetov, ki bodo ustvarjeni. Enkapsulira logiko ustvarjanja predmeta v ločeni metodi, pri čemer abstrahira postopek instanciranja in spodbuja ohlapno povezavo med ustvarjalcem in ustvarjenimi predmeti. Ta vzorec omogoča prilagodljivost, razširljivost in vzdržljivost v kodni bazi, tako da omogoča podrazredom, da definirajo lastno implementacijo tovarniške metode za ustvarjanje posebnih vrst predmetov.

razlika datumov v excelu

Kdaj uporabiti vzorec načrtovanja tovarniške metode?

Uporabi vzorec načrtovanja tovarniške metode:

  • Ko želite enkapsulirati ustvarjanje predmeta: Če imate zapleten postopek ustvarjanja objekta ali če se postopek lahko razlikuje glede na pogoje, lahko enkapsulacija te logike v tovarniško metodo poenostavi kodo odjemalca in spodbudi ponovno uporabo.
  • Ko želite odjemalsko kodo ločiti od konkretnih razredov: Uporaba vzorca tovarniške metode vam omogoča ustvarjanje objektov prek vmesnika ali abstraktnega razreda, pri čemer abstrahirate specifične izvedbene podrobnosti konkretnih razredov iz odjemalske kode. To spodbuja ohlapno povezovanje in olajša spreminjanje ali razširitev sistema brez vpliva na obstoječo kodo odjemalca.
  • Ko morate podpreti več različic izdelkov: Če mora vaša aplikacija ustvariti različne različice izdelka ali če bodo morda v prihodnosti predstavljene nove vrste izdelkov, vzorec tovarniške metode ponuja prilagodljiv način za prilagoditev tem različicam z definiranjem tovarniških metod za vsako vrsto izdelka.
  • Ko želite podpirati prilagajanje ali konfiguracijo: Tovarne je mogoče uporabiti za enkapsulacijo konfiguracijske logike, kar strankam omogoča prilagajanje postopka ustvarjanja z zagotavljanjem parametrov ali konfiguracijskih možnosti tovarniški metodi.

Komponente vzorca načrtovanja tovarniške metode

1. Ustvarjalec

To je abstraktni razred ali vmesnik, ki deklarira tovarniško metodo. Kreator običajno vsebuje metodo, ki služi kot tovarna za ustvarjanje predmetov. Lahko vsebuje tudi druge metode, ki delujejo z ustvarjenimi predmeti.

2. Betonski ustvarjalec

Razredi Concrete Creator so podrazredi Creatorja, ki izvajajo tovarniško metodo za ustvarjanje določenih tipov predmetov. Vsak Concrete Creator je odgovoren za ustvarjanje določenega izdelka.

3. Izdelek

To je vmesnik ali abstraktni razred za objekte, ki jih ustvari tovarniška metoda. Izdelek definira skupni vmesnik za vse objekte, ki jih lahko ustvari tovarniška metoda.

4. Betonski izdelek

Razredi konkretnih izdelkov so dejanski objekti, ki jih ustvari tovarniška metoda. Vsak razred Concrete Product izvaja vmesnik Product ali razširja abstraktni razred Product.

pretvorniški niz do danes

Primer vzorca načrtovanja tovarniške metode

Spodaj je izjava o problemu za razumevanje vzorca načrtovanja tovarniške metode:

Razmislite o programski aplikaciji, ki mora upravljati ustvarjanje različnih vrst vozil, kot so dvokolesniki, trikolesniki in štirikolesniki. Vsak tip vozila ima svoje specifične lastnosti in obnašanje.

1. Brez vzorca načrtovanja tovarniške metode

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();  } }>
Izhod
I am two wheeler>

Kakšne so težave z zgornjim dizajnom?

V zgornji zasnovi kode:

  • Tesna povezava: Razred strankeClient>neposredno instancira konkretne razrede (TwoWheeler>inFourWheeler>) na podlagi vrste vnosa, ki je bil zagotovljen med njegovo izdelavo. To vodi do tesne povezave med stranko in konkretnimi razredi, zaradi česar je kodo težko vzdrževati in razširiti.
  • Kršitev načela enotne odgovornosti (SRP): TheClient>razred je odgovoren ne le za določanje vrste vozila, ki ga je treba instancirati glede na vrsto vnosa, temveč tudi za upravljanje življenjskega cikla predmeta vozila (npr. čiščenje). To krši načelo enotne odgovornosti, ki pravi, da mora imeti razred samo en razlog za spremembo.
  • Omejena razširljivost: Dodajanje novega tipa vozila zahteva sprememboClient>razreda, ki krši načelo odprto-zaprto. Ta zasnova ni razširljiva, ker ne more sprejeti novih tipov vozil brez spreminjanja obstoječe kode.

Kako se izognemo težavi?

  • Določite tovarniški vmesnik: UstvaritiVehicleFactory>vmesnik ali abstraktni razred z metodo za ustvarjanje vozil.
  • Izvedba tovarn betona: Izvedite razrede tovarne betona (TwoWheelerFactory>inFourWheelerFactory>), ki izvajajoVehicleFactory>vmesnik in zagotavlja metode za ustvarjanje primerkov določenih tipov vozil.
  • Refactor Client: SpremeniteClient>razred sprejeti aVehicleFactory>namesto neposrednega instanciranja vozil. Stranka bo zahtevala vozilo od tovarne, s čimer se odpravi potreba po pogojni logiki, ki temelji na tipih vozil.
  • Izboljšana prilagodljivost: S tem pristopom je dodajanje novih tipov vozil tako preprosto kot ustvarjanje novega tovarniškega razreda za nov tip vozila brez spreminjanja obstoječe kode odjemalca.

2. Z vzorcem oblikovanja tovarniške metode

Razčlenimo kodo na komponentno kodo:

FactoryMethodDesignPattern

1. Vmesnik izdelka

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

2. Betonski izdelki

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. Vmesnik ustvarjalca (tovarniški vmesnik)

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

4. Ustvarjalci betona (tovarne betona)

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

Popolna koda tega primera:

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();  } }>
Izhod
I am two wheeler I am four wheeler>

V zgornji kodi:

pretvori char v int java
  • Vehicle> služi kot vmesnik izdelka, ki definira skupno metodo printVehicle()> ki jih morajo izvajati vsi betonski izdelki.
  • TwoWheeler> in FourWheeler> so konkretni razredi izdelkov, ki predstavljajo različne vrste vozil, ki izvajajo printVehicle()> metoda.
  • VehicleFactory> deluje kot vmesnik ustvarjalca (tovarniški vmesnik) z metodo createVehicle()> ki predstavlja tovarniško metodo.
  • TwoWheelerFactory> in FourWheelerFactory> so razredi konkretnih ustvarjalcev (tovarne betona), ki izvajajo VehicleFactory> vmesnik za ustvarjanje primerkov določenih tipov vozil.

Primeri uporabe vzorca načrtovanja tovarniške metode

Tukaj je nekaj pogostih aplikacij vzorca načrtovanja tovarniške metode:

  • Ustvarjalni okviri:
    • JDBC (Java Database Connectivity) obsežno uporablja tovarne za ustvarjanje povezav, stavkov in naborov rezultatov. Ogrodja za vbrizgavanje odvisnosti, kot sta Spring in Guice, se močno zanašajo na tovarne za ustvarjanje in upravljanje bean-ov.
  • Kompleti orodij GUI:
    • Swing in JavaFX uporabljata tovarne za ustvarjanje komponent uporabniškega vmesnika, kot so gumbi, besedilna polja in oznake, kar omogoča prilagajanje in prilagodljivost oblikovanja uporabniškega vmesnika.
  • Ogrodja beleženja:
    • Ogrodja za beleženje, kot sta Log4j in Logback, uporabljajo tovarne za ustvarjanje zapisovalnikov z različnimi konfiguracijami, ki omogočajo nadzor nad nivoji beleženja in izhodnimi cilji.
  • Serializacija in deserializacija:
    • Ogrodja za serializacijo objektov pogosto uporabljajo tovarne za ustvarjanje objektov iz serializiranih podatkov, ki podpirajo različne formate serializacije in različice.
  • Sistemi vtičnikov:
    • Sistemi, ki temeljijo na vtičnikih, pogosto uporabljajo tovarne za dinamično nalaganje in ustvarjanje primerkov vtičnikov, kar omogoča razširljivost in prilagajanje.
  • Razvoj igre:
    • Igralni stroji pogosto uporabljajo tovarne za ustvarjanje različnih vrst igralnih predmetov, likov in ravni, kar spodbuja organizacijo kode in prilagodljivost.
  • Spletni razvoj:
    • Spletna ogrodja včasih uporabljajo tovarne za ustvarjanje komponent pogleda, krmilnikov in storitev, kar omogoča modularnost in preizkušljivost v spletnih aplikacijah.

Prednosti vzorca načrtovanja tovarniške metode

Prednosti vzorca načrtovanja tovarniške metode so:

ukaz chown
  • Ločitev: Ločuje logiko ustvarjanja objektov od odjemalske kode, ki uporablja te objekte. Zaradi tega je koda bolj prilagodljiva in vzdržljiva, ker spremembe v procesu ustvarjanja ne zahtevajo sprememb kode odjemalca.
  • Razširljivost: Preprosto je uvesti nove vrste izdelkov, ne da bi spremenili kodo odjemalca. Preprosto morate ustvariti nov podrazred Concrete Creator in implementirati tovarniško metodo za izdelavo novega izdelka.
  • Preizkušljivost: Poenostavi preizkušanje enote, tako da vam omogoča, da se med preizkusi norčujete iz ustvarjanja izdelka ali ga onemogočite. Različne izvedbe izdelkov lahko testirate ločeno, ne da bi se zanašali na dejansko ustvarjanje predmeta.
  • Ponovna uporabnost kode: Tovarniško metodo je mogoče ponovno uporabiti v različnih delih aplikacije, kjer je potrebno ustvarjanje predmeta. To spodbuja centralizacijo in ponovno uporabo logike ustvarjanja objektov.
  • Enkapsulacija: Pred kodo odjemalca skrije konkretne razrede izdelkov, zaradi česar je koda manj odvisna od specifičnih implementacij. To izboljša vzdržljivost in zmanjša spajanje.

Slabosti vzorca načrtovanja tovarniške metode

Slabosti vzorca načrtovanja tovarniške metode so:

  • Povečana kompleksnost: Predstavlja dodatne razrede in vmesnike ter dodaja plast abstrakcije, ki lahko naredi kodo bolj zapleteno za razumevanje in vzdrževanje, zlasti za tiste, ki vzorca ne poznajo.
  • režijski stroški: Uporaba polimorfizma in dinamične vezave lahko rahlo vpliva na zmogljivost, čeprav je to v večini aplikacij pogosto zanemarljivo.
  • Tesna povezanost znotraj hierarhij izdelkov: Ustvarjalci betona so še vedno tesno povezani s svojimi ustreznimi izdelki betona. Spremembe enega pogosto zahtevajo spremembe drugega.
  • Odvisnost od konkretnih podrazredov: Koda odjemalca je še vedno odvisna od abstraktnega razreda Creator, ki zahteva poznavanje njegovih konkretnih podrazredov za pravilne klice tovarniških metod.
  • Možnost prekomerne uporabe: Pomembno je, da vzorec tovarniške metode uporabljate preudarno, da se izognete pretiranemu inženiringu aplikacije. Preprosto ustvarjanje predmetov je pogosto mogoče izvesti neposredno brez potrebe po tovarni.
  • Testni izzivi: Samo testiranje tovarniške logike je lahko bolj zapleteno.