WordPress-widgets: Upptäck objektorienterad programmering
Om du inte har läst det första inlägget i den här serien rekommenderar jag det, eftersom vi börjar börja skriva objektorienterad kod för WordPress genom att använda Widgets API.
Serien kommer att fånga några saker:
- visa dig grundskelettet för en widget och varför den är objektorienterad,
- diskutera vilka saker du bör kunna lägga märke till och varför
- uppdatera Widget Boilerplate direkt på den här webbplatsen först och tryck sedan ut den till GitHub,
- bygga en widget med hjälp av API:t med boilerplate som grund för vårt arbete.
Men innan jag gör det vill jag försäkra mig om att alla som läser detta är fångade på kärnprinciperna för objektorienterad programmering och har allt som behövs för att bygga ut en objektorienterad lösning för WordPress.
För detta ändamål rekommenderar jag följande:
- Två pelare för objektorienterad programmering: Del 1 av 2
- Två pelare för objektorienterad programmering: Del 2 av 2
- Abstrakta klasser, del 1 – Abstraherande beteende
- Abstrakta klasser, del 2 – Abstrakta klasser och gränssnitt
- Den oberoende WordPress-utvecklaren
Om du har läst allt innehåll, bra. Du kommer att vara väl förberedd för det här inlägget och de kommande inläggen. Om inte, kan det finnas några hål i resten av det du ska läsa, men innehållet i inlägget bör vara tillräckligt tydligt.
Vad är affären, exakt?
Så här är det: Förra veckan delade jag lite kod tillsammans med lite information om Widgets API. Jag kommer att återkomma till det lite mer i det här inlägget innan vi kommer in på den mer kodningsintensiva delen av två anledningar:
- Jag vill att alla som läser detta ska vara på samma sida när det gäller att skriva objektorienterad kod (åtminstone i detta sammanhang),
- Jag inser att människor kommer från olika bakgrunder och jag vill se till att vi alla är på samma sida så mycket som möjligt innan jag fortsätter.
Om du har erfarenhet av att skriva objektorienterad kod, särskilt i avancerad kapacitet, kan detta verka enklare för dig; Annars hoppas jag att detta kommer att beväpna dig med allt du behöver för att upptäcka objektorienterade metoder, inte bara angående detta API utan även när du läser andras kod.
Hur man upptäcker objektorienterad programmering
En naturlig första fråga är kanske varför vi behöver kunna upptäcka, läsa eller förstå objektorienterad programmering innan vi faktiskt skriver det?
Ett ord om dålig kod
Det korta svaret på det är detta:
Du behöver inte, men jag är till hjälp. Om du kan läsa objektorienterad programmering kommer du att få ett försprång med att dra fördel av vad den erbjuder som ett paradigm eftersom du kommer att bygga vidare på strategier och arbete som gjorts av andra i andra projekt.
Det betyder inte att vi inte kommer att läsa den dåliga koden, men vi kommer att göra vad vi kan för att identifiera dålig kod, identifiera de problematiska områdena och sedan göra vad vi kan för att undvika att införliva den i vårt arbete.
För nu ska vi dock ta en titt på Widgets API för att se vad vi kan göra för att upptäcka objektorienterad programmering.
Tillbaka till objektorienterad programmering
I det tidigare inlägget beskrev jag två saker som indikerar att API:et är objektorienterat (åtminstone till viss del):
- användningen av sökordet extends ,
- funktioner som vi måste implementera.
Anledningen till att jag vill återkomma till detta ämne är att det identifierar två viktiga saker som är en del av kärnobjektorienterade principer: Arv och funktionsimplementering (som ofta är en del av abstrakta klasser ).
En notering innan vi tittar på ovanstående:
När du tittar på källan till klassen WP_Widget kommer du att märka att det inte finns abstrakta metoder. Men några av de funktioner som vi måste implementera, som jag kommer att nämna senare i det här inlägget, är främsta kandidater för abstrakta metoder. Och jag ska diskutera varför också.
Låt oss dela upp ämnena ovan i två separata avsnitt: Arv och Abstraktioner.
Arv
Jag täckte arv är relativt djup i förra inlägget, så jag ska inte förtydliga poängen här. Jag ska bjuda på några ord, men jag är mycket mer intresserad av att diskutera abstraktion, vilket jag kommer att göra om ett ögonblick.
Innan du går för långt in på det här, vänligen se följande kod:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Men först kan vi inse att alla klasser som implementerar Widgets API måste använda arv enbart på grund av nyckelordet extends .
Det betyder att det finns en funktionalitet som vi kommer att ärva (eller få gratis) och det finns en funktionalitet som vi måste implementera på egen hand.
Från PHP-manualen :
Till exempel, när du utökar en klass, ärver underklassen alla offentliga och skyddade metoder från den överordnade klassen. Om inte en klass åsidosätter dessa metoder kommer de att behålla sin ursprungliga funktionalitet.
När du ärver funktionalitet från en klass kan du dock upptäcka att det är viktigt att strikt anropa förälderns konstruktor (i vår __construct- funktion).
Men detta väcker vad jag tror är en av de viktigaste frågorna med arv i PHP (och hela anledningen till att jag ville inkludera det här avsnittet): Behöver vi anropa den överordnade konstruktorn uttryckligen?
Även enligt manualen:
Överordnade konstruktörer anropas inte implicit om den underordnade klassen definierar en konstruktor. För att köra en överordnad konstruktor krävs ett anrop till parent::__construct() i den underordnade konstruktorn. Om det underordnade inte definierar en konstruktor så kan det ärvas från den överordnade klassen precis som en vanlig klassmetod (om den inte deklarerades som privat).
Men vi kan förenkla detta. Det här är kanske lättare att komma ihåg:
- Om vår klass använder arv men inte definierar en konstruktor, anropas den överordnade konstruktorn.
- Om vår klass använder arv men definierar en konstruktor, måste den överordnade konstruktionen uttryckligen anropas.
Eller kanske ännu enklare:
- Om vår klass inte definierar en konstruktor, kommer koden som standard till föräldrarnas konstruktor.
Vettigt? Kort sagt, om vi definierar våra egenskaper, initialisering och kod i en konstruktor, bör den första raden i vår klasss konstruktor vara ett anrop till den överordnade konstruktorn.
Abstraktion
För att vara helt tydlig innehåller inte källkoden för klassen WP_Widget abstrakta metoder. En del av detta har att göra med hur klassen är byggd, en del av detta har att göra med bakåtkompatibilitet och funktioner i PHP5.
Detta betyder dock inte att vi inte kan identifiera vilka funktioner som kan markeras som abstrakta. Faktum är att jag tror att det är en fråga om vilka klasser som bör göras abstrakta. Men först, låt oss definiera abstrakta funktioner.
Vid ärvning från en abstrakt klass måste alla metoder markerade som abstrakt i förälderns klassdeklaration definieras av barnet; Dessutom måste dessa metoder definieras med samma (eller en mindre begränsad) synlighet.
När du tittar på källan till vår widget:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Jag tycker att det är rättvist att säga att formulärfunktionen kan markeras som abstrakt eftersom den är unik för vår implementering. Ett annat sätt att tänka abstrakta funktioner ur en programmeringssynpunkt är att fråga dig själv: Vilka funktioner kommer att kräva unik funktionalitet?
Och i det här fallet är formulärfunktionen just det eftersom varje widget kommer att vara unikt annorlunda vad gäller vad den renderar. Widgetfunktionen kan också markeras som abstrakt eftersom den matar ut innehållet i widgeten. Detta innehåll är naturligtvis baserat på den funktionalitet vi har implementerat i vår implementering.
Dessutom säger själva källkoden för klassen WP_Widget :
funktion WP_Widget::widget() måste åsidosättas i en underklass.’
Det är just denna typ av funktion som bör markeras som abstrakt. Eftersom PHP ger ett felmeddelande om en funktion är markerad som abstrakt och inte implementerad. Vi behövde inga die function calls eller något liknande.
De andra funktionerna behöver dock inte nödvändigtvis markeras som abstrakta och här är anledningen:
- __construct kommer att anropa förälderns konstruktor, på den mest grundläggande nivån, och detta är nödvändigt för att initiera basklassen. Glöm dock inte; vi kan lägga till våra egenskaper till denna metod som är unika för vår klass.
- update använder funktionalitet i den överordnade klassen för att serialisera information.
Vi har alltså två funktioner kvar som skulle kunna markeras som abstrakta i en mer modern iteration av klassen.
Nästa upp
Vid det här laget borde vi alla vara på samma sida när det gäller objektorienterad kod. Åtminstone så långt vi kan komma igenom en rad blogginlägg.
Med början i nästa inlägg ska vi återgå till att skriva kod.
Det vill säga, vi kommer att återbesöka WordPress Widget Boilerplate och jag kommer att omstrukturera den i dess nuvarande tillstånd för att anta mer moderna PHP-standarder.
Jag ska dela med mig av ändringarna jag gör, motiveringarna till varför, och sedan ska jag också prata om vilken typ av widget vi ska bygga baserat på boilerplate (och vi kan göra det).