Gamyklos metodo projektavimo modelis yra a kūrybos dizaino modelis kuri suteikia sąsają superklasės objektams kurti, leidžianti poklasiams keisti kuriamų objektų tipą. Ji įtraukia objektų kūrimo logiką į atskirą metodą, skatindama laisvą ryšį tarp kūrėjo ir sukurtų objektų. Šis modelis yra ypač naudingas, kai tikslūs kuriamų objektų tipai gali skirtis arba juos reikia nustatyti vykdymo metu, todėl objektų kūrimas yra lankstesnis ir išplečiamas.

Turinys

• Kas yra gamyklinio metodo projektavimo modelis?
• Kada naudoti gamyklinio metodo dizaino modelį?
• Gamyklinio metodo projektavimo modelio komponentai
• Gamyklos metodo projektavimo modelio pavyzdys
• Gamyklinio metodo projektavimo modelio naudojimo atvejai
• Gamyklinio metodo projektavimo modelio privalumai
• Gamyklinio metodo projektavimo modelio trūkumai

Kas yra gamyklinio metodo projektavimo modelis?

Gamyklos metodo projektavimo modelis yra kūrybos projektavimo modelis, naudojamas programinės įrangos inžinerijoje, kad būtų sukurta sąsaja superklasės objektams kurti, o poklasiams leidžiama keisti kuriamų objektų tipą. Ji įtraukia objekto kūrimo logiką į atskirą metodą, abstrahuoja momentų kūrimo procesą ir skatina laisvą ryšį tarp kūrėjo ir sukurtų objektų. Šis modelis įgalina kodų bazės lankstumą, išplečiamumą ir priežiūrą, nes leidžia poklasiams apibrėžti savo gamyklinio metodo įgyvendinimą, kad būtų galima sukurti konkrečių tipų objektus.

pandos iterrows

Kada naudoti gamyklinio metodo dizaino modelį?

Naudokite gamyklinio metodo dizaino modelį:

• Kai norite įtraukti objekto kūrimą: Jei turite sudėtingą objekto kūrimo procesą arba jei procesas gali skirtis priklausomai nuo sąlygų, šios logikos įtraukimas į gamyklinį metodą gali supaprastinti kliento kodą ir paskatinti pakartotinį naudojimą.
• Kai norite atsieti kliento kodą nuo konkrečių klasių: Naudodami gamyklinio metodo šabloną galite kurti objektus per sąsają arba abstrakčią klasę, iš kliento kodo atimant konkrečias konkrečių klasių įgyvendinimo detales. Tai skatina laisvą sujungimą ir palengvina sistemos modifikavimą ar išplėtimą nepažeidžiant esamo kliento kodo.
• Kai reikia palaikyti kelis produkto variantus: Jei jūsų programai reikia sukurti skirtingus gaminio variantus arba jei ateityje gali būti pristatyti nauji gaminių tipai, gamyklinio metodo modelis suteikia lankstų būdą pritaikyti šiuos variantus, apibrėžiant kiekvieno produkto tipo gamyklinius metodus.
• Jei norite palaikyti tinkinimą arba konfigūraciją: Gamyklos gali būti naudojamos konfigūracijos logikai įterpti, leidžiant klientams pritaikyti kūrimo procesą, pateikiant parametrus arba konfigūravimo parinktis gamykliniam metodui.

Gamyklinio metodo projektavimo modelio komponentai

1. Kūrėjas

Tai yra abstrakti klasė arba sąsaja, kuri deklaruoja gamyklinį metodą. Kūrėjas paprastai turi metodą, kuris naudojamas kaip objektų kūrimo gamykla. Jame taip pat gali būti kitų metodų, kurie veikia su sukurtais objektais.

2. Betono kūrėjas

„Concrete Creator“ klasės yra „Creator“ poklasiai, kurie diegia gamyklinį metodą tam tikrų tipų objektams kurti. Kiekvienas betono kūrėjas yra atsakingas už konkretaus produkto sukūrimą.

len of string java

3. Produktas

Tai yra sąsaja arba abstrakčioji klasė objektams, kuriuos sukuria gamyklinis metodas. Produktas apibrėžia bendrą sąsają visiems objektams, kuriuos gali sukurti gamyklinis metodas.

4. Betono gaminys

Konkrečios gaminių klasės yra faktiniai objektai, kuriuos sukuria gamyklos metodas. Kiekviena betono gaminio klasė įgyvendina produkto sąsają arba išplečia produkto abstrakčiąją klasę.

