logo

TechCodeview

Fabrieksmethode ontwerppatroon in Java

Het is een creatie ontwerppatroon dat gaat over de creatie van een object. Het fabrieksontwerppatroon zegt dat een interface (een Java-interface of een abstracte klasse) moet worden gedefinieerd voor het maken van het object en dat de subklassen moeten beslissen welke klasse moet worden geïnstantieerd.

Java-referentietypen

fabrieksmethode



Belangrijke onderwerpen voor het ontwerppatroon van de fabrieksmethode in Java

Wat is het Factory Method Design Pattern in Java?

Factory Method Design Pattern definieert een interface voor het maken van een object, maar laat de subklasse beslissen welke klasse moet worden geïnstantieerd. Met de fabrieksmethode kan een klasse de instantiatie naar een subklasse uitstellen.

Wat-is-fabrieksmethode-ontwerppatroon



Hieronder vindt u de uitleg van de bovenstaande afbeelding:

  • Dankzij de fabrieksmethode in de interface kan een klasse de instantiatie naar een of meer concrete subklassen uitstellen.
  • Omdat deze ontwerppatronen spreken over de instantiatie van een object, vallen ze onder de categorie van creatiepatronen.
  • Als we de naam opmerken Fabrieksmethode Dat betekent dat er een methode is die een fabriek is, en over het algemeen houden fabrieken zich bezig met creatie en hier wordt een object gecreëerd.
  • Het is een van de beste manieren om een ​​object te maken waarbij de logica voor het maken van objecten verborgen is voor de client. Laten we nu eens kijken naar de implementatie.

Wanneer gebruik ik het Factory Method Design Pattern in Java?

Het ontwerppatroon van de fabrieksmethode kan in de volgende gevallen in Java worden gebruikt:

  • Een klasse kan niet voorspellen welk type objecten hij moet maken.
  • Een klasse wil dat zijn subklassen de objecten specificeren die hij maakt.
  • Klassen delegeren de verantwoordelijkheid aan een van meerdere helper-subklassen, en u streeft ernaar de informatie te behouden over welke helper-subklasse de gedelegeerde is binnen een specifiek bereik of een specifieke locatie.

Belangrijkste componenten van het ontwerppatroon van de fabrieksmethode

Key-Component-of-Factory-Method-Design-Pattern-in-Java



Product

  • Het is een abstracte klasse of interface die de algemene bewerkingen definieert voor de objecten die de fabriek gaat maken.
  • Concrete Products zijn de daadwerkelijke klassen die de Productinterface implementeren, en vertegenwoordigen elk een specifiek type object dat moet worden gemaakt.

Schepper

  • Het is een abstracte klasse of interface die de fabrieksmethode declareert.
  • Deze methode is verantwoordelijk voor het maken van Product-objecten, maar delegeert de daadwerkelijke creatie aan subklassen.

Concrete makers

  • Dit zijn subklassen van de Creator die de fabrieksmethode implementeren.
  • Zij beslissen welk specifiek betonproduct ze willen maken, vaak op basis van invoerparameters of configuratie.

Fabrieksmethode

  • Het is een methode gedefinieerd in de Creator-klasse die verantwoordelijk is voor het maken van Product-objecten.
  • Het wordt doorgaans als abstract gedeclareerd in de Creator en geïmplementeerd in de Concrete Creators.

Fabrieksmethode ontwerppatroonvoorbeeld in Java

Probleemstelling

Je ontwikkelt een softwaresysteem voor een e-commerceplatform dat zich bezighoudt met verschillende soorten producten. Elke productcategorie (bijvoorbeeld elektronica, kleding, boeken) vereist een specifieke behandeling tijdens de creatie. U wilt echter de klantcode loskoppelen van de concrete logica voor het maken van producten om de flexibiliteit en onderhoudbaarheid te vergroten. Bovendien wilt u een gemakkelijke uitbreiding mogelijk maken door in de toekomst nieuwe producttypen toe te voegen zonder de bestaande code te wijzigen.

Oplossing met behulp van abstracte klasse

Het bovenstaande probleem kan worden opgelost met behulp van het Factory Method Design Pattern:

Java


Linux run-opdracht



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

>

>

wanneer werd de school uitgevonden?
Uitvoer 

This is Concrete Product A. This is Concrete Product B.>

Oplossing met behulp van Interface

Het bovenstaande probleem kan worden opgelost met behulp van het Factory Method Design Pattern:

Java


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

>

git-status 

>

Uitvoer 

This is Concrete Product A. This is Concrete Product B.>

Gebruiksscenario's van het Factory Method Design Pattern in Java

