Objektorientert programmering i WordPress Kontrollstrukturer I

For de av dere som har fulgt med serien så langt, vet du at vi tar en titt på objektorientert programmering spesielt fra perspektivet til en nybegynner.

Dette betyr at vi nærmer seg emnet, ikke bare for de som ser på hvordan man kommer i gang med paradigmet, men vi ser på alle de forskjellige funksjonene i PHP som utgjør språket, og som til slutt brukes innenfor sammenheng med objektorientert programmering.

I tillegg gjør vi alt dette i sammenheng med WordPress slik at vi ved slutten av serien ser hvordan en praktisk anvendelse av hvordan alt dette kan brukes i et ekte verdenseksempel.

Hvis dette er første gang du leser en artikkel i serien, anbefaler jeg på det sterkeste å sjekke ut de forrige artiklene, da hver artikkel i denne serien bygger på den før den.

Så langt har vi dekket følgende:

  1. En introduksjon
  2. klasser
  3. typer

I denne artikkelen skal vi snakke om kontrollstrukturer.

Hva er kontrollstrukturer?

"Kontrollstrukturer" er en fancy term term som beskriver hvordan vi kan, ahem, kontrollere hvordan koden flyter gjennom vårt program basert på en rekke faktorer.

For eksempel, la oss si at vi ønsker å utvikle seg gjennom et bestemt sett med instruksjoner, men du vil gjøre det noe hvis en variabel er satt, eller et annet sett med instruksjoner for en annen variabel er satt.

Eller la oss si at du har et sett med data som du vil løse gjennom å lese hver verdi, angi hver bestemt verdi, eller til og med lage bestemte verdier.

Uansett hva som er tilfelle, måten du går på å gjøre dette er gjennom bruk av kontrollstrukturer. I resten av denne artikkelen skal vi dekke to typer kontrollstrukturer: Conditionals og Loops.

Selv om conditionals og sløyfer er de typer kontrollstrukturer som vi skal gjennomgå, er det delsett av hver.

For eksempel har conditionals:

  • hvis da uttalelser
  • bryter / case uttalelser


Loops, derimot, har noen andre variasjoner:

  • til
  • for hver
  • gjøre
  • samtidig som

Selv om disse kan være nye konstruksjoner for noen av dere, har vi allerede dekket det grunnleggende i de forrige artiklene, så vi har alt vi trenger for å gå videre.

Betingede uttalelser

Etter min mening er betingede utsagn noen av de enkleste å forstå da de leser mer som setninger enn mange andre typer programmeringserklæringer. For eksempel, hvis du bokstavelig talt sier "om denne tilstanden er sant, så gjør denne handlingen, ellers gjør denne handlingen."

Jo, det blir en litt mer komplisert enn det hvis du har sagt noen andre forhold for å sjekke før du bestemmer deg for et tiltak, men det er fortsatt det samme.

Så med det sagt, la oss begynne med å ta en titt på en av de to variantene av conditionals som tilbys av PHP.

hvis da uttalelser

Som tidligere nevnt er det mest grunnleggende betingede utsagnet av skjemaet hvis / annet, og du ser vanligvis det skrevet som dette:

Selvfølgelig, dette forklarer ikke egentlig hvordan kontrollstrukturen fungerer, gjør det? Jeg mener, sikkert, det gir litt av et skjelett for hvordan du ser på det, men det gir mer å være ønsket.

Nemlig, hva er dette tilstand linje? For det andre, hva er handlingsplaner som kontrollstrukturen kan ta?

Først tilstand refererer til noen uttalelse som kan vurderes som et boolesk uttrykk. Gir mening? For å si det enkelt, tilstand representerer noen uttalelse som kan vurderes som ekte eller falsk.

Så, for eksempel, la oss si at vi har to verdier:

  1. $ is_active
  2. $ TOTAL_COUNT