Gamyklos metodo projektavimo modelio pavyzdys

Žemiau pateikiamas problemos pareiškimas, kad suprastumėte gamyklinio metodo projektavimo modelį:

Apsvarstykite programinę įrangą, kuri turi kurti įvairių tipų transporto priemones, pvz., „Two Wheelers“, „Three Wheelers“ ir „Four Wheelers“. Kiekvienas transporto priemonių tipas turi savo specifines savybes ir elgesį.

1. Be gamyklinio metodo projektavimo modelio

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

Kokios problemos kyla dėl aukščiau pateikto dizaino?

Aukščiau pateiktame kodo dizaine:

• Tvirtas sujungimas: Klientų klasėClient>tiesiogiai sukuria konkrečias klases (TwoWheeler>irFourWheeler>) pagal jo kūrimo metu pateiktą įvesties tipą. Dėl to kliento ir konkrečių klasių glaudžiai susiejama, todėl kodą sunku prižiūrėti ir išplėsti.
• Vienos atsakomybės principo (SRP) pažeidimas: TheClient>klasė yra atsakinga ne tik už tai, kokio tipo transporto priemonę reikia sukurti pagal įvesties tipą, bet ir už transporto priemonės objekto gyvavimo ciklo valdymą (pvz., valymą). Tai pažeidžia bendros atsakomybės principą, pagal kurį klasė turi turėti tik vieną priežastį keistis.
• Ribotas mastelio keitimas: Pridedant naują transporto priemonės tipą, reikia pakeistiClient>klasė, kuri pažeidžia Atviro-uždarymo principą. Šis dizainas nėra keičiamas, nes jis negali pritaikyti naujų tipų transporto priemonių nepakeitus esamo kodo.

Kaip išvengti problemos?

• Apibrėžkite gamyklinę sąsają: SukurtiVehicleFactory>sąsaja arba abstrakčioji klasė su transporto priemonių kūrimo metodu.
• Įdiegti betono gamyklas: Įdiekite betono gamyklos klases (TwoWheelerFactory>irFourWheelerFactory>), kurie įgyvendinaVehicleFactory>sąsają ir pateikti metodus, kaip sukurti konkrečių tipų transporto priemonių egzempliorius.
• Refaktoriaus klientas: ModifikuotiClient>klasė priimti aVehicleFactory>pavyzdį, o ne tiesiogines transporto priemones. Klientas paprašys transporto priemonės iš gamyklos, todėl nebereikės sąlyginės logikos, pagrįstos transporto priemonių tipais.
• Padidintas lankstumas: Taikant šį metodą, pridėti naujų tipų transporto priemones yra taip paprasta, kaip sukurti naują gamyklinę klasę naujam transporto priemonės tipui nekeičiant esamo kliento kodo.

2. Su gamyklinio metodo dizaino modeliu

Suskirstykime kodą į komponentų kodą:

1. Produkto sąsaja

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

2. Betono gaminiai

// 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. Kūrėjo sąsaja (gamyklinė sąsaja)

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

4. Betono kūrėjai (betono gamyklos)

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

Pilnas šio pavyzdžio kodas:

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

Aukščiau pateiktame kode:

mysql šou vartotojai

• Vehicle> veikia kaip produkto sąsaja, apibrėžianti bendrą metodą printVehicle()> kad visi betono gaminiai turi būti įgyvendinti.
• TwoWheeler> ir FourWheeler> yra konkrečių gaminių klasės, atstovaujančios skirtingus transporto priemonių tipus, įgyvendinančios printVehicle()> metodas.
• VehicleFactory> veikia kaip kūrėjo sąsaja (gamyklinė sąsaja) su metodu createVehicle()> atstovaujantis gamykliniam metodui.
• TwoWheelerFactory> ir FourWheelerFactory> yra konkrečių kūrėjų klasės (betono gamyklos), įgyvendinančios VehicleFactory> sąsaja, skirta sukurti konkrečių tipų transporto priemonių egzempliorius.

Gamyklinio metodo projektavimo modelio naudojimo atvejai

Štai keletas įprastų gamyklinio metodo projektavimo modelio taikymo būdų:

• Kūrybos karkasai:
  • JDBC („Java Database Connectivity“) plačiai naudoja gamyklas ryšiams, pareiškimams ir rezultatų rinkiniams kurti. Priklausomybės įpurškimo sistemos, tokios kaip „Spring“ ir „Guice“, labai priklauso nuo gamyklų, kuriant ir valdant pupeles.
