Share
Welkom bij deel twee van deze inleidende serie over Objective-C. Nadat we vorige week de grondbeginselen van de C-taal hebben doorgenomen waarop Objective-C is gebouwd, zullen we deze week overgaan op het focussen op wat Objective-C zo'n geweldige taal maakt voor softwareontwikkeling. In het bijzonder bespreken we de grondbeginselen van Object Oriented Programming (OOP) en demonstreren we hoe we een klasse maken en berichten verzenden naar objecten in Objective-C.
Waarom hebben we Objective-C? Waarom niet gewoon de onderliggende C-taal gebruiken? De reden dat we Objective-C hebben, is om ons een objectgerichte speeltuin te geven waarbinnen we onze applicaties kunnen bouwen. OOP is een programmeerparadigma waarmee ontwikkelaars kunnen nadenken over softwareontwerp in termen van objecten en attributen in plaats van variabelen en functies. In het bijzonder probeert OOP gegevensabstractie, inkapseling, modulariteit, polymorfisme en overerving te verkrijgen. Het onderwerp OOP kan een boek (of een zelfstudiereeks) gemakkelijk zelf vullen, maar in plaats daarvan zal ik u als voorbeeld aan de basisprincipes voorstellen..
Stel je voor dat je een auto hebt. Je kunt je auto als een object beschouwen. Er zijn veel andere auto's in de wereld en je kunt er zelfs meer dan één bezitten. Uw auto heeft verschillende eigenschappen: merk, model, kleur, motortype en nog veel meer. In objectgeoriënteerde programmeringsvoorwaarden zouden we het abstracte concept van een auto een 'klasse' noemen en de individuele auto waarvan u eigenaar bent een object of instantie (geïnstantieerd object) van de klasse. Wanneer een nieuwe auto wordt vervaardigd, wordt een nieuw exemplaar van de autoklasse geïnstantieerd (of gemaakt) en krijgt deze een eigen set eigenschappen.
Nog steeds een beetje vaag? Een andere goede analogie is die van de cookie en de koekjesvormer. De klasse is de cookie-cutter en het object is de cookie.
Dus, waarom denken in termen van objecten? Een van de beste redenen is omdat dit is hoe je hersenen van nature het leven in de echte wereld conceptualiseren, en er zijn veel voordelen aan het kunnen abstraheren van softwareontwikkeling in vergelijkbare termen.
Klassen (en dus objecten) zijn opgebouwd uit methoden en attributen. Als u uit een andere programmeertaal komt, bent u wellicht meer vertrouwd met het vergelijken van methoden met functies en kenmerken met variabelen. We zullen de volgende om de beurt bespreken.
Dus we hebben een "exemplaar" van een auto, wat doen we er nu mee? Wel, we rijden ermee en vullen het onder meer met benzine. Rijden en vullen met benzine is alleen van toepassing op de auto's die we gebruiken, wat betekent dat wanneer we een auto tanken of autorijden, we slechts één exemplaar beïnvloeden, en niet alle auto's ter wereld. Daarom wordt het opvullen van de instantie van de auto beschouwd als een instantie methode. Het is iets dat we doen aan onze instantie en alleen onze instantie.
Aan de andere kant, als we de oorspronkelijke autoklasse vragen hoeveel kleuren van de auto beschikbaar zijn, is dit een klassemethode, omdat we niet langer alleen praten over de auto waar we rondrijden maar alle auto's in het algemeen.
Veel van deze principes worden duidelijker bij gebruik, dus laten we eens kijken naar een beetje syntaxis.
In Objective-C noemen we objectmethoden door berichten door te geven. Als we willen weten hoeveel gas in onze auto zit, sturen we een bericht naar onze instantie en het bericht is de methode die we willen toepassen. Programmatisch ziet het er als volgt uit:
[bericht ontvanger];
De haakjes geven aan dat we een bericht verzenden. De eerste parameter is wie dit bericht zou moeten ontvangen en de tweede parameter is wat het bericht eigenlijk is. Uiteindelijk eindigen we met een puntkomma zoals gebruikelijk in de meeste programmeertalen.
Dus, met ons vorige voorbeeld in gedachten, dit is hoe we zouden omgaan met onze instantie van de auto om gas aan de tank toe te voegen;
[dansCar addGas];
In het bovenstaande voorbeeld wordt ervan uitgegaan dat we een instantie van de klasse Car hebben geïnstantieerd en het de naam "dansCar" hebben gegeven. Vervolgens geven we het bericht "addGas" door aan het object "dansCar", wat het equivalent is van het aanroepen van een functie. In een andere taal kan deze regel er als volgt uitzien:
dansCar.addGas ();
Laten we zeggen dat onze autoklasse een gastank heeft die als een percentage wordt opgeslagen. Als de gastank bijvoorbeeld 50% is, is deze half vol en als deze op 100% staat, betekent dit dat hij vol is. Als we nu willen weten hoeveel gas er in de tank zit, nemen we die informatie niet zomaar rechtstreeks uit een attribuut. In plaats daarvan zouden we een accessor-methode gebruiken om toegang te krijgen tot de interne variabele voor ons. Evenzo, als we de tank willen vullen, geven we niet alleen het benzinetankkenmerk een nieuw percentage, we gebruiken een setter om het attribuut voor ons bij te werken. Dit proces staat bekend als data-inkapseling.
Wat we bedoelen met data-inkapseling is dat data (zogezegd) wordt ingesloten door methoden die erop duiden om er toegang toe te hebben, we moeten methoden gebruiken. Sommigen van jullie die in andere talen hebben geprogrammeerd en nog niet hebben gehoord van gegevensinkapseling vragen zich misschien af waarom we de dingen op deze manier doen. Het antwoord is dat door het inkapselen van gegevens, er een leuk kussen zit tussen de ontwikkelaar van een klasse en de gebruiker van een klas. Omdat de klassemethoden de kenmerken in de klasse beheren en onderhouden, kunnen ze gemakkelijker gegevensintegriteit behouden. Een ander groot voordeel is dat wanneer een ontwikkelaar zijn klas distribueert, de mensen die het gebruiken helemaal geen zorgen hoeven te maken over de interne onderdelen van de klas. Een ontwikkelaar kan een methode bijwerken om deze sneller of efficiënter te maken, maar deze update is transparant voor de gebruiker van de klas, omdat hij / zij nog steeds dezelfde methode gebruikt zonder zijn / haar code te wijzigen.
Dit brengt ons mooi op de volgende sectie waar we naar gaan kijken, en dat is hoe Objective-C de interface van de implementatie scheidt.
Wanneer u in Objective-C een eenvoudige klasse maakt of ermee werkt, ziet u dat deze standaard twee bestanden bevat. Een daarvan is het implementatiebestand dat een bestand is dat eindigt met een achtervoegsel van .m en het interfacebestand dat een bestand is dat eindigt op een achtervoegsel van .h.
#importeren@interface Auto: NSObject // Dit is waar attributen zwevend worden fillLevel; // Dit is waar methoden naartoe gaan - (void) addGas; @einde
Allereerst importeren we Cocoa.h, een standaardbibliotheek met veel herbruikbare code die we kunnen gebruiken in onze app.
Vervolgens verklaren we dat dit de interface voor de auto is, maar we zetten ook NSObject in die verklaring. Toevoegen van ": NSObject" betekent dat de klasse Car erft van de klasse NSObject. In een toekomstige zelfstudie bespreken we meer over overerving.
Onze instantievariabele 'fillLevel' wordt hieronder gedeclareerd en we geven aan dat het van het 'float'-gegevenstype is, zodat we gemakkelijk een percentage kunnen weergeven.
De volgende regel verklaart onze "addGas" -methode. De "-" geeft aan dat dit een instantiemethode is en geen klassemethode. Het "(ongeldig)" gedeelte betekent dat de methode niets terug zal geven als het klaar is met uitvoeren. Als de klasse een geheel getal zou retourneren, zou dit worden gewijzigd in '(int)' en hetzelfde voor elk ander gegevenstype. Ten slotte finaliseren we de methodeverklaring met een puntkomma.
#import "Car.h" @implementation Car - (void) addGas // code gaat hier om gas toe te voegen @end
De implementatie in dit geval bevat de methode om gas aan de tank toe te voegen. We importeren ook Car.h, het interfacebestand. Waar onze addGas-methode zit, zouden we nog veel meer methoden kunnen toevoegen, maar het doel van vandaag is om je eenvoudig te laten begrijpen hoe klassen werken in plaats van een volwaardige klasse te maken.
De volgende keer zullen we dieper ingaan op methoden en op het gebruik van variabelen met methoden (evenals de basisprincipes van het beheren van variabelen in Objective-C). Deze tutorial was niet al te lang, omdat het vaak een beetje verwarrend is voor nieuwe ontwikkelaars waarom we klassen in meer dan één bestand scheiden. Als je je helemaal niet goed voelt, lees dan het bovenstaande opnieuw of stel vragen in het gedeelte 'Opmerkingen' hieronder. Klassen zullen een constante herhaling zijn in deze serie en het is belangrijk dat je begrijpt hoe ze werken.
Aangezien dit deel van de serie redelijk theoretisch was, hoef je niet te veel te doen om te oefenen. Ik raad deze week echter wel aan om je aan te melden voor de ontwikkelaarswebsite van Apple, omdat het een referentie van onschatbare waarde is. Als je dat eenmaal hebt gedaan, kun je een paar van hun downloadbare klassen bekijken en een paar eenvoudige downloaden. U hoeft niet alle code te begrijpen, kijk maar naar hoe de klassen worden gevormd en van elkaar gescheiden worden over bestanden.
Accentsconagua