Share
Velkommen til del to av denne innledende serien om Objective-C. Etter å ha tilbrakt forrige uke gjennomgå grunnleggende av C-språket som Objective-C er bygget på, vil denne uka overgå til å fokusere på hva som gjør Objective-C til et så godt språk for programvareutvikling. Spesielt vil vi diskutere grunnleggende for Objektorientert Programmering (OOP) og demonstrere hvordan du oppretter en klasse og sender meldinger til objekter i Objective-C.
Hvorfor har vi Objective-C? Hvorfor ikke bare bruke det underliggende C-språket? Grunnen til at vi har Objective-C er å gi oss en objektorientert lekeplass der vi skal bygge våre applikasjoner. OOP er et programmeringsparadigm som forsøker å tillate utviklere å tenke på programvareutforming når det gjelder objekter og attributter i stedet for variabler og funksjoner. Spesielt forsøker OOP å oppnå dataabstraksjon, innkapsling, modularitet, polymorfisme og arv. Emnet for OOP kan enkelt fylle en bok (eller en opplæringsserie) på egenhånd, så i stedet vil jeg introdusere deg til de grunnleggende prinsippene som eksempel.
Tenk deg at du har en bil. Du kan tenke på bilen din som et objekt. Det er mange andre biler i verden, og du kan til og med eie mer enn en. Bilen har forskjellige egenskaper til det: lage, modell, farge, motor type, og mange flere. I Objektorienterte Programmeringsbetingelser vil vi kalle abstrakt begrepet en bil en "klasse" og den individuelle bilen som du eier et objekt eller eksempel (instantiated objekt) av klassen. Når en ny bil er produsert, blir en ny forekomst av bilklassen instantiated (eller opprettet) og gitt sitt eget sett med egenskaper.
Fortsatt litt uklar? En annen flott analogi er den av cookien og cookie cutteren. Klassen er cookie cutter, og objektet er informasjonskapsel.
Så, hvorfor tenk når det gjelder gjenstander? En av de beste grunnene er fordi dette er hvordan hjernen din naturlig konseptualiserer livet i den virkelige verden, og det er mange fordeler med å kunne abstrahere programvareutvikling i lignende termer.
Klasser (og dermed objekter) består av metoder og attributter. Hvis du kommer fra et annet programmeringsspråk, kan du være mer kjent likestillingsmetoder med funksjoner og attributter med variabler. Vi vil diskutere hver for seg neste.
Så vi har en "forekomst" av en bil, nå som hva gjør vi med det? Vel, vi kjører den og fyller den blant annet med bensin. Kjøring og fylling med bensin gjelder bare for bilene vi bruker, noe som betyr at når vi fyller opp en bil eller kjører bil, påvirker vi bare en forekomst, og ikke alle bilene i verden. Derfor fylles bileksemplaret som en eksempelmetode. Det er noe vi gjør med vår forekomst og bare vår forekomst.
På den annen side, hvis vi spør den opprinnelige bilklassen hvor mange bilfarger som er tilgjengelige, er dette en klassemetode fordi vi ikke lenger snakker om bilen vi kjører rundt, men alle biler generelt.
Mange av disse prinsippene blir tydeligere med bruk, så la oss se på en liten bit av syntaks.
I Mål-C kaller vi objektmetoder ved å sende meldinger. Når vi vil vite hvor mye gass som er i bilens tilfelle, sender vi en melding til forekomsten vår, og meldingen er metoden vi vil bruke. Programmalt ser det slik ut:
[mottakermelding];
Braketten indikerer at vi sender en melding. Den første parameteren er hvem som skal motta denne meldingen, og den andre parameteren er hva meldingen egentlig er. Til slutt slutter vi med et semikolon som er vanlig for de fleste programmeringsspråk.
Så, med vårt tidligere eksempel i tankene, er det slik at vi ville samhandle med vår forekomst av bil for å legge til gass i tanken;
[DansCar addGas];
Eksempelet ovenfor antar at vi har instansiert en forekomst av bilklassen og kalt den "dansCar." Vi sender så "addGas" -meldingen til objektet "dansCar", som svarer til å kalle en funksjon. På et annet språk kan denne linjen se ut som:
dansCar.addGas ();
La oss si at vår bilklasse har en bensintank som er lagret som en prosentandel. For eksempel, hvis bensintanken er på 50%, er den halvfull og hvis den er 100%, betyr den at den er full mot randen. Nå, hvis vi vil vite hvor mye gass er i tanken, tar vi ikke bare direkte den informasjonen fra et attributt. I stedet vil vi bruke en tilgangsmetode for å få tilgang til den interne variabelen for oss. På samme måte, når vi vil fylle tanken, gir vi ikke bare bensintanken en ny prosentandel, vi bruker en setter til å oppdatere attributten for oss. Denne prosessen er kjent som datainnkapsling.
Hva vi mener ved datainnkapsling er at data er inneholdt (så å si) ved metoder som betyr å få tilgang til det, må vi bruke metoder. Noen av dere som har programmert på andre språk og ikke har hørt om datainnkapsling, kan lure på hvorfor vi gjør ting på denne måten. Svaret er at ved å inkapslere data er det en fin pute mellom utvikleren av en klasse og brukeren av en klasse. Fordi klassemetoder styrer og opprettholder attributter i klassen, kan de lettere opprettholde dataintegritet. En annen stor fordel er at når en utvikler distribuerer sin klasse, trenger de som bruker det ikke å bekymre seg for internene i klassen i det hele tatt. En utvikler kan oppdatere en metode for å gjøre det raskere eller mer effektivt, men denne oppdateringen er gjennomsiktig for brukeren av klassen fordi han / hun fortsatt bruker samme metode uten endring i hans / hennes kode.
Dette bringer oss pent videre til neste avsnitt vi skal se på, som er hvordan Objective-C skiller grensesnitt fra implementering.
Når du oppretter eller arbeider med en enkel klasse i Objective-C, ser du at den som standard har to filer. En er implementeringsfilen som er en fil som slutter med et suffiks av .m og grensesnittfilen som er en fil som slutter med et suffiks av .h.
#importere@interface Bil: NSObject // Dette er hvor attributter går float fillLevel; // Dette er hvor metodene går - (void) addGas; @slutt
Først og fremst importerer vi Cocoa.h som er et standardbibliotek med mye gjenbrukbar kode som vi kan bruke i vår app.
Deretter erklærer vi at dette er grensesnittet for bilen, men vi legger også NSObject inn i den erklæringen. Legge til ": NSObject" betyr at bilklassen arver fra NSObject-klassen. Vi snakker mer om arv i en fremtidig opplæring.
Vår instansvariabel "fillLevel" er deklarert neste, og vi angir at den er av "float" datatypen, slik at vi enkelt kan representere en prosentandel.
Neste linje erklærer vår "addGas" -metode. "-" indikerer at dette er en instansmetode, ikke en klassemetode. "(Void)" -delen betyr at metoden ikke vil returnere noe tilbake når det er ferdig med å kjøre. Hvis klassen skulle returnere et heltall, ville dette bli endret til "(int)" og det samme for enhver annen datatype. Endelig avsluttes metoden deklarasjonen med en semikolon.
#import "Car.h" @implementation Car - (void) addGas // kode går her for å legge til gass @end
Implementeringen i dette tilfellet inneholder metoden for å legge til gass i tanken. Vi importerer også Car.h, som er grensesnittfilen. Hvor vår addGas-metode sitter, kan vi legge til mange flere metoder, men dagens omfang er å bare få deg til å forstå hvordan klasser fungerer i stedet for å lage en fullverdig klasse.
Neste gang ser vi nærmere på metoder og ved å bruke variabler med metoder (samt grunnleggende for å administrere variabler i Objective-C). Denne opplæringen var ikke så lang som det ofte er litt forvirrende for nye utviklere om hvorfor vi deler klasser inn i mer enn én fil. Hvis du føler deg forvirret, vær så snill å lese om det ovenfor, eller still spørsmål i kommentarfeltet nedenfor. Klasser vil bli en konstant gjenkonkurranse i denne serien, og det er viktig at du forstår hvordan de fungerer.
Å se at denne delen av serien var ganske teoretisk, det er ikke for mye du kan gjøre for å øve. Imidlertid anbefaler jeg denne uken at du registrerer deg for Apples utviklerwebside, da det er en uvurderlig referanse. Når du har gjort det, ta en snoop rundt noen av sine nedlastbare klasser og last ned noen enkle. Du trenger ikke å forstå all koden, bare se på hvordan klassene blir dannet og skilt over filer.
Accentsconagua