Rūpnīcas metodes dizaina modelis ir a radošs dizaina modelis kas nodrošina saskarni objektu izveidei virsklasē, ļaujot apakšklasēm mainīt veidojamo objektu veidu. Tā iekapsulē objektu izveides loģiku atsevišķā metodē, veicinot brīvu saikni starp radītāju un izveidotajiem objektiem. Šis modelis ir īpaši noderīgs, ja precīzi veidojamo objektu tipi var atšķirties vai tie ir jānosaka izpildlaikā, nodrošinot objekta izveides elastību un paplašināšanu.

Satura rādītājs

• Kāds ir rūpnīcas metodes dizaina modelis?
• Kad izmantot rūpnīcas metodes dizaina modeli?
• Rūpnīcas metodes dizaina modeļa sastāvdaļas
• Rūpnīcas metodes dizaina modeļa piemērs
• Rūpnīcas metodes dizaina modeļa izmantošanas gadījumi
• Rūpnīcas metodes dizaina modeļa priekšrocības
• Rūpnīcas metodes dizaina modeļa trūkumi

Kāds ir rūpnīcas metodes dizaina modelis?

Factory Method Design Pattern ir jaunrades dizaina modelis, ko izmanto programmatūras inženierijā, lai nodrošinātu saskarni objektu izveidei virsklasē, vienlaikus ļaujot apakšklasēm mainīt veidojamo objektu veidu. Tā iekapsulē objektu izveides loģiku atsevišķā metodē, abstrahējot instantiācijas procesu un veicinot brīvu saikni starp radītāju un izveidotajiem objektiem. Šis modelis nodrošina elastību, paplašināšanu un apkopi kodu bāzē, ļaujot apakšklasēm definēt savu rūpnīcas metodes ieviešanu, lai izveidotu noteiktu veidu objektus.

css teksta līdzināšana

Kad izmantot rūpnīcas metodes dizaina modeli?

Izmantojiet rūpnīcas metodes dizaina modeli:

• Ja vēlaties iekapsulēt objekta izveidi: Ja jums ir sarežģīts objekta izveides process vai ja process var atšķirties atkarībā no apstākļiem, šīs loģikas iekapsulēšana rūpnīcas metodē var vienkāršot klienta kodu un veicināt atkārtotu izmantošanu.
• Ja vēlaties atsaistīt klienta kodu no konkrētām klasēm: Izmantojot rūpnīcas metodes modeli, varat izveidot objektus, izmantojot interfeisu vai abstraktu klasi, no klienta koda abstrahējot konkrēto klašu specifiskās ieviešanas detaļas. Tas veicina vaļīgu savienojumu un atvieglo sistēmas modifikāciju vai paplašināšanu, neietekmējot esošo klienta kodu.
• Ja jums ir jāatbalsta vairākas produktu variācijas: Ja jūsu lietojumprogrammai ir jāizveido dažādas produkta variācijas vai ja nākotnē var tikt ieviesti jauni produktu veidi, rūpnīcas metodes modelis nodrošina elastīgu veidu, kā pielāgot šīs variācijas, definējot rūpnīcas metodes katram produkta veidam.
• Ja vēlaties atbalstīt pielāgošanu vai konfigurāciju: Rūpnīcas var izmantot, lai iekapsulētu konfigurācijas loģiku, ļaujot klientiem pielāgot izveides procesu, nodrošinot parametrus vai konfigurācijas opcijas rūpnīcas metodei.

Rūpnīcas metodes dizaina modeļa sastāvdaļas

1. Radītājs

Šī ir abstrakta klase vai interfeiss, kas deklarē rūpnīcas metodi. Veidotājs parasti satur metodi, kas kalpo kā rūpnīca objektu izveidei. Tajā var būt arī citas metodes, kas darbojas ar izveidotajiem objektiem.

2. Betona veidotājs

Concrete Creator klases ir Creator apakšklases, kas ievieš rūpnīcas metodi, lai izveidotu noteiktu veidu objektus. Katrs betona veidotājs ir atbildīgs par konkrēta produkta izveidi.

3. Produkts

Šī ir saskarne vai abstraktā klase objektiem, ko izveido rūpnīcas metode. Produkts definē kopējo saskarni visiem objektiem, ko var izveidot rūpnīcas metode.

4. Betona izstrādājums

Konkrētās produktu klases ir faktiskie objekti, ko izveido rūpnīcas metode. Katra betona izstrādājuma klase ievieš produkta saskarni vai paplašina produkta abstrakto klasi.

xor java

Rūpnīcas metodes dizaina modeļa piemērs

