Nagu ma selle seeria esimeses postituses mainisin, kuulete sageli teemal "The Three Pillars of Object-Oriented Programming". Samuti võite kuulda objektorienteeritud programmeerimise neljast sambast.
Ja asi pole selles, et neid on kokku seitse või midagi sellist. Selle asemel on see rohkem seotud sellega, mida inimesed peavad OOP-i aluseks: kas on kolm või neli peamist kontseptsiooni?
Eelmisest artiklist (pealkirjast rääkimata) võite aimata, ma usun, et neid on neli.
Ja selles postituses käsitlen kahte viimast:
- Pärand,
- ja polümorfism
Kui olete enne selle artikli lugemist teinud mis tahes tüüpi objektorienteeritud programmeerimist, olete tõenäoliselt kuulnud vähemalt ühest neist.
Vaatamata sellele vaatame igaüks neist üksikasjalikumalt.
Veel kaks OOP-i sammast
Enne kõigi nende juurde hüppamist tahan olla kindel, et olete seni käsitletuga kursis.
Sõna analüüsist
Ma ei hakka seda mõtet käsitlema, kuid põhjus, miks ma nüüd objektorienteeritud põhitõdedest räägin, on see, et me liigume selle materjali teise faasi. Alustasime analüüsifaasi katmisega, mis hõlmas järgmist:
Nüüd Arengu juurde
Ja nüüd oleme arendusfaasis. Mõned võivad seda nimetada põhitõdedeks (kuid ma olen rahul, et ilma põhialusteta ei saa head arendust teha, nii et see on nii (.
Kui te pole eelmist postitust lugenud, soovitan seda teha enne jätkamist, kuna see hõlmab abstraktsiooni, kapseldamise ja selle seost WordPressiga.
3 Pärand
Pärimise kontseptsiooni on üsna lihtne järgida. See tähendab, et üks klass võib pärida teise klassi atribuute. Toon selle kohta mõne näite, kuid lubage mul esitada selle postituse jaoks töötav määratlus:
Pärimine viitab ideele, et ühel klassil, kuigi sellel on oma rakendus, pärib see sõna otseses mõttes ülemklassi omadused, funktsioonid ja üldise teostuse.
Näide 1: dokument
Väga lihtsalt öeldes oletame, et teil on klass nimega Dokument ja dokumendil on pealkiri ja sellel on sisu. Seejärel on dokumendi alamklass, millel on kuupäeva ja kellaaja atribuudid. Võiksime seda nimetada PostDocument või PageDocument.
See tähendab, et PageDocument pärib Dokumendi atribuudid ja atribuudid, lisades sellele ka oma teostuse. On loogiline?
Kui ei, siis ärge muretsege. See ei pruugi alati alguses "klõpsata", nii et vaatame teist näidet.
Näide 2: Sõnum
Oletame, et meil on sõnumiklass. Sõnumil on tavaliselt kaks omadust:
- 1 saatja,
- 2 Saaja.
On aus öelda, et sõnumeid on erinevat tüüpi, eks? See tähendab, et võib-olla on meil meilisõnum või tekstsõnum.
Meilisõnumil on endiselt saatja ja saaja, kuid sellel on palju muud, eks? Sellel on sellised asjad nagu:
- teemarida,
- valikuline lisand,
- teine saatjate komplekt, kellele see on saadetud,
- tugi teiste avalikult või privaatselt sõnumisse kopeerimiseks,
- ja palju muud.
Tekstsõnumis seevastu ei pruugi olla kõike ülaltoodut. Oletame, et räägime lihtsast SMS-sõnumist (võrreldes rikastekstsõnumiga näiteks Hangoutsis, Telegramis, iMessage’is või mis iganes muus saadaval).
See klass:
- olema seotud telefoninumbriga,
- võib hõlmata rühma teisi adressaate, kes kõik on avalikud,
- operaator (see on mobiilsideteenuse pakkuja),
- maksimaalne märkide arv, mida see võib sisaldada
- võimalus jagada üks sõnum mitmeks sõnumiks, kui märkide maksimaalne arv ületab teatud tähemärkide arvu.
Kuid see tekitab siiski küsimusi omaduste ja meetodite (või üldisemalt rakendamise kohta, eks?)
Sõna rakendamisest
Kui rääkida objektorienteeritud programmeerimisest, on meil nn juurdepääsu modifikaatorid. Võib-olla olete neid mujal lugenud, näiteks nähtavuse muutjatena või millegi sellisena.
Kõik on sama.
Lühidalt võib neid modifikaatoreid määratleda järgmiselt:
Märksõnad, mis määravad, millistel klassidel on juurdepääs olemasolevale teabele.
Lucikly, sellest osast on lihtne aru saada:
- privaatsed atribuudid ja funktsioonid on juurdepääsetavad ainult klassile, milles need on määratletud. See tähendab, et PostDocument ei saa kasutada midagi dokumendis, mis on märgitud privaatseks. Kõigil kavatsustel ja eesmärkidel pole PostDocument isegi teadlik selle teabe olemasolust.
- kaitstud omadused ja funktsioonid on juurdepääsetavad klassile, milles need on määratletud, ja mis tahes klassile, mis on järglane. See tähendab, et igal klassil, mis pärib andmed baasklassist või ülemklassist, on sellele juurdepääs. Seega, erinevalt privaatsetest juurutamise üksikasjadest, pääseb PostDocument juurde dokumendi teabele, kui see on kaitstuks märgitud.
- avalikud omadused ja funktsioonid on kõigile kättesaadavad. Sellel pole tegelikult midagi pistmist pärimisega, vaid rohkem kapseldamisega, kui üldse. Selle asemel tuleb otsustada, millele tahame, et teised objektid pääseksid juurde.
Kuidas siis rakendamist käsitletakse? See on keeleti erinev, kuid PHP ei toeta seda, mida nimetatakse "mitmekordseks pärandiks". Lihtsamalt öeldes saab PHP antud klass pärida (või laiendada) ainult ühte teist klassi. Mitte mitut klassi (mõned keeled toetavad seda).
Klassi laiendamisel pärib alamklass ülemklassilt kõik avalikud ja kaitstud meetodid. Kui klass neid meetodeid ei alista, säilitavad need oma algsed funktsioonid.
Meie näites ei saa me tutvustada teist klassi, näiteks WrittenDocument, mis pärib nii PageDocument kui ka PostDocument. See on kas üks või teine. Ja väärib märkimist, et kui see pärib PostDocumentilt, pärib see teabe ka dokumendist, kuna see on klassi alamklassi alamklass.
4 Polümorfism
Nüüd, kui meil on paigas pärimise põhidefinitsioon, võime rääkida polümorfismist. Hea uudis on see, et see on suur ja imelik sõna väga lihtsa kontseptsiooni jaoks.
Halb uudis on see, et me pole rääkinud liidestest ega abstraktsetest klassidest. Need on tulemas, kuid neid peetakse nelja samba osaks, nii et ärge nende pärast praegu muretsege.
Selle asemel mõelge sellele järgmiselt:
Polümorfism võimaldab meil viidata ühe tüübi klassile, kui seda võidakse deklareerida teise tüübina.
See võib endiselt segadust tekitada, kuid kas mäletate meie näiteks ülaltoodud sõnumi näidet? Saame luua SMSMessage klassi, mis laiendab klassi Sõnum ja seejärel kutsuda sellel teatud meetodeid.
SMSMessage’il võib olla meetod, mis klassil Message on. Ja kui klass on loodud SMSMessage klassi eksemplarina, kutsub see seda meetodit välja. Samamoodi, kui sellel pole meetodit, kuid selle vanemklassil Message on see olemas, kutsub ta seda meetodit.
Mõnikord on seda kõige lihtsam koodis mõista, nii et teeme seda.
Esiteks määratleme oma sõnumiklassi :
<?php
class Message
{
public function send()
{
echo "This message is sent from the Message class.n";
}
public function receive()
{
echo "This message was received from the Message class.n";
}
}
Seejärel määratleme oma SMSMessage klassi. Pange tähele, et sellel ei ole Receive() funktsiooni. See on hetkega oluline:
<?php
class SMSMessage extends Message
{
public function send()
{
echo "This message is sent from the SMSMessage class.n";
}
}Nüüd loome oma sõnumiklassi ja kutsume välja mõned meetodid:
<?php
$message = new Message();
$message->send();
$message->receive();Ja teeme sama, kasutades SMSMessage klassi:
<?php
$message = new SMSMessage();
$message->send();
$message->receive();Kui soovite kogu skripti, näete seda siin, saate selle alla laadida ja kohapeal käivitada.
Pärand, polümorfism ja WordPress
Siin on näpunäide (ja me uurime seda lähemalt, kui jõuame liideste ja abstraktsete klasside juurde): kui klass laiendab teist klassi ja sellel puuduvad juurutamise üksikasjad, mis tema ülemklassil on, kasutatakse ülemrakendust.
Teine mõtteviis on "käsuahela ülestöötamine". See algab meie loodud klassist madalaima klassiga. Meie ülaltoodud näites on see SMS-sõnum. Kui ta seda sealt ei leia, liigub see klassi, mida ta laiendab. (Ja kui see seda sealt ei leia ja see klass laiendab klassi, proovib ta seal.)
Kogu polümorfne asi on järgmine: oleme loonud ühte tüüpi klassi SMSMessage, kuid see kasutab teist tüüpi klassi rakendamist (jah, et see pärib, kuid see on siiski erinev).
Kursuste kirjutamine WordPressis
Lõpetuseks tahaksin jätta teile selle: ma mainisin midagi sarnast eelmises postituses, kuid tahan seda siin korrata.
Olenemata sellest, kui paljusid neist kontseptsioonidest WordPressi tuum kasutab, pole see oluline, sest me saame WordPressis kirjutada kvaliteetset objektorienteeritud koodi, mis suhtleb WordPressiga ja mängib kenasti WordPressiga (ja muu kolmanda osapoole koodiga – mitte alati)., kuid mitu korda).
Mis edasi saab?
Järgmisena vaatleme liideseid ja abstraktsioone.
Need on objektorienteeritud programmeerimise jaoks endiselt olulised, kuid kui olete kahest eelmisest postitusest aru saanud, olete valmis saama eelseisvate kontseptsioonidega kindla kogemuse.
Ja kui ei, siis ärge muretsege! Võite sellest alati kommentaarides rääkida või meili teel rohkem vestelda.