Introduction
In dit artikel gaan we dieper in op het Factory Method Design Pattern, geà mplementeerd in Python.
ontwerppatronen definiëren beproefde oplossingen voor verschillende terugkerende problemen in softwareontwikkeling. Ze vertegenwoordigen geen echte code, maar manieren waarop we onze code kunnen organiseren voor de optimale resultaten.
in een wereld met beperkte middelen helpen ontwerppatronen ons om de meeste resultaten te bereiken met de minste hoeveelheid gebruikte middelen. Het is ook belangrijk op te merken dat ontwerppatronen niet op alle situaties van toepassing zijn en het is van cruciaal belang om het probleem in kwestie te beoordelen om de beste aanpak voor dat specifieke scenario te kiezen.
ontwerppatronen zijn onderverdeeld in een paar brede categorieën, maar voornamelijk in Creatiepatronen, structurele patronen en gedragspatronen.
het fabrieksmethode-patroon is een creatief ontwerppatroon.
The Factory Method Design Pattern
Definition
de Factory Method wordt gebruikt in objectgeoriënteerd programmeren als een middel om fabrieksinterfaces te bieden voor het maken van objecten. Deze interfaces definiëren de algemene structuur, maar initialiseren geen objecten. De initialisatie wordt overgelaten aan meer specifieke subklassen.
de bovenliggende klasse / interface herbergt alle standaard en generiek gedrag dat kan worden gedeeld over subklassen van verschillende typen. De subklasse is op zijn beurt verantwoordelijk voor de definitie en instantiatie van het object gebaseerd op de superklasse.
motivatie
de belangrijkste motivatie achter het ontwerppatroon van de fabrieksmethode is het verbeteren van losse koppeling in code door het creëren van een abstracte klasse die zal worden gebruikt om verschillende soorten objecten te maken die enkele gemeenschappelijke kenmerken en functionaliteit delen.
dit resulteert in meer flexibiliteit en hergebruik van code omdat de gedeelde functionaliteit niet zal worden herschreven nadat deze van dezelfde klasse is overgenomen. Dit ontwerppatroon staat ook bekend als een virtuele Constructor.
het fabrieksmethode ontwerppatroon wordt vaak gebruikt in bibliotheken door clients toe te staan om te kiezen welke subklasse of welk type object ze willen maken door middel van een abstracte klasse.
een fabrieksmethode ontvangt informatie over een vereist object, instantieert het en retourneert het object van het opgegeven type. Dit geeft onze applicatie of bibliotheek een enkel punt van interactie met andere programma ‘ s of stukjes code, waardoor onze object creatie functionaliteit wordt ingekapseld.
Factory Method Implementation
ons programma zal een bibliotheek zijn die gebruikt wordt voor het verwerken van vormobjecten in termen van creatie en andere bewerkingen zoals het toevoegen van kleur en het berekenen van de oppervlakte van de vorm.
gebruikers zouden onze bibliotheek moeten kunnen gebruiken om nieuwe objecten te maken. We kunnen beginnen met het creëren van individuele vormen en gebruik te maken van hen zoals is, maar dat zou betekenen dat veel gedeelde logica zal moeten worden herschreven voor elke vorm die we beschikbaar hebben.
de eerste stap om deze herhaling op te lossen zou zijn om een bovenliggende vormklasse te maken met methoden als calculate_area() en calculate_perimeter(), en eigenschappen zoals dimensies.
de specifieke vormobjecten zullen dan overerven van onze basisklasse. Om een vorm te maken, zullen we moeten identificeren wat voor soort vorm nodig is en maak de subklasse voor het.
we beginnen met het maken van een abstracte klasse om een generieke vorm weer te geven:
Dit is de basisklasse voor al onze vormen. Laten we een aantal concrete, meer specifieke vormen maken:
tot nu toe hebben we een abstracte klasse gemaakt en deze uitgebreid naar verschillende vormen die beschikbaar zullen zijn in onze bibliotheek. Om de verschillende vormobjecten te maken, moeten klanten de namen en details van onze vormen kennen en afzonderlijk de creatie uitvoeren.
Dit is waar de fabriek methode in het spel komt.
het fabrieksmethode ontwerppatroon zal ons helpen de beschikbare vormen van de client te abstraheren, dat wil zeggen dat de client niet alle beschikbare vormen hoeft te kennen, maar alleen hoeft te maken wat ze nodig hebben tijdens runtime. Het zal ons ook in staat stellen om de objectcreatie te centraliseren en in te kapselen.
laten we dit bereiken door een ShapeFactory aan te maken die gebruikt zal worden om de specifieke vormklassen te maken op basis van de input van de client:
dit is onze interface voor het maken. We bellen niet de constructeurs van betonklassen, we bellen de fabriek en vragen het om een vorm te maken.
onze ShapeFactory werken door het ontvangen van informatie over een vorm, zoals een naam en de vereiste afmetingen. Onze fabrieksmethode create_shape() zal dan worden gebruikt om kant-en-klare objecten van de gewenste vormen te maken en terug te geven.
de client hoeft niets te weten over de creatie van het object of de details. Met behulp van het fabrieksobject kunnen ze objecten maken met een minimale kennis van hoe ze werken:
het uitvoeren van deze code zal resulteren in:
of, we kunnen een andere vorm bouwen:
wat vermeldenswaard is, is dat behalve dat de client niet veel hoeft te weten over het creatieproces – wanneer we een object willen instantiëren, noemen we niet de constructor van de klasse. We vragen de fabriek om dit voor ons te doen op basis van de informatie die we doorgeven aan de functie create_shape().
voors en tegens
voors
een van de belangrijkste voordelen van het gebruik van het ontwerppatroon van de fabrieksmethode is dat onze code losjes gekoppeld wordt doordat de meeste componenten van onze code niet op de hoogte zijn van andere componenten van dezelfde codebase.
dit resulteert in code die gemakkelijk te begrijpen en te testen is en meer functionaliteit toevoegt aan specifieke componenten zonder het hele programma te beïnvloeden of te breken.
het ontwerppatroon van de fabrieksmethode helpt ook om het beginsel van de individuele verantwoordelijkheid te handhaven waar klassen en objecten die specifieke functionaliteit verwerken, resulteren in betere code.
Cons
het creëren van meer klassen leidt uiteindelijk tot minder leesbaarheid. In combinatie met een abstracte fabriek (factory of factories), zal de code echter al snel uitgebreid worden, onderhoudbaar.
conclusie
concluderend stelt het ontwerppatroon van de fabrieksmethode ons in staat om objecten te maken zonder de exacte klasse te specificeren die nodig is om het specifieke object te maken. Dit stelt ons in staat om onze code te ontkoppelen en verbetert de herbruikbaarheid.
het is belangrijk op te merken dat het, net als elk ander ontwerppatroon, alleen geschikt is voor specifieke situaties en niet voor elk ontwikkelingsscenario. Een beoordeling van de huidige situatie is van cruciaal belang voordat wordt besloten om het ontwerppatroon van de fabrieksmethode toe te passen om de voordelen van het patroon te benutten.