Lær objektiv-C Dag 3

Velkommen til del tre av denne serien -Jeg håper du nyter det! I forrige uke så vi på hvordan vi separerer klasser i å skille filer (grensesnitt og implementering), denne uken skal vi se på klasser igjen, men litt mer i dybden. Vi vil også ta en topp i arv og hvordan det fungerer, sammen med variabelt omfang.

Så langt har vi hatt noen gode tilbakemeldinger via e-post, twitter og kommentarer. Det er flott å se så mange mennesker er interessert i dette emnet, og det er enda bedre å se at så mange av dere prøver det selv og spør noen flotte spørsmål. Hold det oppe!

I gjennomgang: Klasser og objekter

La oss se på hva vi har lært om klasser i denne serien så langt. Hvis du ikke vet noe om dette, vær så snill å skumme tilbake til den siste opplæringen for å re-cap. Ok, så, hva er klasser?

En klasse er en samling av innkapslede data og tilpassede metoder. En klasse kan inneholde mange forskjellige typer data, og klassemetoder utfører vanligvis (men ikke alltid) handling relatert til dataene. I Mål-C er en klasse vanligvis sammensatt av to filer: en grensesnittfil og en implementeringsfil. Grensesnittfilen bruker .h filtypen etter konvensjon og er der personen som bruker klassen, raskt kan finne metodene og datamedlemmene som er tilgjengelige for klassen. Implementeringsfilen bruker .m filtypen etter konvensjon, og er der hovedparten av koden ligger fordi den inneholder den faktiske implementeringen av alle funksjonene deklarert i grensesnittet.

Så, hva gjør en klasse forskjellig fra et objekt? Hva er et objekt? Et objekt er en forekomst av en klasse. Tenk tilbake til vårt eksempel med bilen i den siste delen av serien. Hvor bil er da klassen bilen min, dansCar, og din bil ville alle være objekter fordi de er tilfeller av bilklassen.

Klasser fra Apple (og litt historie)

Før vi fortsetter, vil jeg dele noen få (av mange) vanlige klasser du bruker mye som leveres av Apple, men først en rask historieleksjon.

Mange klasser Apple gir er prepended med forkortelsen "NS", som står for NextStep. Da Steve Jobs forlot Apple, grunnla han NeXT, og skapte arbeidsstasjons datamaskiner som kjørte på operativsystemet. Objektorientert programmeringsspråk som brukes på disse maskinene, ble kalt NeXTSTEP, som er hvor vi får "NS" fra. Da Apple 'kjøpte' (en annen historieleksjon i seg selv) NeXTSTEP, bestemte de seg for å basere Mac OS X på NeXTSTEP.

Her er noen enkle, vanlige klasser vi ser mye av:

  • NSString er en streng med tekst som er uforanderlig.
  • NSMutableString er en tekststreng som er omgjengelig.
  • NSArray er en rekke objekter som er uforanderlige.
  • NSMutableArray er en rekke objekter som er mutable.
  • NSNumber har en numerisk verdi.

Vi lærer mange flere senere, men for nå vil ovennevnte komme til nytte. Du lurer nok på hva som er ugjennomtrengelig og uforanderlig, noe som er et helt fornuftig spørsmål. Hvis en gjenstand er uforanderlige det betyr at når vi lager objektet og tilordner en verdi så er det statisk. Verdien kan ikke endres. Hvis en gjenstand er foranderlig da er det dynamisk, noe som betyr at verdien kan endres etter opprettelsen.

Pekere og Initialisering

La oss si at vi vil lage en statisk tekststreng og logge den, hvordan skal vi gå om det? I vår kode ville det se slik ut:

 #importere  int main (int argc, const char * argv []) NSString * testString; testString = [[NSString alloker] init]; testString = @ "Her er en teststreng i testString!"; NSLog (@ "testString:% @", testString); returner 0;  

Jeg opprettet denne filen i XCode ved å gå til Fil> Nytt prosjekt> Mac OS X> Program> Kommandolinjeverktøy> Type: Foundation (ganske en reise!) og redigere implementeringsfilen (extension: .m) i prosjektet.

Det er ganske mange ting her som er nye, så la oss undersøke brikken for hverandre.

Først og fremst importerer vi grunnbiblioteket (dette er fordi vi setter typen til Foundation i det nye prosjektvinduet før).

 int main (int argc, const char * argv [])  

Dette erklærer den opprinnelige funksjonen som vil bli kalt når programmet starter. De to parametrene adskilt av et komma er for å overføre argumenter til vår søknad. For øyeblikket, ikke bekymre deg for disse, da vi ikke trenger dem akkurat nå.

 NSString * testString; testString = [[NSString alloker] init]; 

