Návrhový vzor tovární metody je a kreativní designový vzor který poskytuje rozhraní pro vytváření objektů v nadtřídě, což umožňuje podtřídám měnit typ objektů, které budou vytvořeny. Zapouzdřuje logiku vytváření objektů do samostatné metody a podporuje volné spojení mezi tvůrcem a vytvořenými objekty. Tento vzor je zvláště užitečný, když se přesné typy objektů, které mají být vytvořeny, mohou lišit nebo je třeba určit za běhu, což umožňuje flexibilitu a rozšiřitelnost při vytváření objektů.

Obsah

• Jaký je návrhový vzor tovární metody?
• Kdy použít návrhový vzor tovární metody?
• Součásti návrhového vzoru tovární metody
• Příklad vzoru návrhu tovární metody
• Případy použití návrhového vzoru tovární metody
• Výhody návrhového vzoru tovární metody
• Nevýhody návrhového vzoru tovární metody

Jaký je návrhový vzor tovární metody?

Návrhový vzor Factory Method je kreativní návrhový vzor používaný v softwarovém inženýrství k poskytování rozhraní pro vytváření objektů v nadtřídě a zároveň umožňuje podtřídám měnit typ objektů, které budou vytvořeny. Zapouzdřuje logiku vytváření objektů do samostatné metody, abstrahuje proces vytváření instancí a podporuje volné spojení mezi tvůrcem a vytvořenými objekty. Tento vzor umožňuje flexibilitu, rozšiřitelnost a udržovatelnost v kódové základně tím, že umožňuje podtřídám definovat vlastní implementaci tovární metody pro vytváření specifických typů objektů.

rosomák vs jezevec

Kdy použít návrhový vzor tovární metody?

Použít návrhový vzor tovární metody:

• Když chcete zapouzdřit vytváření objektů: Pokud máte složitý proces vytváření objektů nebo pokud se proces může lišit v závislosti na podmínkách, zapouzdření této logiky do tovární metody může zjednodušit klientský kód a podpořit opětovnou použitelnost.
• Když chcete oddělit klientský kód od konkrétních tříd: Použití vzoru továrních metod vám umožňuje vytvářet objekty prostřednictvím rozhraní nebo abstraktní třídy abstrahováním specifických implementačních detailů konkrétních tříd z klientského kódu. To podporuje volné propojení a usnadňuje úpravu nebo rozšíření systému bez dopadu na stávající klientský kód.
• Pokud potřebujete podporovat více variant produktu: Pokud vaše aplikace potřebuje vytvořit různé varianty produktu nebo pokud mohou být v budoucnu zavedeny nové typy produktů, vzor továrních metod poskytuje flexibilní způsob, jak se těmto variacím přizpůsobit definováním továrních metod pro každý typ produktu.
• Pokud chcete podpořit přizpůsobení nebo konfiguraci: Továrny lze použít k zapouzdření logiky konfigurace, což klientům umožňuje přizpůsobit proces vytváření poskytnutím parametrů nebo možností konfigurace tovární metodě.

Součásti návrhového vzoru tovární metody

1. Tvůrce

Toto je abstraktní třída nebo rozhraní, které deklaruje tovární metodu. Tvůrce obvykle obsahuje metodu, která slouží jako továrna na vytváření objektů. Může obsahovat i další metody, které pracují s vytvořenými objekty.

2. Tvůrce betonu

Třídy Concrete Creator jsou podtřídy třídy Creator, které implementují tovární metodu pro vytváření specifických typů objektů. Každý tvůrce betonu je zodpovědný za vytvoření konkrétního produktu.

referenční proměnná v jazyce Java

3. Produkt

Toto je rozhraní nebo abstraktní třída pro objekty, které vytváří metoda factory. Produkt definuje společné rozhraní pro všechny objekty, které může tovární metoda vytvořit.

4. Betonový výrobek

Třídy Concrete Product jsou skutečné objekty, které tovární metoda vytváří. Každá třída konkrétního produktu implementuje rozhraní produktu nebo rozšiřuje abstraktní třídu produktu.

Příklad vzoru návrhu tovární metody

Níže je uveden problém pro pochopení vzoru návrhu tovární metody:

Zvažte softwarovou aplikaci, která potřebuje zvládnout vytváření různých typů vozidel, jako jsou dvoukolky, tříkolky a čtyřkolky. Každý typ vozidla má své specifické vlastnosti a chování.

1. Bez Návrhového Vzoru Tovární Metody

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

Jaké jsou problémy s výše uvedeným designem?

Ve výše uvedeném návrhu kódu:

