Share
Som beskrevet i første innlegg i denne serien nærmer vi oss begrepet objektorientert programmering innenfor WordPress, og det gjør vi for veldig nybegynner.
Det betyr at hvis du aldri har hørt om OOP, om du har vært nysgjerrig på å lære det, og du er noen som er interessert i WordPress og lærer å utvikle løsninger på toppen av det, så er denne serien for deg.
Over det neste settet av artikler skal vi dekke alle de store aspektene ved objektorientert programmering. Når vi gjør det, skal vi se på hvordan vi kan bruke det vi har lært ved å bygge en arbeidsløsning for WordPress.
Men først må vi begynne med det grunnleggende.
Hvis du skulle spørre 10 forskjellige utviklere for deres definisjon av en klasse, vil du sannsynligvis få mange lignende svar, men få av dem var faktisk det samme. Faktisk, den som jeg hørte gjentatt mest ofte da jeg var yngre, gikk slik:
En klasse er en tegning for å skape et objekt.
I teorien høres det bra ut spesielt hvis du vet hva et objekt er. Men det er problemet, ikke sant? Vi prøver å lære om objektorientert programmering, så det er ingen garanti for at vi selv vet hva et objekt er; Derfor, hvordan kan vi forstå at en klasse tjener som et blåkopi for det?
På en måte ber det spørsmålet.
Så la oss sikkerhetskopiere noen få trinn og definere hva et objekt er for å tydeligere definere hva en klasse er.
Hele ideen om det objektorienterte programmeringsparadigmet er at vi som programmerere lettere kan modellere informasjonen vi ser i den virkelige verden ved hjelp av konstruksjoner i en kode.
For eksempel i den virkelige verden har vi objekter som kan beskrives ved hjelp av adjektiver, og disse objektene kan utføre handlinger. Selv om dette kan være litt kliché, tenk et øyeblikk om en bil:
Igjen, et enkelt eksempel, men det viser seg at alt som vi har i den virkelige verden, vanligvis kan reduseres til et substantiv som kan beskrives av dets adjektiver og handlingene det utfører.
Så la oss generalisere denne ideen til objekter. Faktisk, la oss erstatte ett ord for en annen:
Enkelt nok, ikke sant? Kort sagt er det at vi skal kunne beskrive de tingene vi ser i den virkelige verden som gjenstander innenfor et programmeringsparadigm. Vær oppmerksom på at enkelte språk kaller attributter egenskaper, og noen anropsmetoder fungerer. Det spiller ingen rolle heller, det er alt det samme. De henviser bare til adjektiver om objektet og handlinger som det kan ta, henholdsvis.
Neste, de fleste programmeringskurs eller bøker alltid begynn med et eksempel på hvordan objekter er ment å modellere ekte verdensobjekter (likt som jeg gjorde med bileksemplet ovenfor).
Og til en viss grad er det sannhet til det. For de som ha har jobbet i utvikling, så er du sannsynligvis kjent med hvordan vi kan modellere mennesker innenfor rammen av vår søknad, men det går foran oss selv.
Selv om det er sant at vi kan bruke objektorientert programmering til å modellere ekte verdensobjekter, har jeg funnet ut at, oftere ikke, jeg modellerer en mer generalisert form for et ekte verdensobjekt - for eksempel en bruker snarere enn a person - og at handlingene de utfører er mer unike for dem.
Til det formål vil eksemplene jeg vil gi gjennom denne artikkelen og de i resten denne serien være mer rettet mot praktiske anvendelser i dataprogrammering. Ingen skal skrive en bilplugin, og ingen skal skape et dyrobjekt (noe som du ofte også ser og hører i introduksjonsprogrammeringskursene).
I stedet skal vi prøve å fokusere litt mer på objekter som er mer sannsynlig å bli sett i programmeringsområdet - ikke i den virkelige verden. Ikke fordi objektorientert programmering er svak, men fordi måten vi går på å lære er svak.
Selvfølgelig reiser det spørsmålet om hva som er et godt eksempel? Problemet med å svare på et spørsmål som dette er at det bokstavelig talt kan være et bredt spekter av ting.
Dette inkluderer objekter som:
Og du ser: Mange av disse tingene finnes egentlig ikke i den virkelige verden. For eksempel er blogginnlegg ikke håndgribelig. Det er ting vi leser på våre skjermer. Men betyr det at de ikke har egenskaper som en dato, en tid og en forfatter? Eller betyr det at de ikke har handlinger som publisere og slette?
Selvfølgelig ikke.
Så når vi utvikler seg gjennom denne serien, skal vi snakke om objekt når det gjelder de tingene vi har større sannsynlighet for å jobbe med.
Jeg ser ikke oss programmering av et dyr - og absolutt ikke så i WordPress - når som helst i løpet av denne serien :).
Ok, nå som vi har tatt en kort nedbrytning inn i hva Objekter er faktisk, og gode og dårlige eksempler på hver, det er på tide å faktisk begynne å snakke om klasser og hvordan de virkelig fungerer som tegninger for objekter.
Ved programmering opprettes et objekt fra en klasse. Det betyr at en klasse definerer alle egenskapene en objekt har og handlingene det kan ta, og da vil datamaskinen opprette et objekt i minnet.
Når det gjelder klasser, kan du høre utviklere diskutere skriveklasser, definere klasser eller bygge klasser. Alle disse vilkårene er akseptable.
Etter det kan du høre utviklere snakke om å lage objekter. Handlingen med å skape et objekt kalles instantiation. Ja - det er et stort ord for et relativt enkelt konsept. Men tenk på det på denne måten: Når du har en klasse, har du en definisjon der du kan opprette flere forekomster av et objekt.
Hvis vi trenger å tegne en analogi til den virkelige verden, tenk først om et sett med tegninger for et hus. Det legger grunnplan, dimensjoner, vegger og så videre som gir byggearbeidere informasjon om hvordan man skal bygge et hus. Da, når det kommer tid til å faktisk bygge et hus, da bygger et team av byggearbeidere huset på bakgrunn av tegningen.
Slik er tilfellet med klasser, instantiering og objekter. Klasser er tegningene, datamaskinen er laget av byggearbeidere, og gjenstandene er huset. Og akkurat som flere hus kan oppføres fra en enkeltblåkopi, er det slik med objekter og klasser.
Når det kommer til å skrive kode, kan noen mennesker vise bildet i hodet - andre, kanskje ikke.
Personlig tror jeg at dette har mer å gjøre med hvordan hver enkelt av oss har en tendens til å lære og behandle informasjon, men jeg tror at det er mulig å begynne å forstå hvordan programvare systemer samarbeider jo lenger du skriver kode.
Her skal vi ikke se på noe komplekst system; derimot, er skal ta en titt på et eksempel på en klasse og deretter en visuell fremstilling av hva som kan se ut når det gjelder kode og når det gjelder et mentalt bilde.
Siden vi har å gjøre med WordPress, vil kanskje et første eksempel på en klasse være en som representerer et blogginnlegg.
Gitt, dette vil være et enkelt eksempel for å demonstrere ideer om attributter og funksjoner, men vi vil dekke ulike konstruksjoner i flere detaljer i fremtidige artikler.
Så, med det sagt, la oss si at vi skal lage en klasse for et blogginnlegg. La oss også si at vårt blogginnlegg vil ha en forfatter, en dato hvor den ble publisert, uansett om den er publisert, og handlingene som skal publiseres og slettes.
Et eksempel på klassenavn for et blogginnlegg med disse attributter og funksjoner vil se slik ut:
klasse Blog_Post privat $ forfatter; privat $ publish_date; privat $ er_publisert; offentlig funksjon publisering () // Publiser artikkelen her offentlig funksjon slette () // Slett artikkelen her
For de som er kjent med objektorientert programmering, kan du gjenkjenne noe av informasjonen ovenfor, og du kan også forstå at jeg har utelatt bestemte ting (som konstruktøren). Ikke bekymre deg for det - vi vil dekke disse konseptene senere.
For de som er helt nye for programmering, ser dette ut som en grunnleggende klassetekst. For øyeblikket, ikke bekymre deg for ordene privat og offentlig som vi dekker de senere.
I stedet fokusere på $ forfatter, $ PUBLISH_DATE, og $ is_published. Dette er attributter. Legg merke til at de sitter over funksjondefinisjonene i klassen. Disse er analoge med adjektiver som beskriver Blogg innlegg.
Deretter har vi funksjonene publisere() og delete (). Disse to funksjonene er handlingene som kan tas på de Blogg innlegg. Husk, bare hvordan objekter i den virkelige verden kan bevege seg (som en bil kan kjøre), kan et blogginnlegg bli publisert.
Så hva skjer når du faktisk instanser et blogginnlegg? Det vil si når vi lager et blogginnlegg i kode, hvordan kan vi mentalt bilde hva som skjer i datamaskinen.
Først, la oss skissere hvordan et blogginnlegg er instantiated. Husk, instantiated er et ord akkurat som oppført er for byggearbeidere - det er hvordan et objekt er opprettet fra en klasse.
La oss se hvordan vi kan bruke den enkle klassedisplayen til å lage tre forskjellige blogginnlegg:
$ first_post = ny Blog_Post (); $ second_post = ny Blog_Post ();
Lett nok å lese, ikke sant? Ovenfor har vi opprettet to variabler som refererer til to helt forskjellige Blogg innlegg objekter.
Vær oppmerksom på at selv om vi snakker om dette mer i en fremtidig artikkel, er ordet ny er det som instruerer datamaskinen til å instantiere en Blogg innlegg fra oss fra klassen definisjonen.
Så la oss ta en titt på det første eksemplet hvor vi får vår første forekomst av Blogg innlegg.
Legg merke til i denne illustrasjonen, har vi $ first_post variabel som refererer til forekomsten av Blogg innlegg det ble opprettet. De Blogg innlegg finnes i datamaskinens minne, den har sine attributter som er tilgjengelige, samt de tilgjengelige metodene.
Vi kan få tilgang til alle disse gjennom $ first_post variabel som refererer til dette objektet. Vi snakker om det mer detaljert senere i serien.
Men hva med $ second_post? Hvordan gjør at se innenfor sammenheng med objektorientert programmering?
Hvis du sammenligner de to illustrasjonene, ser de ganske mye ut, akkurat? $ first_post refererer til en forekomst av Blogg innlegg, $ second_post refererer til en andre forekomst av Blogg innlegg selv om de både kom fra en enkelt klasse.
Legg merke til at for de som er teknisk stygt, det er mulig for begge variablene å referere til en enkelt forekomst, men det er utenfor rammen av denne artikkelen.
Uansett, på dette tidspunktet bør du ha en høy forståelse av hva en klasse er, hvilken rolle den spiller i objektorientert programmering, og hvordan vi kan lage forekomster av objekter som er tilgjengelige gjennom variabler.
Dette viser fortsatt oss ikke hvordan vi skal samhandle med klassene skjønt, gjør det? Vi kommer til det, men først må vi diskutere noen av de mer primitive aspektene av programmering som strenger, arrayer, looper og conditionals.
Hver av de nevnte konstruksjonene vil hjelpe oss med å gi liv til våre gjenstander, og når vi har tatt en tur til hver av dem, kommer vi tilbake for å gjøre mer modne klasser som faktisk kan fungere.
Accentsconagua