Objektorientert programmering i WordPress Omfang

Ved å fortsette vår diskusjon av objektorientert programmering i WordPress, må vi begynne å snakke om ideen om omfang. Kort sagt, dette refererer til ideen om at klasser kan kontrollere hvordan deres attributter og funksjoner er tilgjengelige (eller om de selv kan nås).

Dette er enda en kjerneidee av objektorientert programmering, hvorefter vi skal være i god form for å begynne å jobbe med en faktisk WordPress-plugin.

Før du går videre, vær oppmerksom på at hver artikkel i denne serien bygger på den før den, så hvis du bare blir med oss, vær så snill å sjekke ut de forrige artiklene i serien:

1. En introduksjon
2. klasser
3. typer
4. Kontrollstrukturer: betingede uttalelser
5. Kontrollstrukturer: Looper
6. Funksjoner og attributter

Når du er helt opptatt, la vi fortsette vår diskusjon om det siste stykket av paradigmet som er nødvendig for oss å forstå før vi går inn i praktisk anvendelse av objektorientert programmering innen WordPress.

Definere omfang

Ifølge Wikipedia er den første definisjonen av omfang som følger:

I dataprogrammering er omfanget av et navn som er bindende - en forening av et navn til en enhet, som en variabel - den delen av et dataprogram hvor bindingen er gyldig: hvor navnet kan brukes til å referere til enheten. I andre deler av programmet kan navnet referere til en annen enhet (det kan ha en annen binding), eller til ingenting i det hele tatt (det kan være ubundet).

Med mindre du er en erfaren programmerer, er dette litt forvirrende, ikke sant? Faktisk kan det til og med lese som en jargong.

Men det er greit fordi formålet med denne artikkelen er å gi en arbeidsdefinisjon av omfanget, samt noen praktiske eksempler på hvordan det ser ut i forbindelse med et program.

Så før vi ser på de tre ulike aspektene av omfanget i objektorientert programmering, la oss formulere en renere definisjon. 

Kort sagt, refererer omfanget til hvordan variabler og funksjoner kan være tilgang fra tredjepartsobjekter eller barnobjekter innenfor programmet. 

For eksempel, si at du har en Blogg innlegg objekt og en Forfatter gjenstand. La oss da si at forfatteren har attributter for fornavn og etternavn og Blogg innlegg ønsker å få tilgang til dem for å si, vise dem på skjermen.

Kanskje et høyt nivå illustrasjon ville hjelpe:

I dette innlegget, den Blogg innlegg Be om navninformasjon fra Forfatter klasse. Legg merke til at i diagrammet ovenfor er klassenavnet i den første bloggen, attributter i den andre blokken, og deretter er de tomme tredje blokkene vanligvis reservert for funksjoner.

Men det er utenfor, ahem, omfanget av denne artikkelen.

Husk: Klasser representerer vanligvis substantiver, attributter representerer adjektiver, og funksjoner representerer verb eller handling som objektet kan ta. For det formål innlemmer klassene vanligvis sin informasjon på strategiske måter slik at hvordan de arbeider blir skjult og hva de kan gjøre er demonstrert av deres allment tilgjengelige funksjoner.

For å gjøre dette må variabler og funksjoner gis et visst omfang som gir andre objekter tilgang til informasjonen. Denne typen objekter inkluderer tredjepartsobjekter som vil utnytte dataene representert av en klasse, og en annen type objekt representerer en gjenstand som arver informasjon fra denne klassen.

Arv er utover det vi skal dekke i denne spesielle artikkelen; Vi vil imidlertid dekke dette litt senere i serien for de som er helt nye til objektorientert programmering.

Så med det sagt, er vi klar til å se på et praktisk eksempel på omfang, inkludert hvordan vi har brukt det så langt i serien og hvordan det påvirker designbeslutninger fremover.

Alt om offentlig, privat og beskyttet

Primeren ovenfor burde ha forklart, minst et høyt nivå, hvilket omfang er og hvordan det betyr noe, men hvis ikke, så vil kanskje de følgende avsnittene.

Nærmere bestemt skal vi ta en titt på hver av de typer omfang som variabler og funksjoner kan ha, vi skal forklare hva hver enkelt betyr, og da skal vi forklare når du vil bruke hver av dem.

Før vi går videre, merk at offentlig, beskyttet, og privat søkeord kan brukes til å omfatte begge attributter og funksjoner. Dette betyr at reglene som gjelder for attributter, også gjelder for funksjoner.

Med det sagt, la oss ta en titt på hvert av søkeordene.

Offentlig

For å si det enkelt, offentlig Attributter og funksjoner er tilgjengelige for hver type objekt som forsøker å få tilgang til variabelen eller funksjonen.

For eksempel:

first_name = $ name;  offentlig funksjon set_last_name ($ navn) $ this-> last_name = $ name;  offentlig funksjon get_first_name () return $ this-> first_name;  offentlig funksjon get_last_name () return $ this-> last_name;  // Andre klassedetaljer ...

Gitt dette oppsettet kan ethvert objekt som kaller en forekomst av dette objektet ikke bare få tilgang til $ FIRST_NAME og $ last_name attributter, men kan også endring dem. På samme måte kan ethvert objekt som kaller en forekomst av objekt, få tilgang til funksjonene for å hente navnet og endre navnet.

Så det reiser spørsmålet: Hva er poenget med å ha disse funksjonene hvis attributtet blir offentliggjort? Jeg mener, det er overflødig, ikke sant? Ja. Og vi vil svare det senere i artikkelen når vi snakker om privat søkeord.

beskyttet

neste, beskyttet Attributter og funksjoner er tilgjengelige i sammenheng med klassen de er definert i, men ikke for tredjepartsobjekter. Når det er sagt, de kan kalles fra sin egen klasse, men ikke fra eksterne klasser.

