Share
In deze serie kijken we naar ontwerppatronen en hoe we ze kunnen gebruiken in ons voordeel bij het bouwen van producten bovenop WordPress.
Het leuke aan ontwerppatronen is dat ze niet expliciet zijn beperkt tot thema's of plug-ins - ze zijn handig in verschillende scenario's. Het is gewoon een kwestie van in staat zijn om te identificeren welke patronen van toepassing zijn op bepaalde scenario's.
In het laatste bericht hebben we het Singleton-patroon beoordeeld. In dit artikel gaan we het Simple Factory Pattern bekijken, wat vooral handig is wanneer je een aantal verschillende klassen hebt die elk een uniek doel hebben en een specifiek probleem oplossen.
In dit bericht bekijken we nog een ander patroon - het Simple Factory Pattern - dat handig is wanneer je een aantal klassen hebt die elk een uniek doel hebben en die geselecteerd kunnen worden op basis van bepaalde criteria.
Het Simple Factory Pattern is eigenlijk afgeleid van een patroon dat bekend staat als het Factory Method Pattern, een iets gecompliceerdere versie van het patroon dat we gaan beoordelen.
Volgens Wikipedia is het patroon van de fabrieksmethode als volgt gedefinieerd:
Het patroon van de fabrieksmethode is een objectgeoriënteerd creatieontwerppatroon om het concept van fabrieken te implementeren en gaat over het probleem van het maken van objecten (producten) zonder de exacte klasse van objecten te specificeren die worden gemaakt
Klinkt een beetje ingewikkeld, niet??
De waarheid is dat het eigenlijk een heel krachtig ontwerppatroon is, maar het zou een veel langer artikel zijn om het te bespreken, en het is een beetje buiten bereik voor het doel van deze serie.
Dus, zoals gezegd, gaan we een versie bekijken van het patroon dat een beetje is gepaard en moeten meer algemeen van toepassing zijn op minder gecompliceerde projecten.
Laten we, voordat we dat doen, op een definitie komen van het Simple Factory Pattern:
Het Simple Factory-patroon retourneert een specifieke set gegevens of een specifieke klasse op basis van de invoer.
Ah het risico om een woordspeling te maken, eenvoudig, toch?
De waarheid is dat veel software-ingenieurs de Simple Factory meer als een idioom dan een volledig patroon beschouwen; anderen beschouwen dit als een patroon.
Voor wat het waard is, zie ik het als een heel eenvoudig patroon. Het heeft een specifieke use-case die gemakkelijk kan worden geïdentificeerd wanneer deze tijdens de ontwikkeling moet worden gebruikt, en die we verderop in dit artikel zullen bespreken.
Hoe dan ook, ik breng dit naar boven, zodat als je ziet dat dit wordt gebruikt als een idioom (of een patroon) dat in verschillende artikelen op internet wordt gebruikt, of zelfs in een gesprek, je weet dat de betreffende ontwikkelaars dezelfde programmeerstrategie bedoelen - gewoon op een andere manier.
Net als ontwerppatronen in niet-WordPress-specifieke projecten, zoals grotere toepassingen, bieden de ontwerppatronen een beproefde manier om een veelvoorkomend probleem op te lossen.
Het helpt onze code een beetje te abstraheren, ons project gemakkelijk te onderhouden, gemakkelijk leesbaar te houden en kan ons zelfs helpen onze code lean te houden. Dit kan ertoe leiden dat we er eigenlijk meer hebben bestanden in ons project, maar elk bestand zou minder coderegels moeten bevatten.
Dit betekent dat elk bestand een specifiek doel moet hebben dat duidelijk moet zijn, niet alleen voor ons, maar ook voor toekomstige ontwikkelaars.
Voordat we ons verdiepen in de diagrammen, praten over klassen en de strategieën die nodig zijn om het eigenlijke patroon te implementeren, wil ik vermelden dat we hier een eenvoudige benadering van gaan gebruiken..
Het punt is, het lezerspubliek van deze blog omvat een breed scala aan ervaringen - we hebben enkele mensen die leren code te schrijven; anderen die doorgewinterde veteranen zijn.
Om een beroep te doen op de meerderheid van de lezers, moeten we een evenwicht vinden. Dus voor degenen onder u die al jarenlang betrokken zijn bij software engineering, lijkt dit misschien te simplistisch; haal het echter niet weg - misschien haal je iets nieuws op.
Voor degenen onder u die beginners of zelfs tussentijdse programmeurs zijn, let goed op wat we bespreken, want het kan voordelen bieden in toekomstige (of zelfs bestaande) werkzaamheden.
Dus stel je dit scenario voor: je werkt aan een functie die een reeks invoer bevat - meestal een soort van unieke string of integer - en je hebt dit lang if / else verklaring of misschien heb je deze zo groot switch / case verklaring die blijft groeien naarmate uw project groeit.
Het probleem is dat de conditionals lastig te beheren zijn. In feite kunnen case-conditionals, of de case-blocks, uiteindelijk zo veel werk doen als een bepaalde functie zou moeten doen.
Dit is waar de Simple Factory om de hoek komt kijken. Wat we kunnen doen is de details die plaatsvinden in elk van de conditionals in hun eigen klasse abstraheren waardoor het veel gemakkelijker wordt om de code veel leaner te houden en te houden.
En dat is het eenvoudige fabriekspatroon.
Dus hier zijn de belangrijkste kenmerken van het Simple Factory Pattern:
Niets te gecompliceerd, toch? Eerlijk gezegd denk ik dat het diagram iets gecompliceerder is dan de principes die spelen. Het biedt echt veel flexibiliteit vooral wanneer u op zoek bent naar een ander gebruikerstype zoals een editor of iets dergelijks.
Notitie: Dit is niet te verwarren met de ingebouwde gebruikerstypes van WordPress. Dit is gewoon een voorbeeld om te laten zien hoe het patroon eruit zou zien.
Nu we het diagram voor het patroon hebben bekeken, laten we de broncode in actie bekijken. Hieronder zullen we de broncode voor elke klas bekijken en daarna zal ik een download beschikbaar maken voor een volledig gedocumenteerde demo na de discussie.
Laten we eerst de plugin-klasse bekijken. Vergeet niet dat dit niets meer is dan een prototype van hoe het patroon eruit ziet. Het is niet hetzelfde als een volledig ontwikkelde WordPress-plug-in.
fabriek = nieuw Simple_Factory (); openbare functie get_user ($ permissie) return $ this-> factory-> get_user ($ permission); ?>
Merk op dat de plug-in relatief eenvoudig is:
Accentsconagua
$ fabriek eigenschap aan een instantie van de Simple_Factory get_user die een gebruiker retourneert op basis van een typeWe zullen zien hoe dit in het spel komt nadat we alle andere klassen hebben bekeken.
De Gebruiker is een abstracte basisklasse die een basisconstructor en een abstracte functie biedt die door alle andere subklassen moet worden geïmplementeerd.
rol = $ rol; abstracte openbare functie get_role (); ?>
Houd er rekening mee dat deze klasse is bedoeld om te worden onderverdeeld in verschillende andere klassen, die we elk moment in detail zullen bekijken.
De volgende vier klassen zijn allemaal afzonderlijke bestanden die elk de subklasse Gebruiker basisklasse. Ik heb ervoor gekozen om ze hier allemaal bij elkaar te voegen, omdat er zo weinig afwijking is van de daadwerkelijke implementatie dat het eenvoudig genoeg moet zijn om te volgen.
rol = "Beheerder"; openbare functie get_role () return $ this-> rol; ?>
role = "Reader"; openbare functie get_role () return $ this-> rol; ?>
rol = "Vrijwilliger"; openbare functie get_role () return $ this-> rol; ?>
Zoals gebruikelijk, laat me vragen in de comments; lees anders de code door en lees dan verder De eenvoudige fabriek wat de volgende sectie is - het verbindt dit alles samen.
Vergeet ook niet dat al deze code aan het einde van het artikel wordt gedeeld, samen met code-opmerkingen die precies beschrijven wat er gebeurt.
De Simple_Factory klasse is echt de crux van het hele patroon. Hier worden alle beslissingen genomen en de juiste objecten geretourneerd.
Merk op dat de Simple_Factory omvat de basisgebruikersklasse en de bijbehorende subklassen en werkt vervolgens om het juiste type gebruiker terug te geven op basis van de inkomende reeks machtigingen.
Hoewel het op dit punt in dit artikel een beetje duidelijk zou moeten zijn, biedt het Simple Factory Pattern een aantal voordelen, vooral als je gewend bent om met grote conditionals te werken.
Over het algemeen is dit een van mijn favoriete patronen, simpelweg vanwege de kwestie van de code-indeling en specialisatie die het op tafel kan brengen.
Ten slotte kun je via deze link de volledige broncode - compleet met documentatie en installatie-instructies - downloaden op GitHub.
Op dit punt hebben we drie patronen bekeken:
Deze serie kan een tijdje duren; Ik denk echter dat we op zijn minst voldoende aandacht hebben besteed om velen van ons te laten beginnen met het implementeren van patronen in ons werk.
Dus in het laatste artikel van de serie zullen we samenvatten wat we hebben geleerd en ik zal ook enkele andere patronen aanbevelen, hun doel en enkele andere punten van onderzoek die je moeten blijven helpen bij het blijven leren over ontwerppatronen. en hun voordelen niet alleen in de ontwikkeling van WordPress, maar ook in de algemene ontwikkeling van software.
