Objektorienterad programmering i WordPress Omfattning

När vi fortsätter vår diskussion om objektorienterad programmering i WordPress, måste vi börja prata om tanken om omfattning. Kort sagt, det här hänvisar till idén om att klasser kan styra hur deras attribut och funktioner är åtkomliga (eller huruvida de inte ens kan nås).

Detta är ännu en kärnidé av objektorienterad programmering, varefter vi borde vara i god form för att börja arbeta med en verklig WordPress-plugin.

Innan du går framåt, var vänlig och observera att varje artikel i den här serien bygger på den innan den, så om du bara går med oss, var god och kolla in de tidigare artiklarna i serien:

1. En introduktion
2. Klasser
3. typer
4. Kontrollstrukturer: Villkorliga uttalanden
5. Kontrollstrukturer: Loops
6. Funktioner och attribut

När vi är alla fångade, låt oss fortsätta vår diskussion om den sista delen av paradigmet som är nödvändigt för att vi ska förstå innan vi går in i praktisk tillämpning av objektorienterad programmering inom WordPress.

Definiera omfattning

Enligt Wikipedia är den första definitionen av omfattningen följande:

I dataprogrammering är omfattningen av ett namn bindande - en association av ett namn till en enhet, såsom en variabel - den del av ett datorprogram där bindningen är giltig: där namnet kan användas för att hänvisa till enheten. I andra delar av programmet kan namnet referera till en annan enhet (det kan ha en annan bindning), eller alls ingenting (det kan vara obundet).

Om du inte är en erfaren programmerare är det lite förvirrande, eller hur? Faktum är att det kanske kan läsa som lite jargong.

Men det är okej eftersom syftet med denna artikel är att tillhandahålla en arbetsdefinition av räckvidd samt några praktiska exempel på hur det ser ut inom ramen för ett program.

Så, innan vi tittar på de tre olika aspekterna av räckvidd i objektorienterad programmering, låt oss formulera en renare definition. 

Kortfattat refererar räckvidd till hur variabler och funktioner kan vara åtkomst från tredje parts objekt eller barnobjekt inom programmet. 

Till exempel, säg att du har en inlägg objekt och an Författare objekt. Låt oss nu säga att författaren har attribut för förnamn och efternamn och den inlägg vill komma åt dem för att exempelvis visa dem på skärmen.

Kanske skulle en illustration på hög nivå hjälpa till:

I det här inlägget, the inlägg begär namninformation från Författare klass. Observera att i klassen ovan är klassnamnet i den första bloggen, attributen i det andra blocket, och sedan är de tomma tredje blocken vanligtvis reserverade för funktioner.

Men det är bortom, hm, omfattning av denna artikel.

Kom ihåg: Klasser representerar vanligtvis substantiv, attribut representerar adjektiv och funktioner representerar verb eller handling som objektet kan ta. För detta ändamål inkapslas klasserna normalt sin information på strategiska sätt så att på vilket sätt de jobbar hålls gömda och Vad de kan göra är demonstrerad av deras offentligt tillgängliga funktioner.

För att göra detta måste variabler och funktioner ges ett visst räckvidd som ger andra objekt tillgång till deras information. Dessa typer av objekt inkluderar objekt från tredje part som vill utnyttja data som representeras av en klass och en annan typ av objekt representerar ett objekt som ärver information från den klassen.

Arv är bortom vad vi kommer att täcka i den här artikeln; Vi kommer dock att täcka detta lite senare i serien för dem som är helt nya till objektorienterad programmering.

Så med det sagt är vi redo att ta en titt på ett praktiskt exempel på omfattning, inklusive hur vi har använt det hittills i serien och hur det påverkar designbeslut som går framåt.

Allt om offentliga, privata och skyddade

Primeren ovan borde ha förklarat, åtminstone en hög nivå, vilket omfattning är och hur det är viktigt, men om inte, kanske kommer följande avsnitt att.

Närmare bestämt ska vi titta på var och en av de typer av omfattning som variabler och funktioner kan ha, vi ska förklara vad varje betyder, och då kommer vi att förklara när du vill använda varje.

Innan vi går framåt, notera att offentlig, skyddad, och privat nyckelord kan användas för att omfatta båda attributen och funktioner. Det här är viktigt eftersom de regler som gäller attribut är också tillämpliga på funktioner.

Med det sagt, låt oss ta en titt på vart och ett av sökorden.

offentlig

Enkelt uttryckt, offentlig attribut och funktioner är tillgängliga för varje typ av objekt som försöker komma åt variabeln eller funktionen.

Till exempel:

first_name = $ name;  allmän funktion set_last_name ($ name) $ this-> last_name = $ name;  allmän funktion get_first_name () returnera $ this-> first_name;  allmän funktion get_last_name () returnera $ this-> last_name;  // Övriga klassuppgifter ...

Med den här inställningen kan något objekt som kräver en förekomst av det här objektet inte bara komma åt $ first_name och $ last_name attribut, men kan också Byta dem. På samma sätt kan varje objekt som kallar en förekomst av objekt få åtkomst till funktionerna för att hämta namnet och ändra namnet.

Så det ställer frågan: Vad är meningen med att ha dessa funktioner om attributet blir offentligt? Jag menar att det är överflödigt eller inte? Ja. Och vi kommer att svara på det senare i artikeln när vi pratar om privat nyckelord.

Skyddad

