Share
Voor degenen die een uitgebreide achtergrond in software engineering hebben, moeten ontwerppatronen vertrouwd terrein zijn; Er is echter een hele groep ontwikkelaars - vooral in de webontwikkelingsgemeenschap - die niet noodzakelijk vertrouwd zijn met ontwerppatronen (ook al hebben ze deze waarschijnlijk gebruikt!).
In deze serie gaan we kijken naar ontwerppatronen, met name in de context van WordPress, hoe ze nuttig zijn en enkele praktische voorbeelden die we kunnen gebruiken in onze thema's en plug-ins..
Het uiteindelijke doel van de serie is om een gedegen definitie te geven van wat ontwerppatronen zijn, waarom ze nuttig zijn, hoe ze worden gebruikt in de kern van WordPress en vervolgens twee populaire voorbeelden te bekijken die we gemakkelijk in ons eigen werk kunnen gebruiken..
Voordat we enkele praktische voorbeelden bekijken, kunnen we ontwerppatronen definiëren en een voorbeeld bekijken van hoe ze worden gebruikt in de kern van WordPress..
Voor diegenen van jullie die nog nooit van gehoord hebben of die nooit ontwerppatronen hebben gebruikt, is het belangrijk om te begrijpen wat ze zijn voordat we ze daadwerkelijk gaan gebruiken in ons werk.
Wikipedia biedt de volgende definitie:
Een ontwerppatroon in architectuur en informatica is een formele manier om een oplossing voor een ontwerpprobleem in een bepaald vakgebied te documenteren. Een georganiseerde verzameling ontwerppatronen die betrekking hebben op een bepaald veld, wordt een patroontaal genoemd.
Misschien zou een meer vereenvoudigde definitie zijn:
Een patroon is een ontwerp dat kan worden toegepast op een probleem in een specifieke situatie.
Als dat zo is nog steeds niet duidelijk, denk er zo over na:
De algemene implementatie en architectuur zien er precies hetzelfde uit; de details van de implementatie variëren natuurlijk van project tot project, maar dat is gewoon de aard van het beest.
In de komende secties en aankomende artikelen zullen we dit in meer detail bekijken.
Als je elk type WordPress-ontwikkeling met betrekking tot het haaksysteem hebt gedaan - dat wil zeggen, je hebt hele plug-ins, thema's of zelfs een eenvoudige functie geschreven en hebt geprofiteerd van de add_action of add_filter functies - dan heb je ontwerppatronen gebruikt.
WordPress gebruikt een zogenaamd gebeurtenisgestuurd ontwerppatroon. Er zijn verschillende variaties van door gebeurtenissen aangestuurde ontwerppatronen die we een moment zullen herzien, maar de kern van de patronen is hetzelfde:
Over het algemeen zendt de uitgever een bericht uit dat er is iets gebeurd voor alle objecten waarop is geabonneerd op die bepaalde uitgever.
Een andere manier om hiernaar te kijken is dat, in software, wanneer er iets gebeurt, we zeggen dat er een evenement wordt georganiseerd. Misschien is de meest voorkomende plaats die we zien in webontwikkeling in JavaScript met dingen zoals de muis waarop wordt geklikt, een toets op het toetsenbord die wordt ingedrukt of iets dergelijks.
Vervolgens schrijven we functies die deze functies afhandelen, en deze functies worden passend aangeduid als gebeurtenishandlers omdat ze verantwoordelijk zijn voor het afhandelen van de case wanneer een gebeurtenis plaatsvindt.
Niet erg ingewikkeld, toch? Eerlijk gezegd vind ik de terminologie soms verwarrender dan de daadwerkelijke implementatie.
Hoe dan ook, in de context van WordPress - of welke webapplicatie dan ook - zijn evenementen niet beperkt tot toetsaanslagen of muisklikken. In plaats daarvan kan het gebeuren tijdens verschillende delen van de levenscyclus van de pagina, wanneer gegevens naar de database worden geschreven, wanneer gegevens naar de database worden gelezen, enzovoort.
Uiteindelijk kun je het patroon desgewenst implementeren, zodat je haken kunt bieden waarin ontwikkelaars functies kunnen registreren om te schieten zodra het evenement zich voordoet.
Dit brengt ons volledig terug naar de architectuur van WordPress: haken worden overal in de code geplaatst, zodat we een functie kunnen registreren om altijd af te vuren er gebeurt iets (dat wil zeggen, wanneer een gebeurtenis plaatsvindt).
Er zijn een aantal door gebeurtenissen aangestuurde ontwerppatronen, waarvan er één bekend staat als het waarnemerspatroon. Dit specifieke patroon is ook bekend als het Publisher-Subscriber Pattern of, beknopter, Pub-Sub.
In de eenvoudigste implementatie van dit patroon is er een enkele uitgever die verantwoordelijk is voor het uitzenden van berichten naar een of meer abonnees. De abonnees zijn verantwoordelijk voor de registratie bij de uitgever en vervolgens is de uitgever verantwoordelijk voor het verzenden van een bericht of het ondernemen van actie tegen alle abonnees.
Een diagram op hoog niveau ziet er ongeveer zo uit:
Vanuit een codeperspectief heeft de uitgever drie dingen nodig:
Evenzo moet de abonnee twee dingen kunnen doen:
Er zijn een aantal manieren waarop dit kan worden geïmplementeerd, maar voor alle intenties en doeleinden en om het voorbeeld relatief eenvoudig te houden, laten we zeggen dat de abonnees zichzelf registreren bij de uitgever met de waarnemer registreren methode en de functie accepteert een verwijzing naar de abonnee en elke abonnee heeft een bijwerken methode die de Publisher oproept bij het uitzenden van het bericht.
class MyPublisher / ** De lijst met abonnees die zijn geregistreerd bij deze uitgever * / private $ subscribers; / ** * Verantwoordelijk voor het initialiseren van de klas en het opstellen van de lijst met abonnees. * / public function __construct () $ this-> subscribers = array (); // end constructor / ** * Voegt het binnenkomende onderwerp toe aan de lijst met geregistreerde abonnees * * @param array $ subject Het onderwerp dat moet worden toegevoegd aan de lijst met subscribers * / public function register ($ subject) array_push ($ this- > subscribers, $ subject); // end register_subscriber / ** * Waarschuwt alle abonnees dat er iets is gebeurd door hun 'update' * methode aan te roepen. * / public function notify_subscribers () for ($ i = 0; $ l < count( $this->abonnees); $ i ++) $ current_subscriber = $ this-> subscribers [$ i]; $ Current_subscriber-> update (); // end for // end notify_subscribers // end class
De bovenstaande code is ongeveer net zo eenvoudig als we het kunnen maken:
Voor degenen die meer ervaring hebben met object-georiënteerde technieken, zult u waarschijnlijk de noodzaak zien om een klasse-interface voor de Publisher te maken, maar dat is buiten het bereik van deze specifieke tutorial.
Denk eraan, het doel is om eenvoudigweg een voorbeeld te geven van hoe een eenvoudige waarnemer eruit kan zien.
Het creëren van een uitgever is eigenlijk maar de helft van de implementatie. Denk eraan, we moeten iets hebben dat echt, weet je, onderschrijft naar de uitgever om actie te ondernemen wanneer er iets gebeurt.
Dit is waar de toepasselijke naam Abonnee in het spel komt.
class MySubscriber / ** De uitgever waarop deze klasse * / private $ publisher registreert; / ** * Verantwoordelijk voor het initialiseren van de klasse en het instellen van een verwijzing naar de uitgever * / public function __construct () $ this-> publisher = new MyPublisher (); $ this-> publisher-> registreer ($ this); // end constructor / ** * Dit is de methode die de Publisher oproept wanneer deze zijn bericht uitzendt. * / update openbare functie () / ** Implementatie is puur gebaseerd op wat u wilt. * / // eindupdate // eindklasse
Kortom, dit is het. Merk hierboven op dat deze implementatie van de bijwerken functie is niet echt gedefinieerd. Dat komt omdat het ons de mogelijkheid biedt om uniek gedrag aan te bieden aan dit specifieke exemplaar.
Maar onthoud, er is veel code in de WordPress-kern die niet objectgeoriënteerd is. In plaats daarvan is het procedureel. Als zodanig varieert de implementatie van een patroon als dit enigszins.
Een analogie in WordPress zou bijvoorbeeld ongeveer zo kunnen zijn:
Accentsconagua
function my_custom_subscriber ($ content) $ content = 'Dit is mijn aangepaste inhoud.' . $ Inhoud; return $ inhoud; // einde my_custom_subscriber add_action ('the_content', 'my_custom_subscriber'); Merk op dat de syntaxis een beetje anders is, maar we doen in essentie iets heel vergelijkbaars:
my_custom_subscriber - en het is geregistreerd bij de de inhoud evenementde inhoud functie vuurt, onze aangepaste functie zal vuren.Niets is te ingewikkeld, hoop ik.
Een van de doelen in deze serie is niet alleen om een paar voorbeelden te geven van ontwerppatronen en hoe deze te implementeren, maar ze zijn al aanwezig in bestaande systemen.
Naast het door gebeurtenissen aangestuurde patroon dat we hierboven hebben besproken, gaan we ook een blik werpen op twee patronen die gebruikelijk, praktisch en zeer nuttig zijn in ons dagelijks werk.
Concreet gaan we de volgende patronen bekijken:
Vanzelfsprekend gaat praten over software alleen zo ver zonder te praten over diagrammen en / of code, dus we zullen een blik werpen op beide in de komende reeks artikelen.
Zoals je kunt zien, is het concept van ontwerppatronen niets erg ingewikkelds en valt er veel te winnen door ze in ons werk te gebruiken. Misschien is de grootste uitdaging waar ontwikkelaars voor staan ontwerppatronen te gebruiken om ontwerppatronen te gebruiken.
In plaats daarvan is het belangrijk om te erkennen dat er bepaalde situaties zijn waarin ontwerppatronen van toepassing zijn. Dat wil zeggen dat er bepaalde problemen zijn waarvoor ontwerppatronen de perfecte oplossing zijn. Ervaring is misschien wel de beste leraar om te weten wanneer een ontwerppatroon moet worden gebruikt en wanneer niet om het te gebruiken.
In de volgende artikelen zullen we hopelijk genoeg terrein kunnen bespreken om twee solide voorbeelden van ontwerppatronen te bieden, wanneer ze van toepassing zijn, hoe ze te gebruiken en hoe ze ons kunnen helpen bij ons toekomstige werk.