Zemāk ir problēmas izklāsts, lai izprastu rūpnīcas metodes dizaina modeli:

Apsveriet lietojumprogrammu, kurai nepieciešams izveidot dažādu veidu transportlīdzekļus, piemēram, Two Wheelers, Three Wheelers un Four Wheelers. Katram transportlīdzekļa tipam ir savas specifiskās īpašības un uzvedība.

1. Bez rūpnīcas metodes dizaina parauga

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

Kādas ir problēmas ar iepriekš minēto dizainu?

Iepriekš minētajā koda dizainā:

• Stingrs savienojums: Klientu klaseClient>tieši rada konkrētās klases (TwoWheeler>unFourWheeler>), pamatojoties uz ievades veidu, kas tika nodrošināts tā izveides laikā. Tas noved pie ciešas saiknes starp klientu un konkrētajām klasēm, apgrūtinot koda uzturēšanu un paplašināšanu.
• Vienas atbildības principa (SRP) pārkāpums: TheClient>klase ir atbildīga ne tikai par transportlīdzekļa veida noteikšanu, pamatojoties uz ievades veidu, bet arī par transportlīdzekļa objekta dzīves cikla pārvaldību (piemēram, tīrīšana). Tas pārkāpj vienotas atbildības principu, kas nosaka, ka klasei ir tikai viens iemesls mainīties.
• Ierobežota mērogojamība: Lai pievienotu jauna tipa transportlīdzekli, ir jāmainaClient>klase, kas pārkāpj Atvērtā-slēgtā principu. Šis dizains nav mērogojams, jo tas nevar pielāgot jauna veida transportlīdzekļus, nemainot esošo kodu.

Kā mēs izvairāmies no problēmas?

• Definējiet rūpnīcas saskarni: Izveidot aVehicleFactory>saskarne vai abstraktā klase ar transportlīdzekļu izveides metodi.
• Iebūvēt betona rūpnīcas: Ieviest betona rūpnīcas klases (TwoWheelerFactory>unFourWheelerFactory>), kas īstenoVehicleFactory>saskarni un nodrošināt metodes, lai izveidotu konkrētu transportlīdzekļu tipu gadījumus.
• Refaktora klients: ModificētClient>klasē pieņemt aVehicleFactory>piemēram, nevis tieši transportlīdzekļus. Klients pieprasīs transportlīdzekli no rūpnīcas, novēršot nepieciešamību pēc nosacītās loģikas, kas balstīta uz transportlīdzekļu veidiem.
• Uzlabota elastība: Izmantojot šo pieeju, jaunu transportlīdzekļu veidu pievienošana ir tikpat vienkārša kā jaunas rūpnīcas klases izveide jaunajam transportlīdzekļa tipam, nemainot esošo klienta kodu.

2. Ar rūpnīcas metodes dizaina modeli

Sadalīsim kodu komponentu kodā:

1. Produkta saskarne

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

2. Betona izstrādājumi

// 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. Radītāja saskarne (rūpnīcas saskarne)

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

4. Betona veidotāji (betona rūpnīcas)

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

Pilns šī piemēra kods:

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

Iepriekš minētajā kodā:

lateksa fontu izmēri

• Vehicle> kalpo kā produkta saskarne, kas nosaka kopējo metodi printVehicle()> kas jāīsteno visiem betona izstrādājumiem.
• TwoWheeler> un FourWheeler> ir konkrētas produktu klases, kas pārstāv dažādu veidu transportlīdzekļus, ieviešot printVehicle()> metodi.
• VehicleFactory> darbojas kā veidotāja saskarne (rūpnīcas saskarne) ar metodi createVehicle()> kas pārstāv rūpnīcas metodi.
• TwoWheelerFactory> un FourWheelerFactory> ir konkrētas radītāju klases (betona rūpnīcas), kas īsteno VehicleFactory> saskarne, lai izveidotu konkrētu veidu transportlīdzekļu gadījumus.

Rūpnīcas metodes dizaina modeļa izmantošanas gadījumi

Šeit ir daži izplatīti rūpnīcas metodes dizaina modeļa lietojumi:

• Radīšanas ietvari:
  • JDBC (Java datu bāzes savienojamība) plaši izmanto rūpnīcas, lai izveidotu savienojumus, paziņojumus un rezultātu kopas. Atkarības ievadīšanas sistēmas, piemēram, Spring un Guice, pupiņu izveidei un pārvaldībai lielā mērā ir atkarīgas no rūpnīcām.