Nästa, skyddad attribut och funktioner är tillgängliga inom ramen för den klass där de definieras, men inte för objekt från tredje part. Som sagt, de kan kallas från sin egen klass, men inte från externa klasser.

first_name = $ name;  skyddad funktion set_last_name ($ name) $ this-> last_name = $ name;  skyddad funktion get_first_name () returnera $ this-> first_name;  skyddad funktion get_last_name () returnera $ this-> last_name;  // Övriga klassuppgifter ...

Men det finns ett undantag: underklasser. 

Låt oss till exempel säga att du definierar en klass som heter bidragsgivare vilket är en underklass av Författare, det betyder att bidragsgivare har tillgång till Allt av skyddad (och offentlig) attribut och funktioner i sin föräldraklass.

Med koden ovan betyder det att du kan ringa metoder som get_first_name () inifrån Författare klass eller inom bidragsgivare klass men inte från alla externa klasser.
Visst har underklasser mer att göra med arv vilket är något vi talar om mer senare i serien. Jag tar dock upp detta för att ge en viktig förtydligande mellan offentlig attribut och funktioner och privat attribut och funktioner.
Privat
kortfattat, privat attribut och funktioner låser attribut och funktioner i den klass där de definieras. Det betyder att inget externt objekt eller underklasser kan komma åt några av informationen.
Det är uppenbart att det här är den strängaste omfattningen, men det ska inte läsas som om det är en dålig sak (eller en bra sak). Istället är det meningen att det är möjligt att ge en viss information för att vara dold (eller abstraherad) inom ramen för den klass där den definieras.
Gå tillbaka till vårt första exempel, låt oss ta en titt på hur vi kan refactor klassen så att den ger maximal mängd verktyg för både externa klasser och underklasser.
first_name = $ name;  privat funktion set_last_name ($ name) $ this-> last_name = $ name;  privat funktion get_first_name () returnera $ this-> first_name;  privat funktion get_last_name () returnera $ this-> last_name;  // Övriga klassuppgifter ...
För det första visar detta exempel dålig användning av privat nyckelord. 
I det här exemplet är inte bara attributen otillgängliga, men funktionerna är inte heller åtkomliga. Med andra ord, för andra föremål i "omvärlden" verkar denna klass inte ha något tillgängligt. Ännu värre, inte ens underklasser kan komma åt någon av dessa uppgifter.
Kort sagt, koden är inte riktigt meningsfull.
Så, låt oss refactor detta lite men mer så att attributet förblir gömt (och därmed otillgängligt för tredje parts objekt), och vi anger ett sätt för tredje parts objekt att hämta namnen men kommer att endast tillåta den faktiska klassen och dess underklasser att ändra dem:
förnamn;  allmän funktion get_last_name () returnera $ this-> last_name;  // Övriga klassuppgifter ...
Det är förstås bara ett exempel. Självklart lämnar vi några av implementeringsdetaljerna så att vi inte gör det vet vad detaljer kan kräva, säg namn som ska uppdateras. 
Men det spelar ingen roll: Det här visar ett komplett exempel på hur privat, skyddad, och offentlig scoped aspekter av en klass kan fungera i samverkan med varandra för att ge en säker, strategisk väg att få tillgång till information.
Abstraktion och informationsglidning
Vad gäller räckvidd kan du göra argumentet att det hela kommer till abstraktion och information att dölja. 
Det vill säga att klasser (som är ritningar för objekt, om du kommer ihåg från våra tidigare artiklar) borde strategiskt organisera sin information så att:
 
information som borde endast vara tillgänglig och relevant för den bör förbli privat 
 
Information som ska vara tillgänglig för sig och dess underklasser bör skyddas
 
Information som ska vara tillgänglig för tredje parts objekt borde vara offentlig
 
Faktum är att jag går ett steg längre och säger att du inte kommer att se faktiskt många attribut märkta som offentlig. Istället är du mer sannolikt att se attributen markerade som skyddad - för delklassificering - eller privat, så att deras data kan hanteras av funktioner som är avsedda på lämpligt sätt. 
Ursprungligen låter det relativt enkelt, eller hur? Och begreppet i sig är inte särskilt komplicerat, men när det gäller byggsystem som bygger på ett antal olika objekt som alla arbetar tillsammans för att ge solid abstraktion, rena gränssnitt genom vilka tredjepartsklasser och underklasser kan interagera med det och effektiva sätt att organisera information, det kan bli mer utmanande - det finns många rörliga delar att överväga.
Med det sagt är detta ett av de saker som skriver kod, interagerar med andra utvecklare, och läsningskoden kan uppfostra upplevelsen. 
För vad det än är värt, är jag inte rädd för att erkänna att det fortfarande är strategier som jag inte kämpar för eftersom jag inte förstår koncepten, men för att försöka ge den renaste klassens genomförande som möjligt kan vara svårt, särskilt i ett system det kan ändras.
Men det är innehåll för ett annat inlägg.
Naturligtvis, om du har frågor eller kommentarer om något angående ämnesområdet, tveka inte att lämna dem i kommentarerna.
Vad kommer härnäst?
Från och med nästa artikel kommer vi att börja infoga en del av denna information till en praktisk tillämpning av att bygga ett WordPress-plugin.
Så för de av er som har väntat på att se hur denna serie fungerar tillsammans med WordPress, borde nästa artikel börja föra samman alla koncept som vi fortsätter serien med vårt eget WordPress-plugin med hjälp av begreppet objektorienterad programmering.



		
			
	   
	




Koda