• GUI įrankių rinkiniai:
  • „Swing“ ir „JavaFX“ naudoja gamyklas, kad sukurtų vartotojo sąsajos komponentus, pvz., mygtukus, teksto laukus ir etiketes, kad būtų galima tinkinti ir lanksčiai kurti vartotojo sąsają.
• Registravimo karkasai:
  • Registravimo sistemos, tokios kaip Log4j ir Logback, naudoja gamyklas, kad sukurtų skirtingų konfigūracijų registratorius, leidžiančius valdyti registravimo lygius ir išvesties paskirties vietas.
• Serializavimas ir deserializavimas:
  • Objektų serializavimo sistemos dažnai naudoja gamyklas, kad sukurtų objektus iš serijinių duomenų, palaikančių skirtingus serializavimo formatus ir versijų kūrimą.
• Papildinių sistemos:
  • Papildiniais pagrįstos sistemos dažnai naudoja gamyklas, kad įkeltų ir dinamiškai sukurtų papildinių egzempliorius, kad būtų galima išplėsti ir pritaikyti.
• Žaidimo kūrimas:
  • Žaidimų varikliai dažnai naudoja gamyklas, kad sukurtų įvairių tipų žaidimo objektus, simbolius ir lygius, skatindami kodo organizavimą ir lankstumą.
• Interneto kūrimas:
  • Žiniatinklio sistemos kartais naudoja gamyklas, kad sukurtų peržiūros komponentus, valdiklius ir paslaugas, todėl žiniatinklio programose galima moduliuoti ir išbandyti.

Gamyklinio metodo projektavimo modelio privalumai

Gamyklinio metodo projektavimo modelio pranašumai yra šie:

jvm java

• Atsiejimas: Jis atskiria objektų kūrimo logiką nuo kliento kodo, kuris naudoja tuos objektus. Dėl to kodas tampa lankstesnis ir lengviau prižiūrimas, nes kūrimo proceso pakeitimams nereikia keisti kliento kodo.
• Išplečiamumas: Nesunku įdiegti naujų produktų tipų nekeičiant kliento kodo. Jums tereikia sukurti naują Concrete Creator poklasį ir įdiegti gamyklinį metodą naujam produktui gaminti.
• Bandomumas: Tai supaprastina vienetų testavimą, nes leidžia tyčiotis arba sustabdyti produkto kūrimą bandymų metu. Galite išbandyti skirtingus produktų įgyvendinimus atskirai, nepasitikėdami tikruoju objekto kūrimu.
• Kodo pakartotinis naudojimas: Gamyklos metodas gali būti pakartotinai naudojamas įvairiose programos dalyse, kur reikia sukurti objektą. Tai skatina centralizuoti ir pakartotinai panaudoti objektų kūrimo logiką.
• Inkapsuliavimas: Jis paslepia konkrečias produktų klases nuo kliento kodo, todėl kodas yra mažiau priklausomas nuo konkrečių diegimų. Tai pagerina techninę priežiūrą ir sumažina sujungimą.

Gamyklinio metodo projektavimo modelio trūkumai

Gamyklos metodo projektavimo modelio trūkumai yra šie:

• Padidėjęs sudėtingumas: Jame pristatomos papildomos klasės ir sąsajos, pridedant abstrakcijos sluoksnį, dėl kurio kodą gali būti sudėtingiau suprasti ir prižiūrėti, ypač tiems, kurie nėra susipažinę su modeliu.
• Papildomos išlaidos: Polimorfizmo ir dinaminio surišimo naudojimas gali šiek tiek paveikti našumą, nors daugeliu atvejų tai yra nereikšminga.
• Tvirtas susiejimas produktų hierarchijose: Betono kūrėjai vis dar yra glaudžiai susiję su atitinkamais betono gaminiais. Pakeitus vieną, dažnai reikia pakeisti kitą.
• Priklausomybė nuo betono poklasių: Kliento kodas vis dar priklauso nuo abstrakčios Creator klasės, todėl norint atlikti teisingus gamyklinių metodų iškvietimus, reikia žinoti konkrečius jos poklasius.
• Perteklinio naudojimo galimybė: Svarbu apgalvotai naudoti gamyklinio metodo modelį, kad būtų išvengta pernelyg didelio programos projektavimo. Paprastas objektų kūrimas dažnai gali būti atliekamas tiesiogiai, nereikia gamyklos.
• Bandymo iššūkiai: Pačios gamyklos logikos testavimas gali būti sudėtingesnis.