Hier zijn enkele veelvoorkomende toepassingen van het Factory Method Design-patroon in Java:

  • Creatiekaders:
    • JDBC (Java Database Connectivity) maakt veelvuldig gebruik van fabrieken voor het maken van verbindingen, instructies en resultatensets. Raamwerken voor afhankelijkheidsinjectie zoals Spring en Guice zijn sterk afhankelijk van fabrieken om bonen te creëren en te beheren.
  • GUI-toolkits:
    • Swing en JavaFX gebruiken fabrieken om UI-componenten zoals knoppen, tekstvelden en labels te creëren, waardoor maatwerk en flexibiliteit in het UI-ontwerp mogelijk zijn.
  • Kaders voor logboekregistratie:
    • Logboekframeworks zoals Log4j en Logback gebruiken fabrieken om loggers met verschillende configuraties te maken, waardoor controle over logniveaus en uitvoerbestemmingen mogelijk wordt.
  • Serialisatie en deserialisatie:
    • Objectserialisatieframeworks maken vaak gebruik van fabrieken om objecten te creëren op basis van geserialiseerde gegevens, waarbij verschillende serialisatieformaten en versiebeheer worden ondersteund.
  • Plugin-systemen:
    • Op plug-ins gebaseerde systemen maken vaak gebruik van fabrieken om plug-ins dynamisch te laden en te maken, waardoor uitbreidbaarheid en maatwerk mogelijk zijn.
  • Spelontwikkeling:
    • Game-engines gebruiken vaak fabrieken om verschillende soorten game-objecten, personages en niveaus te creëren, waardoor de code-organisatie en flexibiliteit worden bevorderd.
  • Webontwikkeling:
    • Webframeworks maken soms gebruik van fabrieken om weergavecomponenten, controllers en services te creëren, waardoor modulariteit en testbaarheid in webapplicaties mogelijk wordt.

Voordelen van Factory Method Design Pattern in Java

De voordelen van Factory Method Design Pattern in Java zijn:

  • Ontkoppeling: Het scheidt de logica voor het maken van objecten van de clientcode die deze objecten gebruikt. Dit maakt de code flexibeler en onderhoudbaarder, omdat wijzigingen in het creatieproces geen aanpassingen aan de clientcode vereisen.
  • Uitbreidbaarheid: Het is eenvoudig om nieuwe producttypen te introduceren zonder de klantcode te wijzigen. U hoeft alleen maar een nieuwe Concrete Creator-subklasse te maken en de fabrieksmethode te implementeren om het nieuwe product te produceren.
  • Testbaarheid: Het vereenvoudigt het testen van eenheden doordat u tijdens tests de productcreatie kunt bespotten of uitsluiten. U kunt verschillende productimplementaties afzonderlijk testen zonder afhankelijk te zijn van de daadwerkelijke objectcreatie.
  • Herbruikbaarheid van code: De fabrieksmethode kan worden hergebruikt in verschillende delen van de applicatie waar objectcreatie nodig is. Dit bevordert het centraliseren en hergebruiken van de logica voor het maken van objecten.
  • Inkapseling: Het verbergt de concrete productklassen voor de klantcode, waardoor de code minder afhankelijk wordt van specifieke implementaties. Dit verbetert de onderhoudbaarheid en vermindert koppeling.

Nadelen van het fabrieksmethode-ontwerppatroon in Java

De nadelen van Factory Method Design Pattern in Java zijn:

  • Verhoogde complexiteit: Het introduceert extra klassen en interfaces en voegt een abstractielaag toe die de code complexer kan maken om te begrijpen en te onderhouden, vooral voor degenen die niet bekend zijn met het patroon.
  • Bovengronds: Het gebruik van polymorfisme en dynamische binding kan de prestaties enigszins beïnvloeden, hoewel dit in de meeste toepassingen vaak verwaarloosbaar is.
  • Nauwe koppeling binnen producthiërarchieën: Concrete Creators zijn nog steeds nauw verbonden met hun bijbehorende betonproducten. Veranderingen in het ene vereisen vaak veranderingen in het andere.
  • Afhankelijkheid van betonsubklassen: De clientcode is nog steeds afhankelijk van de abstracte Creator-klasse, waardoor kennis van de concrete subklassen ervan vereist is om correcte fabrieksmethode-aanroepen te kunnen doen.
  • Potentieel voor overmatig gebruik: Het is belangrijk om het Factory Method-patroon oordeelkundig te gebruiken om over-engineering van de applicatie te voorkomen. Het eenvoudig maken van objecten kan vaak direct worden afgehandeld, zonder dat er een fabriek voor nodig is.
  • Uitdagingen testen: Het testen van de fabriekslogica zelf kan complexer zijn.

Conclusie

Tot nu toe hebben we geleerd wat het ontwerppatroon van de fabrieksmethode is en hoe we dit kunnen implementeren. Ik geloof dat we nu een goed begrip hebben van het voordeel van dit ontwerpmechanisme. Fabrieksmethoden zijn overal aanwezig in toolkits en raamwerken. Het voorgaande documentvoorbeeld is een typisch gebruik in MacApp en ET++.

Verder lezen : Zelfstudie over Java-ontwerppatronen