Jos et ole lukenut tämän sarjan ensimmäistä viestiä, suosittelen sitä, koska alamme kirjoittaa oliokoodia WordPressille Widgets API:n avulla.
Sarja aikoo taltioida muutamia asioita:
- näyttää sinulle widgetin perusrungon ja miksi se on oliosuuntautunut,
- keskustella siitä, mitä asioita sinun pitäisi pystyä huomaamaan ja miksi
- päivitä Widget Boilerplate ensin suoraan tälle sivustolle ja siirrä se sitten GitHubiin,
- rakentaa widget API:n avulla, jonka pohjana on työmme.
Mutta ennen kuin teen sen, haluan varmistaa, että jokainen tätä lukeva on perehtynyt olio-ohjelmoinnin perusperiaatteisiin ja että heillä on kaikki tarvittava olio-ratkaisun rakentamiseen WordPressille.
Tätä varten suosittelen seuraavaa:
- Kaksi olio-ohjelmoinnin pilaria: Osa 1/2
- Olio-ohjelmoinnin kaksi pilaria: Osa 2/2
- Abstract Classes, Osa 1 – Abstraktiokäyttäytyminen
- Abstraktit luokat, osa 2 – Abstraktit luokat ja käyttöliittymät
- Itsenäinen WordPress-kehittäjä
Jos olet lukenut kaiken sisällön, hienoa. Olet valmistautunut hyvin tähän viestiin ja tuleviin viesteihin. Jos ei, muussa lukemassasi saattaa olla reikiä, mutta viestin ydin tulee olla riittävän selkeä.
Mikä on sopimus, tarkalleen?
Asia on tässä: viime viikolla jaoin hieman koodia ja tietoja Widgets API :sta. Aion palata asiaan hieman enemmän tässä viestissä ennen kuin siirrymme koodaamista vaativampaan osaan kahdesta syystä:
- Haluan kaikkien tätä lukevien olevan samalla sivulla, kun se liittyy oliokoodin kirjoittamiseen (ainakin tässä yhteydessä),
- Ymmärrän, että ihmiset tulevat eri taustoista, ja haluan varmistaa, että olemme kaikki mahdollisimman pitkälle samalla sivulla ennen kuin jatkat.
Jos sinulla on kokemusta oliokoodin kirjoittamisesta, etenkin edistyneessä kapasiteetissa, tämä saattaa tuntua yksinkertaiselta. Muuten toivon, että tämä varustaa sinut kaikella, mitä tarvitset oliosuuntautuneiden käytäntöjen havaitsemiseksi ei vain tämän API:n suhteen, vaan myös muiden koodia lukiessa.
Kuinka havaita olio-ohjelmointi
Ehkä luonnollinen ensimmäinen kysymys on, miksi meidän täytyy pystyä havaitsemaan, lukemaan tai ymmärtämään olio-ohjelmointia ennen sen kirjoittamista?
Sana huonosta koodista
Lyhyt vastaus siihen on tämä:
Sinun ei tarvitse, mutta se on hyödyllinen minulle. Jos osaat lukea olio-ohjelmointia, sinulla on etumatka sen tarjoaman paradigman hyödyntämisessä, koska aiot rakentaa muiden muissa projekteissa tekemiä strategioita ja työtä.
Tämä ei tarkoita, ettemme lukisi huonoa koodia, mutta teemme kaikkemme tunnistaaksemme huonon koodin, tunnistaaksemme ongelmalliset alueet ja teemme sitten kaikkemme välttääksemme sen sisällyttämisen työhön.
Katsotaan nyt kuitenkin Widgets API :ta nähdäksemme, mitä voimme tehdä olio-ohjelmoinnin havaitsemiseksi.
Takaisin olio-ohjelmointiin
Edellisessä viestissä hahmottelin kaksi asiaa, jotka osoittavat, että API on oliosuuntautunut (ainakin jossain määrin):
- Extens – avainsanan käyttö ,
- toimintoja, jotka meidän on toteutettava.
Syy, miksi haluan palata tähän aiheeseen, on se, että se tunnistaa kaksi keskeistä asiaa, jotka ovat osa ydinolio-periaatteita: Periytys ja funktioiden toteutus (joka on usein osa abstrakteja luokkia ).
Huomautus ennen kuin tarkastelemme yllä olevaa:
Kun tarkastelet luokan WP_Widget lähdettä, huomaat, että abstrakteja menetelmiä ei ole. Mutta jotkin toiminnot, jotka meidän on toteutettava ja jotka mainitsen myöhemmin tässä viestissä, ovat ensisijaisia ehdokkaita abstrakteille menetelmille. Ja keskustelen myös miksi.
Erotetaan yllä olevat aiheet kahteen erilliseen osaan: Perinnöllisyys ja Abstraktiot.
Perintö
Käsittelin perinnön suhteellista syvyyttä edellisessä viestissä, joten en käsittele asiaa tässä. Esitän muutaman sanan, mutta olen paljon kiinnostuneempi abstraktista keskustelusta, jonka teen hetken kuluttua.
Ennen kuin menet tähän liian pitkälle, katso kuitenkin seuraava koodi:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Mutta ensinnäkin voimme huomata, että minkä tahansa luokan, joka toteuttaa Widgets API:n, on käytettävä periytymistä yksinkertaisesti laajennetun avainsanan takia.
Tämä tarkoittaa, että on olemassa tietyn tason toimintoja, jotka aiomme periä (tai saada ilmaiseksi), ja on olemassa taso toimintoja, jotka meidän on otettava käyttöön itse.
PHP käsikirjasta :
Kun esimerkiksi laajennat luokkaa, alaluokka perii kaikki julkiset ja suojatut menetelmät yläluokalta. Ellei luokka ohita näitä menetelmiä, ne säilyttävät alkuperäisen toiminnallisuutensa.
Kun kuitenkin perit toiminnallisuuden luokasta, saatat huomata, että on tärkeää kutsua tiukasti ylätason konstruktoria (__construct- funktiossamme).
Mutta tämä herättää mielestäni yhden tärkeimmistä PHP:n periytymisongelmista (ja koko syyn, miksi halusin sisällyttää tämän osion): Pitääkö meidän kutsua emokonstruktoria eksplisiittisesti?
Myös ohjekirjan mukaan:
Emokonstruktoreja ei kutsuta implisiittisesti, jos aliluokka määrittelee konstruktorin. Pääkonstruktorin suorittamiseksi vaaditaan kutsu emo::__construct() -alennuskonstruktorissa. Jos lapsi ei määrittele konstruktoria, se voidaan periä pääluokasta aivan kuten normaali luokkametodi (jos sitä ei ole ilmoitettu yksityiseksi).
Mutta voimme yksinkertaistaa tätä. Ehkä tämä on helpompi muistaa:
- Jos luokkamme käyttää periytymistä, mutta ei määritä konstruktoria, kutsutaan pääkonstruktoria.
- Jos luokkamme käyttää periytymistä, mutta määrittelee konstruktorin, päärakennetta on kutsuttava eksplisiittisesti.
Tai ehkä vielä yksinkertaisemmin:
- Jos luokkamme ei määritä rakentajaa, koodi on oletuksena vanhempien konstruktori.
Käydä järkeen? Lyhyesti sanottuna, jos määritämme ominaisuudet, alustuksen ja koodin konstruktorissa, luokkamme rakentajan ensimmäisen rivin tulisi olla kutsu ylätason konstruktorille.
Abstraktio
Täysin selväksi, että WP_Widget- luokan lähdekoodi ei sisällä abstrakteja menetelmiä. Osa tästä liittyy luokan rakentamiseen, osa taaksepäin yhteensopivuuteen ja PHP5:n ominaisuuksiin.
Tämä ei kuitenkaan tarkoita, ettemmekö voisi tunnistaa, mitkä funktiot voidaan merkitä abstrakteiksi. Itse asiassa mielestäni se antaa aiheen sille, mitkä luokat tulisi tehdä abstrakteiksi. Mutta ensin määritellään abstraktit funktiot.
Periessään abstraktista luokasta kaikki ylätason luokkailmoituksessa abstraktiksi merkityt menetelmät on lapsen määriteltävä; Lisäksi nämä menetelmät on määriteltävä samalla (tai vähemmän rajoitetulla) näkyvyydellä.
Kun katsot widgetimme lähdettä:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Mielestäni on reilua sanoa, että lomakefunktio voidaan merkitä abstraktiksi, koska se on ainutlaatuinen toteutuksellemme. Toinen tapa ajatella abstrakteja funktioita ohjelmoinnin näkökulmasta on kysyä itseltäsi: Mitkä funktiot vaativat ainutlaatuista toimivuutta?
Ja tässä tapauksessa lomaketoiminto on juuri se, koska jokainen widget on yksilöllisesti erilainen sen suhteen, mitä se tekee. Widget- toiminto voidaan myös merkitä abstraktiksi, koska se tulostaa widgetin sisällön. Tämä sisältö perustuu luonnollisesti toteutuksessamme toteuttamiimme toimintoihin.
Lisäksi itse WP_Widget- luokan lähdekoodi sanoo:
funktio WP_Widget::widget() on ohitettava alaluokassa.’
Juuri tämän tyyppinen funktio tulisi merkitä abstraktiksi. Koska PHP antaa virheen, jos funktio on merkitty abstraktiksi eikä sitä ole toteutettu. Emme tarvinneet die- funktiokutsuja tai muuta vastaavaa.
Muita toimintoja ei kuitenkaan välttämättä tarvitse merkitä abstrakteiksi, ja tästä syystä:
- __construct kutsuu ylätason konstruktoria alkeesimmalla tasolla, ja tämä on välttämätöntä perusluokan alustamiseksi. Älä kuitenkaan unohda; voimme lisätä tähän menetelmään ominaisuutemme, jotka ovat ainutlaatuisia luokallemme.
- päivitys käyttää yläluokan toimintoja tietojen sarjoittamiseen.
Näin ollen meille jää kaksi funktiota, jotka voidaan merkitä abstrakteiksi luokan nykyaikaisemmassa iteraatiossa.
Seuraava
Tässä vaiheessa meidän kaikkien pitäisi olla samalla sivulla oliopohjaisen koodin suhteen. Ainakin sikäli kuin voimme käydä läpi sarjan blogikirjoituksia.
Seuraavasta viestistä alkaen palaamme koodin kirjoittamiseen.
Toisin sanoen, palaamme WordPress Widget Boilerplateen ja aion muuttaa sen nykyiseen tilaan ottamaan käyttöön nykyaikaisemmat PHP-standardit.
Aion jakaa tekemäni muutokset, perustelut miksi, ja sitten puhun myös widgetin tyypistä, jota aiomme rakentaa kattilalevyn perusteella (ja voimme tehdä niin).