Ontwerppatronen het eenvoudige fabriekspatroon

Als je aan een fabriek denkt, wat komt er dan in je op? Voor mij is het een plek waar dingen worden gecreëerd - dat wil zeggen, het is een centrale plek waar dingen worden geproduceerd. Later wordt de levering van de producten gedaan door de fabriek op basis van een bestelling.

Laten we zeggen dat u een auto aanvraagt. Een fabriek maakt er een op basis van de specificaties van de werkorder en levert deze vervolgens af zodra deze compleet is.

Net als hun tegenhangers in de echte wereld, is een softwarefabriek (dat wil zeggen software die het fabrieksontwerppatroon implementeert) een object dat verantwoordelijk is voor het maken en leveren van andere objecten op basis van binnenkomende parameters.

Er zijn drie variaties op het fabriekspatroon:

Eenvoudig fabriekspatroon. Dit maakt interfaces voor het maken van objecten mogelijk zonder de logica voor het maken van objecten aan de client bloot te stellen.
Fabrieksmethodenpatroon. Dit maakt interfaces voor het maken van objecten mogelijk, maar laat subklassen toe om te bepalen welke klasse moet worden geïnstantieerd.
Abstract fabriekspatroon. In tegenstelling tot de bovenstaande twee patronen, is een abstracte fabriek een interface om gerelateerde objecten te maken zonder hun klassen te specificeren / bloot te leggen. We kunnen ook zeggen dat het een object van een andere fabriek biedt die verantwoordelijk is voor het creëren van vereiste objecten.

Het probleem

Laten we aannemen dat je een autoklasse hebt die alle eigenschappen en methoden bevat die relevant zijn voor een auto. In zijn meest eenvoudige vorm zou je het op deze manier creëren:

$ auto = nieuwe auto ();

Meteen na verloop van tijd moet er een verandering zijn in de manier waarop het Car-object wordt gemaakt. We moeten klassevoorwerpen maken die gebaseerd zijn op het Cart-type in plaats van alleen op Car. U moet dus wijzigingen aanbrengen op alle plaatsen waar u een object van deze autoklasse hebt gemaakt.

Maar naarmate de tijd verstrijkt, zullen er onvermijdelijk veranderingen nodig zijn in de manier waarop het Car-object wordt gemaakt. We moeten bijvoorbeeld klassen maken op basis van een auto type in plaats van alleen auto. Als zodanig

In plaats van dat te doen, zou het een betere beslissing zijn om een klasse te creëren die het Factory-patroon implementeert.

De oplossing

In het vorige gedeelte herkenden we dat we een object van het type Car maakten met behulp van de nieuwe trefwoord. En later wordt besloten om een object van de autoklasse te maken, maar op basis van het autotype zoals Sedan, SUV, enz.

Ofwel we moeten de autocoderingscode van het type Auto overal plaatsen wanneer dat nodig is, of Factory implementeren om het op een effectieve manier te behandelen. Raadpleeg het onderstaande codeblok waarin de implementatie van het eenvoudige fabriekspatroon wordt weergegeven.

In de bovenstaande klasse kunt u zien dat we één statische methode beschikbaar hebben die verantwoordelijk is voor het maken van het object op basis van het type dat u doorgeeft. Nu hebben we concrete klassen van verschillende soorten auto's nodig, zoals wat we hieronder hebben opgesomd:

Op dit moment hebben we onze fabrieks- en betonklassen klaar voor gebruik, dus laten we het oefenen voor het maken van objecten van het autotype.

// Nieuwe sedan maken $ sedan = carFactory :: build ('sedan'); // Nieuwe SUV maken $ suv = carFactory :: build ('suv');

Toevoeging van nieuwe klasse

De toevoeging van een nieuwe klasse is eenvoudig: maak een concrete klas en je bent klaar om te beginnen. Bijvoorbeeld:

Conclusie

Als het gaat om het patroon van de fabriek, overweeg dan het gebruik van nieuwe zoekwoord om een nieuw object als schadelijk te maken. De fabriek stelt ons in staat om een gecentraliseerde locatie te hebben en al onze objecten worden gemaakt.

Code