first_name = $ name;  beskyttet funksjon set_last_name ($ navn) $ this-> last_name = $ name;  beskyttet funksjon get_first_name () return $ this-> first_name;  beskyttet funksjon get_last_name () return $ this-> last_name;  // Andre klassedetaljer ...

Men det er et unntak: underklasser. 

For eksempel, la oss si at du definerer en klasse som heter Senior som er en underklasse av Forfatter, dette betyr at Senior har tilgang til alle av beskyttet (og offentlig) Attributter og funksjoner i sin overordnede klasse.

Gitt koden ovenfor betyr dette at du kan ringe metoder som get_first_name () fra innsiden av Forfatter klasse eller innenfor Senior klasse men ikke fra noen eksterne klasser.
Klart har underklasser mer å gjøre med arv, noe som vi snakker om mer senere i serien; Jeg tar imidlertid opp dette for å gi en viktig avklaring mellom offentlig attributter og funksjoner og privat attributter og funksjoner.
Privat
kort oppsummert, privat attributter og funksjoner låser attributter og funksjoner inn i klassen de er definert i. Dette betyr at ingen eksterne objekter eller underklasser kan få tilgang noen av informasjonen.
Klart er dette den strengeste formen for omfang, men det skal ikke leses som om det er en dårlig ting (eller en god ting). I stedet er det ment å gi en måte at visse opplysninger blir skjulte (eller abstraherte) innenfor konteksten til klassen der den er definert.
Gå tilbake til vårt første eksempel, la oss ta en titt på hvordan vi kan refactor klassen slik at den gir maksimalt antall verktøy for både eksterne klasser og underklasser.
first_name = $ name;  privat funksjon set_last_name ($ navn) $ this-> last_name = $ name;  privat funksjon get_first_name () return $ this-> first_name;  privat funksjon get_last_name () return $ this-> last_name;  // Andre klassedetaljer ...
Først viser dette eksemplet dårlig bruk av privat søkeord. 
I dette eksemplet er ikke bare attributter utilgjengelige, men funksjonene er heller ikke tilgjengelige. Med andre ord, til andre objekter i "verden utenfor", synes denne klassen å ha ingenting tilgjengelig. Enda verre, ikke engang underklasser kan få tilgang til noen av disse opplysningene.
Kort sagt, koden er ikke veldig fornuftig.
Så la oss reflektere dette litt, men mer slik at attributtet forblir skjult (og dermed utilgjengelig for tredjepartsobjekt), og vi vil spesifisere en måte for tredjepartsobjekter å hente navnene på, men vil bare la den faktiske klassen og dens underklasser endre dem:
fornavn;  offentlig funksjon get_last_name () return $ this-> last_name;  // Andre klassedetaljer ...
Selvfølgelig er dette bare et eksempel. Åpenbart forlater vi noen av implementeringsdetaljer slik at vi ikke gjør det vet hva detaljer kan ringe for, si, navnene som skal oppdateres. 
Men det spiller ingen rolle: Dette viser et komplett eksempel på hvordan privat, beskyttet, og offentlig Scoped aspekter av en klasse kan fungere sammen med hverandre for å gi en sikker, strategisk måte å få tilgang til informasjon.
Abstraksjon og Informasjon Skjul
Når det gjelder omfanget, kan du argumentere for at det hele kommer ned til abstraksjon og skjule informasjon. 
Det vil si at klasser (som er tegninger for objekt, hvis du husker fra våre tidligere artikler) bør organisere deres informasjon strategisk slik at:
 
informasjon som skal bare være tilgjengelig og relevant for den skal forbli privat 
 
Informasjon som skal være tilgjengelig for seg selv og dens undergrupper bør beskyttes
 
Informasjon som skal være tilgjengelig for tredjepartsobjekter, bør være offentlig
 
Faktisk vil jeg gå et skritt videre og si at du ikke sannsynligvis vil se mange attributter merket som offentlig. I stedet er du mer sannsynlig å se attributter merket som beskyttet - for underklassifisering - eller privat, slik at deres data kan styres av funksjoner som er scoped hensiktsmessig. 
I utgangspunktet høres dette relativt enkelt, ikke sant? Og selve konseptet er ikke veldig komplisert, men når det gjelder bygningssystemer som stole på en rekke forskjellige objekter, jobber de sammen for å gi solid abstraksjon, rene grensesnitt som tredjeparts klasser og underklasser kan samhandle med og effektive måter å organisere informasjon, kan det bli mer utfordrende - det er mange bevegelige deler å vurdere.
Med det sagt, dette er en av de tingene som skriver kode, samhandler med andre utviklere, og lesingskoden kan avlede opplevelsen. 
For hva det er verdt, er jeg ikke redd for å innrømme at disse fremdeles er strategier som jeg ikke sliter med, fordi jeg ikke forstår konseptene, men fordi det er vanskelig å forsøke å gi den reneste klassen implementeringen mulig, spesielt i et system det er skikkelig å forandre seg.
Men det er innhold for et annet innlegg.
Selvfølgelig, hvis du har spørsmål eller kommentarer om noe angående temaet om omfang, ikke nøl med å legge dem i kommentarene.
Hva blir det neste?
Fra den neste artikkelen skal vi begynne å inkorporere noe av denne informasjonen i en praktisk applikasjon for å bygge et WordPress-plugin.
Så for de av dere som har ventet på å se hvordan denne serien fungerer sammen med WordPress, bør neste artikkel begynne å bringe alle konseptene sammen når vi fortsetter serien med vårt eget WordPress-plugin ved hjelp av begrepet objektorientert programmering.



		
			
	   
	




Kode