Dette er åpenbart noe generiske verdier, men la oss si at hvis $ is_active er satt til ekte, så øker vi $ TOTAL_COUNT av en; Ellers trekker vi av $ TOTAL_COUNT av en. 

Slik ser det ut i kode:

I eksemplet ovenfor, $ TOTAL_COUNT vil bli økt med en fordi $ is_active vurderer til sann.

Alternativt, la oss si $ is_active er satt til falsk.

I dette eksempel, $ TOTAL_COUNT vil bli redusert med en fordi $ is_active vurderer til falsk.

Nå, før vi ser på det neste eksemplet, er det viktig å forstå at disse er ekstremt trivielle eksempler. Formålet med disse eksemplene er ikke å fremvise hvordan man tar komplekse operasjoner og å kombinere dem med de betingede konstruksjonene, men i stedet hvordan bruk de betingede konstruksjonene.

Når vi kommer til den delen av serien som har oss begynt å skrive et plugin, så vil du se hvordan vi kan bruke mer forseggjort uttrykk i en praktisk applikasjon.

Med det sagt, la oss se på enda flere eksempler på if / da uttalelser. I dette eksemplet tar vi en titt på hvis / elseif / else. For å komme i gang, må vi anta det $ is_active er satt til sant og $ TOTAL_COUNT er satt til 10.

= 10) $ total_count = $ total_count + 1 annet $ total_count = $ total_count - 1; 

Ovennevnte kode kan leses slik:

  • Hvis $ is_active er satt til sant, og sett deretter $ TOTAL_COUNT til en. $ is_active det er ikke sant.
  • Ellers, hvis $ TOTAL_COUNT er større enn eller lik 10, og deretter øke $ TOTAL_COUNT med 1. Den $ TOTAL_COUNT er lik 10, så vi vil øke $ TOTAL_COUNT til 11.
  • Hvis $ TOTAL_COUNT var ikke større enn eller lik 10, da ville vi redusere $ TOTAL_COUNT av en.

Når koden er ferdig, utføres i eksempelet ovenfor, $ TOTAL_COUNT vil være lik 11.

Gir mening? 

Det er derfor vi kaller disse kontrollstrukturer: Disse uttalelsene (eller evalueringer) tillater oss å bestemme hvilken kode som skal kjøres basert på visse forhold.

For de som har programmert for en stund, er du kjent med mer komplekse uttrykk ved hjelp av operatører som && og || og så videre. Vi får til slutt det, men ikke i denne artikkelen.

Alt som sier, det er et emne jeg er klar over, og det vil vi dekke, men ikke i dag.

Alt annet?

For de av dere som er mer erfarne med programmering, er du sannsynligvis kjent med den ternære operatøren.

Vi kommer ikke til å ta en titt på det i denne spesielle serien av artikler som det er utenfor omfanget av det vi ønsker å dekke; Men hvis du føler deg eventyrlystne og leter etter en mer konsis måte å skrive en enkel på hvis / annet uttalelser, så sjekk den ternære operatøren i PHP manualen.

bryter / case uttalelser

Med det sagt er det en annen type betinget at vi må ta en titt på før du går videre til neste emne.

Denne spesielle konstruksjonen faller fortsatt under betingede uttalelser; Jeg vil imidlertid hevde at du ville se det brukt sjeldnere enn det hvis / annet motstykke.

Som tittelen angir, kalles dette bryter / case uttalelse. Selv om jeg personlig tror at språket gjør det litt mer innviklet å følge, er måten kontrollen flyter gjennom evalueringen ikke mye forskjellig fra det vi allerede har sett.

Som vi gjorde med hvis / annet uttalelser, la oss først se på hvordan bryter / case er strukturert og så tar vi en titt på et par trivielle eksempler.

Den første tingen å merke seg om denne spesielle typen betinget er at evalueringen skjer på et enkelt sted: øverst i koden av koden rett ved siden av bytte om uttalelse.