• GUI rīkkopas:
  • Swing un JavaFX izmanto rūpnīcas, lai izveidotu lietotāja interfeisa komponentus, piemēram, pogas, teksta laukus un etiķetes, kas ļauj pielāgot un elastīgi izstrādāt lietotāja interfeisu.
• Mežizstrādes ietvari:
  • Reģistrācijas sistēmas, piemēram, Log4j un Logback, izmanto rūpnīcas, lai izveidotu reģistrētājus ar dažādām konfigurācijām, ļaujot kontrolēt reģistrēšanas līmeņus un izvades galamērķus.
• Serializācija un deserializācija:
  • Objektu serializācijas sistēmas bieži izmanto rūpnīcas, lai izveidotu objektus no serializētiem datiem, atbalstot dažādus serializācijas formātus un versiju veidošanu.
• Spraudņu sistēmas:
  • Uz spraudņiem balstītās sistēmas bieži izmanto rūpnīcas, lai dinamiski ielādētu un izveidotu spraudņu gadījumus, tādējādi nodrošinot paplašināšanu un pielāgošanu.
• Spēļu izstrāde:
  • Spēļu dzinēji bieži izmanto rūpnīcas, lai izveidotu dažāda veida spēļu objektus, rakstzīmes un līmeņus, veicinot koda organizēšanu un elastību.
• Web izstrāde:
  • Tīmekļa ietvari dažkārt izmanto rūpnīcas, lai izveidotu skata komponentus, kontrollerus un pakalpojumus, nodrošinot modularitāti un pārbaudāmību tīmekļa lietojumprogrammās.

Rūpnīcas metodes dizaina modeļa priekšrocības

Rūpnīcas metodes dizaina modeļa priekšrocības ir:

korekts java

• Atsaiste: Tas atdala objektu izveides loģiku no klienta koda, kas izmanto šos objektus. Tas padara kodu elastīgāku un apkopējamāku, jo izveides procesa izmaiņām nav nepieciešamas izmaiņas klienta kodā.
• Paplašināmība: Ir viegli ieviest jaunus produktu veidus, nemainot klienta kodu. Jums vienkārši jāizveido jauna Concrete Creator apakšklase un jāievieš rūpnīcas metode, lai ražotu jauno produktu.
• Pārbaudāmība: Tas vienkāršo vienību testēšanu, ļaujot pārbaužu laikā izsmiet vai apturēt produkta izveidi. Jūs varat pārbaudīt dažādu produktu ieviešanu atsevišķi, nepaļaujoties uz faktisko objektu izveidi.
• Koda atkārtota izmantošana: Rūpnīcas metodi var atkārtoti izmantot dažādās lietojumprogrammas daļās, kur ir nepieciešams izveidot objektu. Tas veicina objektu izveides loģikas centralizāciju un atkārtotu izmantošanu.
• Iekapsulēšana: Tas slēpj konkrētas produktu klases no klienta koda, padarot kodu mazāk atkarīgu no konkrētām implementācijām. Tas uzlabo apkopi un samazina savienojumu.

Rūpnīcas metodes dizaina modeļa trūkumi

Rūpnīcas metodes dizaina modeļa trūkumi ir:

• Paaugstināta sarežģītība: Tas ievieš papildu klases un saskarnes, pievienojot abstrakcijas slāni, kas var padarīt kodu sarežģītāku, lai to saprastu un uzturētu, īpaši tiem, kas nav pazīstami ar modeli.
• Pieskaitāmās izmaksas: Polimorfisma un dinamiskās saistīšanas izmantošana var nedaudz ietekmēt veiktspēju, lai gan lielākajā daļā lietojumu tas bieži vien ir nenozīmīgs.
• Stingra saikne produktu hierarhijās: Betona veidotāji joprojām ir cieši saistīti ar atbilstošajiem betona izstrādājumiem. Izmaiņas vienā bieži prasa izmaiņas citā.
• Atkarība no betona apakšklasēm: Klienta kods joprojām ir atkarīgs no abstraktās Creator klases, un, lai veiktu pareizus rūpnīcas metožu izsaukumus, ir nepieciešamas zināšanas par tās konkrētajām apakšklasēm.
• Pārmērīgas izmantošanas potenciāls: Ir svarīgi saprātīgi izmantot rūpnīcas metodes modeli, lai izvairītos no pārmērīgas lietojumprogrammas izstrādes. Vienkāršu objektu izveidi bieži var veikt tieši bez rūpnīcas nepieciešamības.
• Testēšanas izaicinājumi: Rūpnīcas loģikas pārbaude var būt sarežģītāka.