De två första pelarna i OOP
När det kommer till att prata om objektorienterad programmering (eller OOP), kommer du sannolikt att höra om The Three Pillars of Object-Oriented Programming eller The Four Pillars of Object-Oriented Programming.
Beroende på din bakgrund kanske du redan har hört talas om dem, vet vad de är och behöver egentligen inte fördjupa dig i det för mycket. Men om du inte har det, tror jag att förståelse för dem är grundläggande för objektorienterad programmering.
Vi har täckt hela analysfasen av objektorienterad programmering:
Med det sagt, låt oss gå in i design- och implementeringsdiskussioner. Det är trots allt vad många vill hoppa till ändå, eller hur?
Innan jag skriver någon kod skulle jag vilja göra två inlägg om de fyra punkterna i objektorienterad programmering (eftersom jag är en av dem som prenumererar på tanken att det finns fyra).
Två pelare av OOP
Återigen, att förstå dessa är nyckeln till att förstå grunden för objektorienterad programmering. Utan dem kommer det att bli svårt att navigera i resten av det som ska diskuteras i framtida inlägg.
Med det, låt oss prata om var och en av dem. Vi tar upp de två första i det här inlägget och de två sista i nästa inlägg.
1 Abstraktion
Generellt sett är detta nyckeln till att skriva objektorienterad kod. Med det menar jag allt som finns i en klass. Vi abstraherar idén om något till en klass. I många böcker kommer vi att se saker som Djur eller Bilar representerade som klasser.
Det här fungerar i teorin, men i praktiken programmerar vi inte djur och inte heller programmerar vi bilar (även om jag antar att vi vid denna tidpunkt i historien kan hävda att vi är det, men jag avviker för du vet vad jag menar).
Istället kommer vi att abstrahera idéer i deras klasser. Och det finns en nyckelidé här:
En klass ska representera ett substantiv.
Det vill säga, du bör inte ha en klass som representerar något som "löpning". Istället kan du ha något som körs och därför skulle körningar vara en metod. Och det är den allmänna uppdelningen av hur abstraktion fungerar:
- Det som ska representeras är klassen,
- Saken gör är dess metoder,
- Och sättet du beskriver saken kan vanligtvis göras via dess attribut eller egenskaper.
Det betyder inte att vi inte har funktioner eller metoder som ändrar dess egenskaper, men de tre punkterna ovan är bra tumregler. Så när du designar en klass kan du fråga saker som:
- Skriver jag något?
- Skriver jag något att göra?
- Eller skriver jag något som beskriver något?
För om du skriver en handling, är det troligtvis gjort av något (eftersom saker agerar – de gör saker). Och om du beskriver något, så hänvisar det troligen till något (när var sista gången du inte beskrev något?)
Vettigt?
2 Inkapsling
Så om vi skriver klasser – bra klasser – måste vi skriva dem på ett sådant sätt att vi kapslar in deras data ordentligt. Och inkapsling är egentligen bara ett "stort" ord som hänvisar till idén om att hantera sitt ansvar (eller hålla reda på dess data).
Så, till exempel, om vi skulle skriva en klass för att representera ett WordPress-inlägg så skulle vi ha en klass som heter Post med egenskaper som publicera, uppdatera, ta bort, postData, publishDate, lastUpdatedData, deletedDate och så vidare.
Då skulle vi ha funktioner som är speciellt utformade för att vidta åtgärder på en instans av klassen Post.
Som exempel kan vi …
- publicera,
- uppdatering,
- eller ta bort ett inlägg
Dessa metoder kommer sannolikt att exponeras på ett sådant sätt att andra klasser kan dra nytta av dem. Dessutom kommer dessa metoder sannolikt också att dra nytta av andra egenskaper som publishDate eller deletedDate.
Och det är här begreppet synlighet kommer in i bilden. I objektorienterad programmering hänvisar inkapsling inte bara till idén om informationen som en klass innehåller utan hur den exponerar data.
Dessa görs på tre sätt som alla definieras nedan:
- offentliga egenskaper och funktioner är tillgängliga för alla att använda dem; offentliga fastigheter är dock vanligtvis inte exponerade. Istället ser vi till att de kan modifieras med en offentlig metod.
- skyddade egenskaper och funktioner är tillgängliga för att användas av klassen och alla andra klasser som ärver information från den. Detta kommer att diskuteras mer i detalj i nästa inlägg.
- privata egenskaper och funktioner är de som uteslutande är avsedda att användas inom ramen för en given klass. Dessa kan vara egenskaper som används för att spåra interna statusar eller metoder som används för att fungera som hjälpfunktioner för offentliga funktioner för att slutföra sitt arbete.
När vi fortsätter genom den här serien kommer vi att se vilken roll var och en av dessa spelar när vi skriver tydliga, lätta att följa, väl utformade klasser.
För nu är det dock viktigt att förstå att dessa ord, offentliga, skyddade och privata, kallas synlighetsmodifierare eftersom de, som du kan konstatera, hanterar synligheten för en metod eller en egenskap med avseende på dess klass och klasser som ärver från det och som interagerar med det.
På tal om arv, jag kommer att prata om det i nästa del av den här serien.
Abstraktion, inkapsling och WordPress
De dåliga nyheterna: Kurser i WordPress
Så här är det: I WordPress ser vi ofta väldigt, väldigt stora klasser. Det här är inte bra. I själva verket är dessa antimönster som kallas gudaklasser (tanken är att du har en enda klass som kan allt).
Och när du har en gudaklass verkar det bekvämt eftersom du kan släppa all funktionalitet på ett ställe. Men
- det är svårt att testa,
- den skalar inte,
- det spelar inte bra med en annan klass (för att inte tala om klasser eller tredjepartsbibliotek),
- den anpassar sig inte bra till förändringar.
I slutändan, när du gör det, gör du inte objektorienterad programmering. Du tar funktioner och kastar in dem i en klass. Och det vill vi komma ifrån.
De goda nyheterna: Skrivkurser på WordPress
Detta väcker dock en fråga: Varför försöka lära sig objektorienterad programmering med WordPress om det inte är ett gediget exempel på objektorienterad programmering?
Det beror på att du fortfarande kan skriva bra objektorienterad kod på WordPress. Det kan fortfarande interagera bra med WordPress, och det kan fortfarande spela bra med många andra aspekter av WordPress.
Jag vet att det låter kontraintuitivt, men när vi dyker djupare in i att skriva objektorienterad kod på WordPress borde detta bli tydligt.