Kui te pole selle seeria esimest postitust lugenud, soovitan seda, sest me hakkame vidinate API abil WordPressi jaoks objektorienteeritud koodi kirjutama .
Seerias on jäädvustatud mõned asjad:
- näidata teile vidina põhilist luustikku ja seda, miks see on objektorienteeritud,
- arutlege, mida peaksite suutma tähele panna ja miks
- värskendage esmalt Widget Boilerplate’i otse sellel saidil ja seejärel lükake see GitHubisse,
- looge vidin, kasutades API-d ja katlaplaati meie töö aluseks.
Kuid enne seda tahan veenduda, et kõik, kes seda loevad, tunnevad objektorienteeritud programmeerimise põhiprintsiipe ja neil on kõik vajalik WordPressi objektorienteeritud lahenduse loomiseks.
Selleks soovitan järgmist:
- Objektorienteeritud programmeerimise kaks sammast: 1. osa 2-st
- Objektorienteeritud programmeerimise kaks sammast: 2. osa 2-st
- Abstraktsed klassid, 1. osa – Abstraktne käitumine
- Abstraktsed klassid, 2. osa – Abstraktsed klassid ja liidesed
- Sõltumatu WordPressi arendaja
Kui olete kogu selle sisu lugenud, on suurepärane. Olete selleks postituseks ja eelseisvateks postitusteks hästi ette valmistatud. Kui ei, siis võib ülejäänud lugemises olla auke, kuid postituse sisu peaks olema piisavalt selge.
Mis leping täpselt on?
Asi on järgmine: eelmisel nädalal jagasin natuke koodi ja teavet vidinate API kohta. Ma käsitlen seda selles postituses veidi rohkem, enne kui jõuame kodeerimise intensiivsema osa juurde kahel põhjusel:
- Ma tahan, et kõik, kes seda loevad, oleksid objektorienteeritud koodi kirjutamise osas samal lehel (vähemalt selles kontekstis),
- Mõistan, et inimesed on erineva taustaga, ja tahan enne jätkamist veenduda, et oleme kõik võimalikult ühel lehel.
Kui teil on kogemusi objektorienteeritud koodi kirjutamisel, eriti edasijõudnutele, võib see tunduda teile lihtsam; muidu loodan, et see varustab teid kõige vajalikuga objektorienteeritud tavade tuvastamiseks mitte ainult selle API kohta, vaid ka teiste koodi lugemisel.
Kuidas tuvastada objektorienteeritud programmeerimist
Võib-olla on loomulik esimene küsimus, miks me peame suutma objektorienteeritud programmeerimist tuvastada, lugeda või mõista enne selle kirjutamist?
Sõna halva koodi kohta
Lühike vastus sellele on järgmine:
Sa ei pea seda tegema, aga mulle on sellest abi. Kui oskate objektorienteeritud programmeerimist lugeda, saate selle paradigmana pakutavate eeliste ärakasutamiseks edumaa, kuna kavatsete tugineda teiste projektide strateegiatele ja tööle.
See ei tähenda, et me ei loeks halba koodi, kuid teeme kõik endast oleneva, et tuvastada halb kood, tuvastada probleemsed piirkonnad ja seejärel teha kõik, et vältida selle kaasamist oma töösse.
Praegu aga vaatame vidinate API -t, et näha, mida saame objektorienteeritud programmeerimise tuvastamiseks teha.
Tagasi objektorienteeritud programmeerimise juurde
Eelmises postituses tõin välja kaks asja, mis näitavad, et API on objektorienteeritud (vähemalt teatud määral):
- laiendab märksõna kasutamine ,
- funktsioone, mida peame rakendama.
Põhjus, miks ma tahan seda teemat uuesti läbi vaadata, on see, et see tuvastab kaks põhiasja, mis on osa objektorienteeritud põhiprintsiipidest: pärimine ja funktsioonide rakendamine (mis on sageli osa abstraktsetest klassidest ).
Märkus enne ülaltoodu vaatamist:
Kui vaatate klassi WP_Widget allikat, märkate, et seal pole abstraktseid meetodeid. Kuid mõned funktsioonid, mida me peame rakendama ja mida ma selles postituses hiljem mainin, on abstraktsete meetodite peamised kandidaadid. Ja ma arutan ka, miks.
Eraldame ülaltoodud teemad kaheks eraldi jaotiseks: Pärimine ja Abstraktsioonid.
Pärand
Eelmises postituses käsitlesin pärimise suhtelist sügavust, nii et ma ei hakka seda siin käsitlema. Ma ütlen paar sõna, kuid ma olen palju rohkem huvitatud abstraktsiooni üle arutlemisest, mida ma teen hetke pärast.
Enne kui lähete sellesse liiga kaugele, vaadake palun järgmist koodi:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Kuid kõigepealt saame aru, et iga klass, mis rakendab vidinate API-d, peab kasutama pärimist lihtsalt laiendatud märksõna tõttu.
See tähendab, et teatud funktsionaalsuse tase me pärime (või saame tasuta) ja funktsionaalsuse taseme, mille peame ise rakendama.
PHP juhendist :
Näiteks klassi laiendamisel pärib alamklass ülemklassilt kõik avalikud ja kaitstud meetodid. Kui klass neid meetodeid ei alista, säilitavad need oma algsed funktsioonid.
Kui pärandate funktsionaalsuse klassist, võite avastada, et on oluline kutsuda rangelt vanemkonstruktor (meie funktsioonis __construct ).
Kuid see tõstatab minu arvates PHP pärimisega seotud ühe kõige olulisema probleemi (ja kogu põhjuse, miks ma tahtsin selle jaotise kaasata): kas peame emakonstruktorit selgesõnaliselt kutsuma?
Samuti vastavalt juhendile:
Vanemkonstruktoreid ei kutsuta kaudselt välja, kui alamklass määratleb konstruktori. Ülemkonstruktori käivitamiseks on vaja alamkonstruktoris kõnet vanematele::__construct(). Kui laps konstruktorit ei defineeri, võib see pärida põhiklassist nagu tavaline klassimeetod (kui seda ei deklareeritud privaatseks).
Kuid me saame seda lihtsustada. Võib-olla on seda lihtsam meeles pidada:
- Kui meie klass kasutab pärimist, kuid ei defineeri konstruktorit, kutsutakse välja emakonstruktor.
- Kui meie klass kasutab pärimist, kuid määratleb konstruktori, tuleb emakonstruktsiooni selgesõnaliselt kutsuda.
Või ehk veelgi lihtsamalt:
- Kui meie klass konstruktorit ei määratle, on kood vaikimisi vanemate konstruktor.
On loogiline? Lühidalt, kui me määratleme konstruktoris oma atribuudid, lähtestamise ja koodi, peaks meie klassi konstruktori esimene rida olema kõne emakonstruktorile.
Abstraktsioon
Et olla täiesti selge, ei sisalda klassi WP_Widget lähtekood abstraktseid meetodeid. Osa sellest on seotud klassi ülesehitusega, osa on seotud tagasiühilduvusega ja PHP5 funktsioonidega.
See aga ei tähenda, et me ei saaks tuvastada, milliseid funktsioone võiks abstraktseks märkida. Tegelikult arvan, et see annab põhjust, millised klassid tuleks muuta abstraktseks. Kuid kõigepealt defineerime abstraktsed funktsioonid.
Abstraktsest klassist pärimisel peavad kõik vanema klassideklaratsioonis abstraktseks märgitud meetodid olema lapse poolt defineeritud; lisaks peavad need meetodid olema määratletud sama (või vähem piiratud) nähtavusega.
Kui vaadata meie vidina allikat:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Arvan, et on õiglane öelda, et vormi funktsiooni võib märkida abstraktseks, kuna see on meie rakendusele ainulaadne. Teine viis abstraktsetest funktsioonidest programmeerimise seisukohast mõelda on endalt küsida: millised funktsioonid nõuavad ainulaadset funktsionaalsust?
Ja antud juhul on vormifunktsioon just see, kuna iga vidin on selle renderdamise osas unikaalselt erinev. Vidina funktsiooni võiks märkida ka abstraktseks, kuna see väljastab vidina sisu. See sisu põhineb loomulikult funktsioonidel, mille oleme oma juurutamisel rakendanud.
Lisaks ütleb klassi WP_Widget lähtekood :
funktsioon WP_Widget::widget() tuleb alamklassis üle kanda.’
Just seda tüüpi funktsioon tuleks märkida abstraktseks. Kuna PHP annab vea, kui funktsioon on märgitud abstraktseks ja seda ei rakendata. Me ei vajanud ühtegi funktsioonikutset ega midagi sellist.
Teisi funktsioone ei pea aga tingimata abstraktseks märkima ja siin on põhjus:
- __construct kutsub kõige elementaarsemal tasemel välja vanemakonstruktori ja see on vajalik baasklassi lähtestamiseks. Ärge unustage siiski; saame sellele meetodile lisada oma omadused, mis on meie klassile ainulaadsed.
- värskendus kasutab teabe serialiseerimiseks emaklassi funktsioone.
Seega jääb meile kaks funktsiooni, mida võiks klassi kaasaegsemas iteratsioonis abstraktseks märkida.
Järgmisena
Siinkohal peaksime kõik objektorienteeritud koodi osas olema samal lehel. Vähemalt niipalju, kui me blogipostituste seeriat läbi saame.
Alates järgmisest postitusest läheme tagasi koodi kirjutamise juurde.
See tähendab, et vaatame uuesti WordPressi vidina katlaplaati ja muudan selle praeguses seisukorras, et võtta kasutusele kaasaegsemad PHP-standardid.
Jagan tehtud muudatusi, põhjendusi, miks ja seejärel räägin ka sellest, millist tüüpi vidinat me katlaplaadi põhjal ehitame (ja me saame seda teha).