OOP:n kaksi toista pilaria
Kuten mainitsin tämän sarjan ensimmäisessä viestissä, tulet usein kuulemaan olio-ohjelmoinnin kolmesta pilarista. Saatat myös kuulla olio-ohjelmoinnin neljästä pilarista.
Eikä kyse ole siitä, että niitä on yhteensä seitsemän tai mitään sellaista. Sen sijaan kyse on enemmän siitä, mitä ihmiset pitävät OOP:n perustana: Onko olemassa kolme vai neljä pääkonseptia?
Voit päätellä edellisestä artikkelista (otsikosta puhumattakaan), uskon, että niitä on neljä.
Ja tässä postauksessa aion kattaa kaksi viimeistä:
- perintö,
- ja polymorfismi
Jos olet tehnyt minkä tahansa olio-ohjelmoinnin ennen tämän artikkelin lukemista, olet todennäköisesti kuullut ainakin yhdestä näistä.
Siitä huolimatta, katsotaanpa kutakin niistä yksityiskohtaisemmin.
Kaksi muuta OOP:n pilaria
Ennen kuin ryhdyn näihin kaikkiin, haluan olla varma, että olet perehtynyt siihen, mitä olemme käsitelleet tähän mennessä.
Sana analyysistä
En käsittele asiaa, mutta koko syy, miksi puhun nyt oliokeskeisistä perusteista, on se, että olemme siirtymässä tämän materiaalin eri vaiheeseen. Aloimme käsitellä analyysivaihetta, joka sisälsi:
Nyt Kehitykseen
Ja nyt ollaan kehitysvaiheessa. Jotkut saattavat kutsua sitä perusteiksi (mutta olen tyytyväinen, että et voi tehdä hyvää kehitystä ilman perusasioita, joten siinä on (.
Jos et ole lukenut edellistä viestiä, suosittelen tekemään niin ennen kuin jatkat, sillä se kattaa käsitteet abstraktio, kapselointi ja miten se liittyy WordPressiin.
3 Perintö
Perinnön käsite on melko helppo seurata. Eli yksi luokka voi periä toisen luokan attribuutteja. Annan muutaman esimerkin tästä hetkessä, mutta anna minun antaa toimiva määritelmä tämän viestin tarkoituksiin:
Periytys viittaa ajatukseen, että yksi luokka, vaikka sillä on oma toteutus, kirjaimellisesti perii ominaisuudet, funktiot ja yleisen toteutuksen emoluokalta.
Esimerkki 1: Asiakirja
Hyvin yksinkertaisesti sanottuna, oletetaan, että sinulla on luokka nimeltä Asiakirja ja asiakirjalla on otsikko ja sillä on sisältö. Sitten on asiakirjan alaluokka, jolla on päivämäärän ja ajan määritteet. Voisimme kutsua tätä PostDocumentiksi tai PageDocumentiksi.
Toisin sanoen PageDocument perii Documentin ominaisuudet ja attribuutit samalla kun lisää siihen oman toteutuksensa. Käydä järkeen?
Jos ei, älä huoli. Se ei aina "klikkaa" aluksi, joten katsotaanpa toista esimerkkiä.
Esimerkki 2: Viesti
Oletetaan, että meillä on Viesti-luokka. Viestillä on tyypillisesti kaksi ominaisuutta:
- 1 Lähettäjä,
- 2 Vastaanottaja.
On kuitenkin reilua sanoa, että viestejä on erilaisia, eikö? Eli ehkä meillä on sähköpostiviesti tai kenties tekstiviesti.
Sähköpostiviestillä on edelleen lähettäjä ja edelleen vastaanottaja, mutta sillä on paljon muuta, eikö? Siinä on asioita, kuten:
- aiherivi,
- valinnainen liite,
- toinen joukko lähettäjiä, joille se on lähetetty,
- tuki muiden kopioimiseen viestiin julkisesti tai yksityisesti,
- ja paljon enemmän.
Toisaalta tekstiviestissä ei välttämättä ole kaikkia yllä olevia. Oletetaan, että puhumme perustekstiviestistä (verrattuna monimuotoiseen tekstiviestiin, kuten Hangoutsissa, Telegramissa, iMessagessa tai missä tahansa muussa).
Tämä luokka:
- olla sidottu puhelinnumeroon,
- voi sisältää ryhmän muita vastaanottajia, jotka kaikki ovat julkisia,
- operaattori (eli matkapuhelinoperaattori),
- enimmäismäärä merkkejä, jonka se voi sisältää
- mahdollisuus jakaa yksi viesti useiksi viesteiksi, jos merkkien enimmäismäärä ylittää tietyn merkkimäärän.
Mutta se herättää silti kysymyksiä ominaisuuksista ja menetelmistä (tai yleisemmin toteutuksesta, eikö?)
Sana toteutuksesta
Mitä tulee olio-ohjelmointiin, meillä on niin kutsutut käyttöoikeusmuuntimet. Ehkä olet lukenut niitä muualla, esimerkiksi näkyvyyden muokkaajiksi tai vastaavaksi.
Ihan sama.
Lyhyesti sanottuna nämä muuntajat voidaan määritellä seuraavasti:
Avainsanat, jotka määräävät, mitä muilla luokilla on pääsy käsillä olevaan tietoon.
Lucikly, tämä osa on helppo ymmärtää:
- yksityiset ominaisuudet ja funktiot ovat vain sen luokan käytettävissä, jossa ne on määritelty. Tämä tarkoittaa, että PostDocument ei voi käyttää mitään yksityiseksi merkityssä asiakirjassa. PostDocument ei ole edes tietoinen näiden tietojen olemassaolosta.
- suojatut ominaisuudet ja toiminnot ovat saatavilla luokalle, jossa ne on määritelty, ja kaikille luokille, jotka ovat jälkeläisiä. Toisin sanoen kaikilla luokilla, jotka perivät tiedot perusluokalta tai emaluokalta, on pääsy siihen. Joten toisin kuin yksityiset toteutustiedot, PostDocument voi käyttää tietoja asiakirjasta, jos se on merkitty suojatuksi.
- julkiset kiinteistöt ja toiminnot ovat kaikkien saatavilla. Tällä ei todellakaan ole mitään tekemistä perinnön kanssa, vaan enemmän kapseloinnin kanssa, jos mitään. Sen sijaan kyse on päättämisestä, mitä haluamme muiden objektien pääsevän käsiksi.
Miten toteutus sitten hoidetaan? Tämä vaihtelee kielestä toiseen, mutta PHP ei tue niin sanottua "moniperintöä". Yksinkertaisesti sanottuna tietty PHP:n luokka voi periä (tai laajentaa) vain yhden muun luokan. Ei useita luokkia (jotkut kielet tukevat tätä).
Kun laajennat luokkaa, alaluokka perii kaikki julkiset ja suojatut menetelmät pääluokasta. Ellei luokka ohita näitä menetelmiä, ne säilyttävät alkuperäisen toiminnallisuutensa.
Esimerkissämme emme voi ottaa käyttöön toista luokkaa, kuten WrittenDocument, joka perii PageDocumentista sekä PostDocumentista. Se on joko yksi tai toinen. Ja on syytä huomata, että jos se perii PostDocumentista, se perii myös tiedot asiakirjasta, koska se on luokan alaluokan alaluokka.
4 Polymorfismi
Nyt kun meillä on perinnön perusmääritelmä, voimme puhua polymorfismista. Hyvä uutinen on, että se on suuri, outo sana hyvin yksinkertaiselle käsitteelle.
Huono uutinen on, että emme ole puhuneet käyttöliittymistä tai abstrakteista luokista. Näitä on tulossa, mutta niitä pidetään osana neljää pilaria, joten älä huolehdi niistä juuri nyt.
Ajattele sen sijaan näin:
Polymorfismin avulla voimme viitata yhden tyypin luokkaan, kun se voidaan julistaa toiseksi tyypiksi.
Se voi silti olla hämmentävää, mutta muistatko esimerkiksi yllä olevan Viestiesimerkkimme? Voimme luoda SMSMessage-luokan, joka laajentaa Viesti-luokkaa ja kutsua sitten tiettyjä menetelmiä siinä.
SMSMessagella voi olla menetelmä, joka on Viesti-luokassa. Ja jos luokka on instantoitu SMSMessage-luokan esiintymänä, se kutsuu tätä menetelmää. Vastaavasti, jos sillä ei ole menetelmää, mutta sen pääluokassa Message on se, se kutsuu sitä menetelmää.
Joskus on helpointa ymmärtää tämä koodissa, joten tehdään niin.
Ensin määritellään viestiluokkamme :
<?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";
}
}
Sitten määritellään SMSMessage -luokkamme. Huomaa, että siinä ei ole Receive()- funktiota. Tämä on hetkellisesti tärkeää:
<?php
class SMSMessage extends Message
{
public function send()
{
echo "This message is sent from the SMSMessage class.n";
}
}Instantoidaan nyt Viesti – luokkamme ja kutsutaan muutama menetelmä:
<?php
$message = new Message();
$message->send();
$message->receive();Ja tehdään sama käyttämällä SMSMessage-luokkaa:
<?php
$message = new SMSMessage();
$message->send();
$message->receive();Jos haluat koko skriptin, voit nähdä sen täältä, ladata sen ja suorittaa sen paikallisesti.
Perinnöllisyys, polymorfismi ja WordPress
Tässä on otos (ja tutkimme tätä enemmän, kun tutustumme käyttöliittymiin ja abstrakteihin luokkiin): Kun luokka laajentaa toista luokkaa eikä sillä ole sen yläluokan toteutustietoja, käytetään ylätason toteutusta.
Toinen tapa ajatella sitä on "työstää komentoketjua". Se alkaa luokasta, joka on alhaisin luomamme. Yllä olevassa esimerkissämme se on SMSMessage. Jos se ei löydä sitä sieltä, se siirtyy luokkaan, johon se ulottuu. (Ja jos se ei löydä sitä sieltä ja luokka laajentaa luokkaa, se yrittää siellä.)
Koko polymorfinen asia on tämä: Olemme instantoineet yhden tyypin luokan, SMSMessage, mutta se käyttää toisen tyypin luokan toteutusta (jota se perii, kyllä, mutta se on kuitenkin erilainen).
Kurssien kirjoittaminen WordPressissä
Lopuksi haluan jättää sinulle tämän: Olen maininnut jotain vastaavaa edellisessä viestissä, mutta haluan toistaa sen tässä.
Riippumatta siitä, kuinka monta näistä käsitteistä WordPress-ydin käyttää, sillä ei ole väliä, koska voimme kirjoittaa WordPressiin korkealaatuista, oliopohjaista koodia, joka on vuorovaikutuksessa WordPressin kanssa ja joka toimii hienosti WordPressin (ja muun kolmannen osapuolen koodin – ei aina) kanssa., mutta monta kertaa).
Mitä seuraavaksi?
Seuraavaksi tarkastelemme käyttöliittymiä ja abstraktioita.
Nämä ovat edelleen olennaisia olio-ohjelmoinnin kannalta, mutta jos olet ymmärtänyt kaksi edellistä viestiä, olet valmis saamaan vankan kokemuksen tulevista käsitteistä.
Ja jos ei, älä huoli! Voit aina keskustella siitä kommenteissa tai voimme keskustella aiheesta lisää sähköpostitse.