OOP kaks esimest sammast
Kui rääkida objektorienteeritud programmeerimisest (või OOP-st), kuulete tõenäoliselt objektorienteeritud programmeerimise kolmest sambast või objektorienteeritud programmeerimise neljast sambast.
Olenevalt teie taustast olete võib-olla neist juba kuulnud, teate, mis need on, ja te ei pea sellesse liiga palju süvenema. Aga kui te seda pole, usun, et nende mõistmine on objektorienteeritud programmeerimise aluseks.
Oleme läbinud kogu objektorienteeritud programmeerimise analüüsifaasi :
Seda öeldes asume disaini ja rakendamise aruteludesse. Lõppude lõpuks tahavad paljud inimesed selle poole hüpata, kas pole?
Enne mis tahes koodi kirjutamist tahaksin teha kaks postitust objektorienteeritud programmeerimise neljast punktist (sest olen üks neist, kes nõustub ideega, et neid on neli).
OOP kaks sammast
Jällegi, nende mõistmine on objektorienteeritud programmeerimise aluse mõistmiseks võtmetähtsusega. Ilma nendeta on tulevastes postitustes käsitletavas osas raske navigeerida.
Sellega räägime neist igaühest. Kahte esimest käsitleme selles postituses ja kahte viimast järgmises postituses.
1 Abstraktsioon
Üldiselt on see objektorienteeritud koodi kirjutamise võti. Selle all pean silmas kõike, mis klassis sisaldub. Abstraheerime idee millestki klassi. Paljudes raamatutes näeme klassidena selliseid asju nagu loomad või autod .
Teoreetiliselt see toimib, kuid praktilises mõttes me ei programmeeri loomi ega programmeeri autosid (kuigi ma arvan, et praegusel ajaloohetkel võite väita, et oleme, aga ma kaldun kõrvale, sest teate, mida ma mõtlen).
Selle asemel abstraheerime ideid nende klassidesse. Ja siin on põhiidee:
Klass peaks esindama nimisõna.
See tähendab, et teil ei tohiks olla klassi, mis esindab midagi sellist nagu "jooksmine". Selle asemel võib teil olla midagi, mis töötab ja seega oleks käitamine meetod. Ja see on abstraktsiooni toimimise üldine jaotus:
- Asi, mida tuleb esindada, on klass,
- Asi, mida asi teeb, on selle meetodid,
- Ja seda, kuidas te asja kirjeldate, saab seda tavaliselt teha selle atribuutide või omaduste kaudu.
See ei tähenda, et meil ei oleks funktsioone või meetodeid, mis selle omadusi muudaksid, kuid ülaltoodud kolm punkti on head rusikareeglid. Nii et klassi kujundamisel võite küsida järgmisi asju:
- Kas ma kirjutan midagi?
- Kas ma kirjutan midagi, mida teha?
- Või kirjutan ma midagi, mis kirjeldab midagi?
Sest kui kirjutate toimingut, teeb selle tõenäoliselt miski (kuna asjad tegutsevad – nad teevad asju). Ja kui kirjeldate midagi, viitab see tõenäoliselt millelegi (millal te viimati midagi ei kirjeldanud?)
On loogiline?
2 Kapseldamine
Nii et kui me kirjutame klasse – häid klasse –, peame need kirjutama nii, et oleksime nende andmed korralikult kapseldatud. Ja kapseldamine on tegelikult lihtsalt "suur" sõna, mis viitab ideele oma kohustuste haldamisest (või andmete jälgimisest).
Näiteks kui kirjutaksime klassi WordPressi postituse esindamiseks, oleks meil klass nimega Post, millel on sellised omadused nagu avaldamine, värskendamine, kustutamine, postData, publishDate, lastUpdatedData, deletedDate ja nii edasi.
Siis oleks meil funktsioonid, mis on spetsiaalselt loodud klassi Post eksemplari suhtes toimingute tegemiseks.
Näiteks võime…
- avaldada,
- värskendus,
- või kustuta postitus
Need meetodid avaldatakse tõenäoliselt nii, et teised klassid saavad neid ära kasutada. Lisaks kasutavad need meetodid tõenäoliselt ära ka muid atribuute, nagu publishDate või deletedDate.
Ja siin tuleb mängu nähtavuse mõiste. Objektorienteeritud programmeerimises ei viita kapseldamine mitte ainult klassis sisalduva teabe ideele, vaid ka sellele, kuidas see andmeid paljastab.
Neid tehakse kolmel viisil, mis kõik on määratletud allpool:
- avalikud omadused ja funktsioonid on kõigile kättesaadavad; avalikke varasid aga tavaliselt ei eksponeerita. Selle asemel tagame, et neid saab avalikul meetodil muuta.
- kaitstud atribuudid ja funktsioonid on saadaval kasutamiseks klassile ja mis tahes muule klassile, mis pärib sellelt teavet. Sellest tuleb täpsemalt juttu järgmises postituses.
- privaatsed omadused ja funktsioonid on need, mis on mõeldud kasutamiseks ainult antud klassi kontekstis. Need võivad olla atribuudid, mida kasutatakse sisemiste olekute või meetodite jälgimiseks, mida kasutatakse avalike funktsioonide abifunktsioonidena nende töö lõpetamiseks.
Seda sarja jätkates näeme, millist rolli mängivad kõik need selgete, hõlpsasti jälgitavate ja hästi üles ehitatud tundide kirjutamisel.
Praegu on aga oluline mõista, et neid sõnu avalik, kaitstud ja privaatne nimetatakse nähtavuse muutjateks, sest nagu saate kindlaks teha, juhivad need meetodi või atribuudi nähtavust selle klassi ja klassid, mis sellelt pärivad ja sellega suhtlevad.
Pärimisest rääkides räägin sellest selle sarja järgmises osas.
Abstraktsioon, kapseldamine ja WordPress
Halvad uudised: WordPressi klassid
Siin on asi: WordPressis näeme sageli väga-väga suuri klasse. See ei ole hea. Tegelikult on need antimustrid, mida nimetatakse jumalaklassideks (mõte seisneb selles, et teil on üks klass, kes teab kõike).
Ja kui teil on jumalik klass, tundub see mugav, sest saate kõik funktsioonid ühte kohta koondada. Aga
- seda on raske katsetada,
- see ei ulatu,
- see ei mängi kenasti teise klassiga (rääkimata klassidest või kolmandate osapoolte raamatukogudest),
- see ei kohane muutustega hästi.
Lõppkokkuvõttes, kui te seda teete, ei tee te objektorienteeritud programmeerimist. Sa võtad funktsioone ja viskad need klassi. Ja me tahame sellest lahti saada.
Hea uudis: WordPressis kirjutamiskursused
See tõstatab aga küsimuse: miks proovida õppida objektorienteeritud programmeerimist WordPressiga, kui see pole objektorienteeritud programmeerimise kindel näide?
Selle põhjuseks on asjaolu, et WordPressis saate endiselt kirjutada head objektorienteeritud koodi. See suudab endiselt WordPressiga hästi suhelda ja suudab endiselt kenasti mängida paljude muude WordPressi aspektidega.
Ma tean, et see kõlab intuitiivselt, kuid kui me süveneme WordPressis objektorienteeritud koodi kirjutamisse, peaks see selgeks saama.