Det er en kreativt designmønster som snakker om opprettelsen av et objekt. Fabrikkdesignmønsteret sier å definere et grensesnitt (Et java-grensesnitt eller en abstrakt klasse) for å lage objektet og la underklassene bestemme hvilken klasse som skal instansieres.
Viktige emner for fabrikkmetodens designmønster i Java
- Hva er Factory Method Design Pattern i Java?
- Når skal du bruke Factory Method Design Pattern i Java?
- Nøkkelkomponenter i fabrikkmetodedesignmønster
- Eksempel på fabrikkmetodedesignmønster i Java
- Brukstilfeller av Factory Method Design Pattern i Java
- Fordeler med Factory Method Design Pattern i Java
- Ulemper med Factory Method Design Pattern i Java
Hva er Factory Method Design Pattern i Java?
Factory Method Design Pattern definerer et grensesnitt for å lage et objekt, men la underklassen bestemme hvilken klasse som skal instansieres. Factory Method lar en klasse utsette instansiering til underklasse.
streng og understreng
Nedenfor er forklaringen av bildet ovenfor:
- Fabrikkmetoden i grensesnittet lar en klasse utsette instansieringen til en eller flere konkrete underklasser.
- Siden disse designmønstrene snakker om instansieringen av et objekt, kommer de inn under kategorien kreativt designmønster.
- Hvis vi legger merke til navnet Fabrikkmetode , det betyr at det er en metode som er en fabrikk, og generelt er fabrikker involvert i kreasjonsting og her med dette blir et objekt skapt.
- Det er en av de beste måtene å lage et objekt der objektopprettingslogikken er skjult for klienten. La oss nå se på implementeringen.
Når skal du bruke Factory Method Design Pattern i Java?
Fabrikkmetodedesignmønster kan brukes i java i følgende tilfeller:
- En klasse kan ikke forutsi hvilken type objekter den må lage.
- En klasse vil at underklassene skal spesifisere objektene den oppretter.
- Klasser delegerer ansvar til en av flere hjelpeunderklasser, og du tar sikte på å holde informasjonen om hvilken hjelpeunderklasse som er delegaten innenfor et spesifikt omfang eller sted.
Nøkkelkomponenter i fabrikkmetodedesignmønster
Produkt
- Det er en abstrakt klasse eller grensesnitt som definerer de vanlige operasjonene for objektene som fabrikken skal lage.
- Konkrete produkter er de faktiske klassene som implementerer produktgrensesnittet, som hver representerer en bestemt type objekt som skal opprettes.
Skaperen
- Det er en abstrakt klasse eller grensesnitt som erklærer fabrikkmetoden.
- Denne metoden er ansvarlig for å lage produktobjekter, men den delegerer selve opprettelsen til underklasser.
Betongskapere
- Dette er underklasser av Skaperen som implementerer fabrikkmetoden.
- De bestemmer hvilket konkret betongprodukt de skal lage, ofte basert på inndataparametere eller konfigurasjon.
Fabrikkmetode
- Det er en metode definert i Creator-klassen som er ansvarlig for å lage produktobjekter.
- Det er vanligvis erklært som abstrakt i skaperen og implementert i de konkrete skaperne.
Eksempel på fabrikkmetodedesignmønster i Java
Problemstilling
Du utvikler et programvaresystem for en e-handelsplattform som omhandler ulike typer produkter. Hver produktkategori (f.eks. elektronikk, klær, bøker) krever spesifikk håndtering under opprettelsen. Du ønsker imidlertid å koble klientkoden fra den konkrete produktopprettingslogikken for å øke fleksibiliteten og vedlikeholdet. I tillegg vil du tillate enkel utvidelse ved å legge til nye produkttyper i fremtiden uten å endre eksisterende kode.
Løsning med abstrakt klasse
Problemet ovenfor kan løses ved å bruke Factory Method Design Pattern:
Java
// Abstract Product Class> abstract> class> Product {> > public> abstract> void> display();> }> // Concrete Products> class> ConcreteProductA> extends> Product {> > @Override> > public> void> display() {> > System.out.println(> 'This is Concrete Product A.'> );> > }> }> class> ConcreteProductB> extends> Product {> > @Override> > public> void> display() {> > System.out.println(> 'This is Concrete Product B.'> );> > }> }> // Creator Abstract Class> abstract> class> Creator {> > public> abstract> Product factoryMethod();> }> // Concrete Creators> class> ConcreteCreatorA> extends> Creator {> > @Override> > public> Product factoryMethod() {> > return> new> ConcreteProductA();> > }> }> class> ConcreteCreatorB> extends> Creator {> > @Override> > public> Product factoryMethod() {> > return> new> ConcreteProductB();> > }> }> // Client Code> public> class> FactoryMethodExample {> > public> static> void> main(String[] args) {> > Creator creatorA => new> ConcreteCreatorA();> > Product productA = creatorA.factoryMethod();> > productA.display();> > Creator creatorB => new> ConcreteCreatorB();> > Product productB = creatorB.factoryMethod();> > productB.display();> > }> }> |
>
ls kommandoer linux
>Produksjon
This is Concrete Product A. This is Concrete Product B.>
Løsning ved hjelp av grensesnitt
Problemet ovenfor kan løses ved å bruke Factory Method Design Pattern:
Java
// Product Interface> interface> Product {> > void> display();> }> // Concrete Products> class> ConcreteProductA> implements> Product {> > @Override> > public> void> display() {> > System.out.println(> 'This is Concrete Product A.'> );> > }> }> class> ConcreteProductB> implements> Product {> > @Override> > public> void> display() {> > System.out.println(> 'This is Concrete Product B.'> );> > }> }> // Factory Interface> interface> Factory {> > Product factoryMethod();> }> // Concrete Factories> class> ConcreteFactoryA> implements> Factory {> > @Override> > public> Product factoryMethod() {> > return> new> ConcreteProductA();> > }> }> class> ConcreteFactoryB> implements> Factory {> > @Override> > public> Product factoryMethod() {> > return> new> ConcreteProductB();> > }> }> // Client Code> public> class> FactoryMethodExample {> > public> static> void> main(String[] args) {> > Factory factoryA => new> ConcreteFactoryA();> > Product productA = factoryA.factoryMethod();> > productA.display();> > Factory factoryB => new> ConcreteFactoryB();> > Product productB = factoryB.factoryMethod();> > productB.display();> > }> }> |
>
>Produksjon
This is Concrete Product A. This is Concrete Product B.>
Brukstilfeller av Factory Method Design Pattern i Java
Her er noen vanlige bruksområder for Factory Method Design-mønsteret i Java:
- Kreasjonelle rammer:
- JDBC (Java Database Connectivity) bruker fabrikker i utstrakt grad for å lage tilkoblinger, uttalelser og resultatsett. Avhengighetsinjeksjonsrammer som Spring og Guice er sterkt avhengige av fabrikker for å lage og administrere bønner.
- GUI-verktøysett:
- Swing og JavaFX bruker fabrikker til å lage UI-komponenter som knapper, tekstfelt og etiketter, noe som gir mulighet for tilpasning og fleksibilitet i UI-design.
- Loggingsrammer:
- Loggrammeverk som Log4j og Logback bruker fabrikker til å lage loggere med forskjellige konfigurasjoner, som muliggjør kontroll over loggingsnivåer og utdatadestinasjoner.
- Serialisering og deserialisering:
- Objektserialiseringsrammeverk bruker ofte fabrikker til å lage objekter fra serialiserte data, og støtter forskjellige serialiseringsformater og versjonsstyring.
- Plugin-systemer:
- Plugin-baserte systemer bruker ofte fabrikker for å laste og lage plugin-forekomster dynamisk, noe som gir mulighet for utvidbarhet og tilpasning.
- Spillutvikling:
- Spillmotorer bruker ofte fabrikker til å lage forskjellige typer spillobjekter, karakterer og nivåer, og fremmer kodeorganisering og fleksibilitet.
- Webutvikling:
- Web-rammeverk bruker noen ganger fabrikker for å lage visningskomponenter, kontrollere og tjenester, noe som muliggjør modularitet og testbarhet i webapplikasjoner.
Fordeler med Factory Method Design Pattern i Java
Fordelene med Factory Method Design Pattern i Java er:
- Frakobling: Den skiller objektopprettingslogikken fra klientkoden som bruker disse objektene. Dette gjør koden mer fleksibel og vedlikeholdbar fordi endringer i opprettelsesprosessen ikke krever endringer i klientkoden.
- Utvidbarhet: Det er enkelt å introdusere nye produkttyper uten å endre klientkoden. Du trenger bare å lage en ny Concrete Creator-underklasse og implementere fabrikkmetoden for å produsere det nye produktet.
- Testbarhet: Det forenkler enhetstesting ved å tillate deg å håne eller stoppe produktoppretting under tester. Du kan teste ulike produktimplementeringer isolert uten å stole på faktisk objektoppretting.
- Gjenbrukbarhet av kode: Fabrikkmetoden kan gjenbrukes i ulike deler av applikasjonen der det er behov for objektoppretting. Dette fremmer sentralisering og gjenbruk av objektopprettingslogikk.
- Innkapsling: Den skjuler de konkrete produktklassene fra klientkoden, noe som gjør koden mindre avhengig av spesifikke implementeringer. Dette forbedrer vedlikeholdsevnen og reduserer koblingen.
Ulemper med Factory Method Design Pattern i Java
Ulempene med Factory Method Design Pattern i Java er:
switch statement java
- Økt kompleksitet: Den introduserer flere klasser og grensesnitt, og legger til et lag med abstraksjon som kan gjøre koden mer kompleks å forstå og vedlikeholde, spesielt for de som ikke er kjent med mønsteret.
- Overhead: Bruken av polymorfisme og dynamisk binding kan påvirke ytelsen litt, selv om dette ofte er ubetydelig i de fleste applikasjoner.
- Tett kopling innen produkthierarkier: Betongskapere er fortsatt tett koblet til deres tilsvarende betongprodukter. Endringer i den ene krever ofte endringer i den andre.
- Avhengighet av betongunderklasser: Klientkoden avhenger fortsatt av den abstrakte Creator-klassen, og krever kunnskap om dens konkrete underklasser for å foreta korrekte fabrikkmetodekall.
- Potensial for overforbruk: Det er viktig å bruke fabrikkmetodemønsteret med omtanke for å unngå å overkonstruere applikasjonen. Enkel objektoppretting kan ofte håndteres direkte uten behov for en fabrikk.
- Testutfordringer: Å teste selve fabrikklogikken kan være mer kompleks.
Konklusjon
Så langt har vi lært hva som er fabrikkmetodedesignmønster og hvordan vi implementerer det. Jeg tror nå vi har en rettferdig forståelse av fordelen med denne designmekanismen. Fabrikkmetoder gjennomsyrer verktøysett og rammeverk. Det foregående dokumenteksemplet er en typisk bruk i MacApp og ET++.
Les videre : Opplæring i Java Design Patterns