Her skjer evalueringen en gang da hver av de påfølgende sak uttalelser er hva som dikterer hvilken handling som er tatt. Det er også en gå i stykker uttalelse som følger med hvert av de uttalelsene vi skal diskutere, og det er også en misligholde blokk med kode nederst som vi vil diskutere i slutten av artikkelen, også.

Men før vi gjør noe av det, la oss sette opp et litt mer praktisk eksempel på hva en grunnleggende bryter / case uttalelsen ser ut som.

La oss anta at vi har en verdi, $ FIRST_NAME, og da ønsker vi å ta et bestemt handlingsarbeid basert på personens fornavn. I dette eksemplet vil vi angi en persons e-postadresse basert på deres fornavn. Hvis vi ikke gjenkjenner personens fornavn, så setter vi verdien tilsvarer null.

Jo, det er litt av et godt eksempel, men det vil vise poenget:

La oss se på strømmen av kontroll i eksempelet ovenfor:

  • Vi definerer a $ persons_name som 'Tom' og vi initialiserer $ EMAIL_ADDRESS som en tom streng.
  • Vi passerer da $ persons_name til bryteretningen for evaluering.
  • Kontrollstrukturen vil evaluere $ persons_name mot hver verdi som er angitt i saksoppstillingen.
  • Siden 'Tom' er verdien av $ persons_name, og så $ EMAIL_ADDRESS vil bli satt til '[email protected]'

Hvis vi skulle passere 'David' som $ persons_name deretter $ EMAIL_ADDRESS ville bli satt til '[email protected]'.

Neste, hvis vi skulle passere noen annet navn enn 'Tom' eller 'David', deretter $ EMAIL_ADDRESS ville bli satt til NULL. Det er også viktig å merke seg det bryter / case er saksfølsom. Dette betyr at hvis du skulle passere 'tom' istedenfor 'Tom', så ville de bli behandlet som forskjellige tilfeller.

Til slutt merk at hver sak slutter med a gå i stykker uttalelse. Dette er viktig fordi gå i stykker instruerer koden til å hoppe ut av bryter / case uttalelse og fortsett å jobbe med hvilken kode som kommer neste gang.

Det er ekstremt viktig å forstå at hvis du glemmer en pauseoppgave, vil den umiddelbart falle ned til neste case statement som åpenbart kan ha uberegnelige resultater (for eksempel å sette feil $ EMAIL_ADDRESS).

Et eksempel på hvor du kan utnytte dette til din fordel er slik:

I eksemplet ovenfor har vi definert saker for begge 'Tom' når det er små bokstaver eller har første bokstav aktivert og demonstrerer hvordan koden kommer til å gå gjennom til neste sak uttalelse.

Men det er en enda bedre måte å gjøre dette mer bulletproof:

Legg merke til at dette tar PHP-funksjonen strtolower for å tvinge innkommende $ persons_name å være helt nedre. Dette gjør at vi kan finjustere våre saksoppgaver enda mer.

Hva skjer neste gang?

I denne artikkelen så vi på den første av to grupper av kontrollstrukturer som er tilgjengelige for oss i PHP. Nei, dette er ikke eksplisitt del av objektorientert programmering, men før vi faktisk snakker om flere grunnleggende aspekter av paradigmet, må vi forstå alle de finere punktene som tillater oss å skrive objektorientert kode.

Til dette formål skal vi fortsette denne diskusjonen om kontrollstrukturer i neste artikkel ved å se på looper. 

Deretter vil vi være klare til å gjøre oppmerksomheten vår oppmerksom på funksjoner. For de som er kjent med prosedyrisk programmering, er funksjonene ikke noe nytt; Men hvis du er ny til objektorientert programmering, så er det en rekke faktorer som skiller dem fra hvordan de brukes i prosessorprogrammering.

Så det er køreplanen for neste sett med artikler. Som vanlig er tilbakemeldingen alltid velkommen, og jeg gleder meg til å fortsette vår diskusjon i neste artikkel.