OOP:n kaksi ensimmäistä pilaria
Kun puhutaan olio-ohjelmoinnista (tai OOP:sta), kuulet todennäköisesti olio-ohjelmoinnin kolmesta pilarista tai olio-ohjelmoinnin neljästä pilarista.
Taustastasi riippuen olet ehkä jo kuullut niistä, tiedät mitä ne ovat, eikä sinun tarvitse sukeltaa niihin liikaa. Mutta jos et ole, uskon niiden ymmärtämisen olevan olio-ohjelmoinnin perusta.
Olemme kattaneet olio-ohjelmoinnin koko analyysivaiheen :
Tämän jälkeen mennään suunnittelu- ja toteutuskeskusteluihin. Loppujen lopuksi monet ihmiset haluavat hypätä tähän, eikö niin?
Ennen kuin kirjoitan mitään koodia, haluaisin tehdä kaksi viestiä olio-ohjelmoinnin neljästä kohdasta (koska olen yksi niistä, jotka hyväksyvät ajatuksen, että niitä on neljä).
OOP:n kaksi pilaria
Jälleen näiden ymmärtäminen on avainasemassa olio-ohjelmoinnin perustan ymmärtämisessä. Ilman niitä tulee olemaan vaikeaa navigoida tulevissa viesteissä käsiteltävistä asioista.
Sen myötä puhutaanpa jokaisesta niistä. Käsittelemme kaksi ensimmäistä tässä viestissä ja kaksi viimeistä seuraavassa postauksessa.
1 Abstraktio
Yleisesti ottaen tämä on avain oliopohjaisen koodin kirjoittamiseen. Tällä tarkoitan kaikkea, mikä sisältyy luokkaan. Abstraktioimme idean jostakin luokasta. Monissa kirjoissa näemme esimerkiksi Eläimet tai Autot luokkina.
Tämä toimii teoriassa, mutta käytännössä emme ohjelmoi eläimiä emmekä autoja (vaikka tässä historian vaiheessa voisi väittää, että olemme, mutta poikkean siitä, koska tiedät mitä tarkoitan).
Sen sijaan aiomme ottaa ideoita heidän luokkiinsa. Ja tässä on keskeinen ajatus:
Luokan tulee edustaa substantiivia.
Eli sinulla ei pitäisi olla luokkaa, joka edustaa jotain "juoksua". Sen sijaan sinulla voi olla jotain, joka toimii, ja näin ollen suoritukset olisivat menetelmä. Ja tämä on yleinen erittely siitä, miten abstraktio toimii:
- Asia, joka on edustettava, on luokka,
- Asia, jota asia tekee, ovat sen menetelmät,
- Ja tapa, jolla kuvaat asiaa, voidaan yleensä tehdä sen attribuuttien tai ominaisuuksien kautta.
Tämä ei tarkoita, etteikö meillä olisi funktioita tai menetelmiä, jotka muokkaavat sen ominaisuuksia, mutta yllä olevat kolme kohtaa ovat hyviä nyrkkisääntöjä. Joten kun suunnittelet luokkaa, voit kysyä esimerkiksi seuraavia asioita:
- Kirjoitanko jotain?
- Kirjoitanko jotain tekemistä?
- Vai kirjoitanko jotain, joka kuvaa jotain?
Koska jos kirjoitat toimintoa, sen todennäköisesti tekee jokin (koska asiat toimivat – ne tekevät asioita). Ja jos kuvailet jotain, se todennäköisesti viittaa johonkin (milloin et viimeksi kuvaillut mitään?)
Käydä järkeen?
2 Kapselointi
Joten jos kirjoitamme luokkia – hyviä luokkia – meidän on kirjoitettava ne siten, että kapseloimme niiden tiedot oikein. Ja kapselointi on oikeastaan vain "iso" sana, joka viittaa ajatukseen vastuunsa hallinnasta (tai tietojensa seuraamisesta).
Jos esimerkiksi kirjoittaisimme luokkaa edustamaan WordPress-julkaisua, meillä olisi luokka nimeltä Post, jolla on ominaisuuksia, kuten publish, update, delete, postData, publishDate, lastUpdatedData, deletedDate ja niin edelleen.
Sitten meillä olisi toimintoja, jotka on erityisesti suunniteltu toimimaan Post – luokan esiintymässä.
Esimerkkinä voimme…
- julkaista,
- päivittää,
- tai poista viesti
Nämä menetelmät tulevat todennäköisesti esille siten, että muut luokat voivat hyödyntää niitä. Lisäksi nämä menetelmät todennäköisesti hyödyntävät myös muita ominaisuuksia, kuten publishDate tai deletedDate.
Ja tässä näkyy näkyvyyden käsite. Olio-ohjelmoinnissa kapselointi ei viittaa vain ajatukseen luokan sisältämistä tiedoista, vaan myös siihen, miten se paljastaa tiedot.
Nämä tehdään kolmella tavalla, jotka kaikki on määritelty alla:
- julkiset kiinteistöt ja toiminnot ovat kaikkien käytettävissä; julkisia kiinteistöjä ei kuitenkaan yleensä paljasteta. Sen sijaan varmistamme, että niitä voidaan muokata julkisella menetelmällä.
- suojatut ominaisuudet ja funktiot ovat luokan ja minkä tahansa muun luokan, joka perii siitä tietoa, käytettäväksi. Tästä keskustellaan tarkemmin seuraavassa postauksessa.
- yksityiset ominaisuudet ja toiminnot ovat niitä, jotka on tarkoitettu käytettäväksi yksinomaan tietyn luokan yhteydessä. Nämä voivat olla ominaisuuksia, joita käytetään seuraamaan sisäisiä tiloja tai menetelmiä, joita käytetään julkisten toimintojen aputoimintoina suorittamaan työnsä.
Kun jatkamme tätä sarjaa, näemme roolin, joka kullakin näistä on kirjoitettaessa selkeitä, helposti seurattavia ja hyvin suunniteltuja kursseja.
Toistaiseksi on kuitenkin tärkeää ymmärtää, että näitä sanoja, julkinen, suojattu ja yksityinen, kutsutaan näkyvyyden muokkaajiksi, koska ne, kuten voit varmistaa, hallitsevat menetelmän tai ominaisuuden näkyvyyttä suhteessa sen luokkaan ja luokat, jotka perivät siitä ja jotka ovat vuorovaikutuksessa sen kanssa.
Perinnöstä puhuttaessa puhun siitä tämän sarjan seuraavassa osassa.
Abstraktio, kapselointi ja WordPress
Huonot uutiset: WordPress-tunnit
Asia on näin: WordPressissä näemme usein hyvin, hyvin suuria luokkia. Tämä ei ole hyvä asia. Itse asiassa nämä ovat anti-malleja, joita kutsutaan jumalaluokiksi (ajatuksena on, että sinulla on yksi luokka, joka tietää kaiken).
Ja kun sinulla on jumalallinen luokka, se näyttää kätevältä, koska voit pudottaa kaikki toiminnot yhteen paikkaan. Mutta
- sitä on vaikea testata,
- se ei skaalaudu,
- se ei pelaa kauniisti toisen luokan kanssa (puhumattakaan luokista tai kolmannen osapuolen kirjastoista),
- se ei sopeudu hyvin muutoksiin.
Viime kädessä, kun teet niin, et tee olio-ohjelmointia. Otat funktioita ja heität ne luokkaan. Ja haluamme päästä eroon siitä.
Hyvät uutiset: Kirjoituskurssit WordPressissä
Tämä herättää kuitenkin kysymyksen: Miksi yrittää oppia olio-ohjelmointia WordPressillä, jos se ei ole vankka esimerkki olio-ohjelmoinnista?
Tämä johtuu siitä, että voit silti kirjoittaa hyvää oliokoodia WordPressissä. Se voi silti olla hyvin vuorovaikutuksessa WordPressin kanssa, ja se voi silti pelata hienosti monien muiden WordPressin osien kanssa.
Tiedän, että se kuulostaa intuitiiviselta, mutta kun sukeltamme syvemmälle oliokoodin kirjoittamiseen WordPressissä, tämän pitäisi tulla selväksi.