• Těsné spojení: Třída klientůClient>přímo vytváří instance konkrétních tříd (TwoWheeler>aFourWheeler>) na základě typu vstupu poskytnutého při jeho konstrukci. To vede k těsnému propojení mezi klientem a konkrétními třídami, což ztěžuje údržbu a rozšiřování kódu.
• Porušení principu jednotné odpovědnosti (SRP): TheClient>třída je odpovědná nejen za určení, který typ vozidla se má vytvořit na základě typu vstupu, ale také za správu životního cyklu objektu vozidla (např. To porušuje princip jednotné odpovědnosti, který říká, že třída by měla mít pouze jeden důvod ke změně.
• Omezená škálovatelnost: Přidání nového typu vozidla vyžaduje úpravuClient>třídy, která porušuje princip otevřeno-uzavřeno. Tento návrh není škálovatelný, protože se nemůže přizpůsobit novým typům vozidel bez úpravy stávajícího kódu.

Jak se problému vyhneme?

• Definujte tovární rozhraní: VytvořitVehicleFactory>rozhraní nebo abstraktní třídy s metodou pro vytváření vozidel.
• Implementace betonových továren: Implementujte třídy betonových továren (TwoWheelerFactory>aFourWheelerFactory>), které implementujíVehicleFactory>rozhraní a poskytují metody pro vytváření instancí konkrétních typů vozidel.
• Klient Refaktoru: UpravteClient>třídy přijmout aVehicleFactory>místo přímého vytváření instance vozidel. Klient si vyžádá vozidlo z továrny, čímž eliminuje potřebu podmíněné logiky založené na typech vozidel.
• Vylepšená flexibilita: S tímto přístupem je přidávání nových typů vozidel stejně jednoduché jako vytvoření nové tovární třídy pro nový typ vozidla bez úpravy stávajícího klientského kódu.

2. S Návrhovým Vzorem Tovární Metody

Pojďme si kód rozdělit na kód po komponentách:

1. Rozhraní produktu

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

2. Betonové výrobky

// 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. Rozhraní pro tvůrce (tovární rozhraní)

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

4. Concrete Creators (Concrete Factory)

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

Kompletní kód tohoto příkladu:

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

Ve výše uvedeném kódu:

char a int java

• Vehicle> slouží jako rozhraní produktu, definující společnou metodu printVehicle()> že všechny betonové výrobky musí implementovat.
• TwoWheeler> a FourWheeler> jsou konkrétní produktové třídy představující různé typy vozidel, implementující printVehicle()> metoda.
• VehicleFactory> funguje jako rozhraní Creator (Factory Interface) s metodou createVehicle()> představující tovární metodu.
• TwoWheelerFactory> a FourWheelerFactory> jsou konkrétní třídy tvůrců (Concrete Factories) implementující VehicleFactory> rozhraní pro vytváření instancí konkrétních typů vozidel.

Případy použití návrhového vzoru tovární metody

Zde jsou některé běžné aplikace vzoru Factory Method Design:

• Tvůrčí rámce:
  • JDBC (Java Database Connectivity) široce využívá továrny pro vytváření připojení, příkazů a sad výsledků. Rámce pro vkládání závislostí jako Spring a Guice se při vytváření a správě fazolí do značné míry spoléhají na továrny.
• GUI Toolkits:
  • Swing a JavaFX využívají továrny k vytváření komponent uživatelského rozhraní, jako jsou tlačítka, textová pole a štítky, což umožňuje přizpůsobení a flexibilitu návrhu uživatelského rozhraní.
• Logovací rámce:
  • Logovací rámce jako Log4j a Logback využívají továrny k vytváření loggerů s různými konfiguracemi, což umožňuje kontrolu nad úrovněmi protokolování a výstupními cíli.
• Serializace a deserializace:
  • Rámce serializace objektů často používají továrny k vytváření objektů ze serializovaných dat, které podporují různé formáty serializace a verzování.
• Systémy pluginů:
  • Systémy založené na zásuvných modulech často používají továrny k dynamickému načítání a vytváření instancí zásuvných modulů, což umožňuje rozšiřitelnost a přizpůsobení.
• Vývoj hry:
  • Herní enginy často využívají továrny k vytváření různých typů herních objektů, postav a úrovní, což podporuje organizaci kódu a flexibilitu.
• Vývoj webu:
  • Webové rámce někdy používají továrny k vytváření komponent zobrazení, řadičů a služeb, což umožňuje modularitu a testovatelnost webových aplikací.

Výhody návrhového vzoru tovární metody

Výhody modelu Factory Method Design Pattern jsou:

json v příkladu json

• Oddělení: Odděluje logiku vytváření objektů od klientského kódu, který tyto objekty používá. Díky tomu je kód flexibilnější a udržovatelný, protože změny v procesu vytváření nevyžadují úpravy kódu klienta.
• Rozšiřitelnost: Je snadné zavádět nové typy produktů bez změny klientského kódu. Jednoduše potřebujete vytvořit novou podtřídu Concrete Creator a implementovat tovární metodu pro výrobu nového produktu.
• Testovatelnost: Zjednodušuje testování jednotek tím, že vám během testů umožňuje zesměšňovat nebo potlačovat vytváření produktů. Můžete testovat různé implementace produktu izolovaně, aniž byste se spoléhali na skutečné vytváření objektů.
• Znovupoužitelnost kódu: Tovární metodu lze znovu použít v různých částech aplikace, kde je potřeba vytvořit objekt. To podporuje centralizaci a opětovné použití logiky vytváření objektů.
• Zapouzdření: Skrývá konkrétní třídy produktů před klientským kódem, takže kód je méně závislý na konkrétních implementacích. To zlepšuje udržovatelnost a snižuje spojování.

Nevýhody návrhového vzoru tovární metody

Nevýhody Factory Method Design Pattern jsou:

• Zvýšená složitost: Zavádí další třídy a rozhraní a přidává vrstvu abstrakce, díky níž je kód složitější na pochopení a údržbu, zejména pro ty, kteří tento vzor neznají.
• Režie: Použití polymorfismu a dynamické vazby může mírně ovlivnit výkon, i když to je ve většině aplikací často zanedbatelné.
• Těsné propojení v rámci produktových hierarchií: Concrete Creators jsou stále pevně spojeni s příslušnými betonovými produkty. Změny jednoho často vyžadují změny druhého.
• Závislost na betonových podtřídách: Klientský kód stále závisí na abstraktní třídě Creator a vyžaduje znalost jejích konkrétních podtříd, aby bylo možné správně zavolat tovární metodu.
• Potenciál nadužívání: Je důležité používat vzor tovární metody uvážlivě, abyste se vyhnuli nadměrnému inženýrství aplikace. Jednoduché vytváření objektů lze často zvládnout přímo bez potřeby továrny.
• Testovací výzvy: Samotné testování tovární logiky může být složitější.