Vi lager nå en peker til et NSString-objekt kalt testString. Når den første linjen av dette er ferdig, eksisterer det ingen streng ennå, bare en peker til en streng som vi ennå ikke har opprettet. På neste linje lager vi strengen pekeren peker på.

Vi kunne alternativt ha skrevet den siste linjen som dette;

 testString = [NSString allokering]; [testString init]; 

Dette kan virke litt forvirrende først. I den første versjonen har vi nestet uttalelsene innen parentes på samme linje, mens i det andre har vi skilt ut setningene i to linjer. Metoden init initierer alle instansvariablene i klassen.

 testString = @ "Her er en teststreng i testString!"; 

Denne linjen er ganske selvforklarende, årsaken til at vi legger ut sitatene med et @ -tegn er å fortelle kompilatoren at følgende tekst er en NSString.

NSLog (@ "testString:% @", testString);

Her logger vi litt informasjon til konsoll. XCode har en debugger innebygd som du finner under Run-menyen. Det er svært nyttig når du utvikler et program for å logge når hendelser skjer og verdiene av visse variabler - det kan hjelpe når du feilsøker program- og feilsøkingsproblemer. Denne metoden fungerer som printf (husk fra den første uken?) Der vi leverer en streng med tekst med erstatningskarakter (% @ betyr et objektiv-C-objekt).

Til slutt returnerer vi 0, som vi vet bare forteller operativsystemet at søknaden avsluttet uten problemer.

Arv

Husk da vi gjorde vår NSString tidligere, brukte vi init-metoden? Vel NSMutableString, NSArray og faktisk, hver eneste NS-klasse, bruker også init. Synes mye bortkastet kode for å sette init-metoden i hver klasse, ikke sant? Det ville være, derfor er init vanligvis bare implementert en gang i rotklassen kjent som NSObject. Fordi klasser arver fra hverandre, en klasse som er opprettet som et barn av en annen, vil foreldreklassen automatisk få tilgang til foreldrenes klassemetoder.

La oss ta NSMutableString for eksempel. NSMutableString har NSString for en forelder (gjør det til et barn), noe som betyr at det arver fra NSString. I mellomtiden. NSString har NSObject som forelder, så det arver fra NSObject.

Så for eksempel har NSObject en metode kalt init, så hver underklasse har denne metoden implementert - som kalles en klassemetode. Faktisk, init-metoden i NSObject gjør egentlig ikke noe som bare returnerer selv. Årsaken til dette er at metodene kan skrives over. Så NSArray-klassen kan overstyre init som den arver til å legge til funksjonalitet for det - for eksempel å sørge for at minnet er tilgjengelig eller forberede eventuelle forekomstvariabler det kan trenge.

Som vist er dette nyttig fordi det betyr at i tillegg til å arve fra klasser kan vi også utvide klasser. Når vi utvider en klasse, tar vi en eksisterende klasse og legger til flere funksjoner til det som allerede er tilgjengelig. Dette betyr at du kan lage din egen versjon av NSString med flere metoder, for eksempel en metode for å fylle strengen med tilfeldig tekst eller utføre en slags tegnkoding.

Sammendrag

På dette punktet er det grunnleggende om hvordan klassene skal fungere klart. For å teste forståelsen din, se om du kan svare på følgende spørsmål i tankene dine:

  • Hva er forskjellen mellom en klasse og et objekt?
  • Hvorfor bruker vi klasser?
  • Hvorfor er arv nyttig?

Siden klasser er en så viktig del av Objective-C, er det viktig å virkelig føle seg komfortabel med å jobbe med dem. I forrige uke begynte vi å se på klasser og denne uken har vi gått inn i mer dybde. Neste uke kan du være glad for å høre, vi skal flytte vekk fra teoretisk side og begynne å jobbe med vår egen enkle klasse eller to for å utføre enkle oppgaver.

Hjemmelekser

Siden vi i hovedsak har gjort teori så langt, er leksene dine denne uken å surfe på Apples utviklerwebside (du burde ha gjort det i forrige uke) og se på noen av de tilgjengelige klassene. Hvis du ikke vet hvor du skal begynne, starter du med noe som NSString. Du vil bli mer komfortabel med detaljene i foreldreklassen, metodene og så videre. Dette vil være viktig senere når du bruker klasser utenfor denne serien, og du vil vite hvilke metoder de arver eller bruker.

Neste gang

Vi får mer praktisk neste uke med noen klassekoding. Klasser er virkelig sentrale for Objective-C, så det er veldig viktig at du tar tak i dem, og målet med denne serien er å virkelig sørge for at du gjør!

Som vanlig, hvis du har noen spørsmål eller kommentarer, kan du nå meg ved å slippe en kommentar eller e-post. Hvis du ønsker å komme i kontakt med meg personlig og få et raskt svar, send meg en tweet!