Share
In de tutorial van vandaag leer je over Categorieën en hoe je ze kunt gebruiken om de functionaliteit van Cocoa-Touch-klassen uit te breiden. Dit is ons laatste deel in de Learn Objective-C-serie, dus je krijgt ook een korte samenvatting van wat we tot nu toe hebben besproken en kijk dan wat je kunt doen om je vaardigheden als Objective-C of iPhone te verbeteren applicatie ontwikkelaar.
Wat zijn categorieën? Veel Objective-C handleidingen en series zullen categorieën over het hoofd zien, wat jammer is omdat ze zo'n handige taalfunctie zijn die verbazingwekkend nuttig is. Categorieën helpen de code schoon te houden en minder rommelig door onnodige subklassen overbodig te maken. Van wat we tot nu toe hebben geleerd, als we een NSString-object hadden, wilden we functionaliteit toevoegen om iets te doen als een methode toevoegen die alle 'a'-tekens zou vervangen door een' 4 '(nutteloos weet ik, maar bijvoorbeeld alleen voor doeleinden), dan konden we NSString onderverdelen en de methode zelf toevoegen. We zagen ook dit soort subklassen toen we onze autoklasse maakten, ik vroeg je aan het einde van die tutorial om een subklasse van de auto te maken, zodat je functionaliteit aan de basisklasse kon toevoegen. Subclassering is een goede benadering en ik kan u op geen enkele manier zeggen dat u moet stoppen met subclassing, maar in bepaalde situaties bieden categorieën een betere benadering om wat extra functionaliteit aan een klasse toe te voegen.
Met categorieën kunnen we methoden toevoegen aan een bestaande klasse, zodat alle instanties van die klasse in uw toepassing uw functionaliteit krijgen. Stel dat we 100 NSString-objecten in uw app hebben, maar u wilt een aangepaste subklasse maken, zodat elke NSString een extra methode heeft (bijvoorbeeld reverseString). Met categorieën kunnen we eenvoudig de methode in een categorie toevoegen en alle instanties mogen de nieuwe methode gebruiken. De syntaxis verschilt duidelijk enigszins van subklasse en categorieën staan je niet toe om instantievariabelen te gebruiken. Het is echter mogelijk om een reeds bestaande methode te overschrijven, maar dit moet met de nodige voorzichtigheid gebeuren en alleen als het echt nodig is.
Categorieën hebben dezelfde syntaxislay-out als een klasse, omdat ze een implementatie en een interface hebben. De interface ziet er als volgt uit:
@interface ClassNameHere (categorie) // methode-declaratie (s) @end De implementatie ziet er als volgt uit; @implementation ClassNameHere (categorie) // methode-implementatie (s) @end
Makkelijk, toch? Laten we dus een voorbeeld bekijken. We gaan een eenvoudige methode maken die een string omkeert. Hoewel deze methode praktisch nutteloos is; het is niet wat de methode aan het doen is die belangrijk is. Je zou al moeten weten hoe de interface eruit zal zien, maar hier is het sowieso:
@interface NSString (reverse) - (NSString *) reverseString; @einde
Nu om onze implementatie te creëren:
@implementation NSString (reverse) - (NSString *) reverseString @end
Vervolgens moeten we een aantal eenvoudige code toevoegen om de reeks rond te draaien. Omdat we methoden aan de klasse NSString toevoegen, verwijzen we naar de tekenreeks met behulp van het zelf. Om de string om te keren, hebben we nu een nieuw, tijdelijk stringobject nodig om de omgekeerde string vast te houden. De manier waarop we de reeks omkeren, is om gewoon de bestaande string in omgekeerde volgorde te doorlopen, elke keer dat we een nieuw karakter vinden, zullen we het aan het object met omgekeerde string toevoegen. De code hiervoor is:
int lengte = [zelf lengte]; NSMutableString * reversedString; reversedString = [[NSMutableString alloc] initWithCapacity: length]; while (length> 0) [reversedString appendString: [NSString stringWithFormat: @ "% C", [self characterAtIndex: - length]]]; return [reversedString autorelease];
Deze methode is vrij eenvoudig, we herhalen één keer voor elk teken in de tekenreeks. We voegen het huidige teken toe met behulp van stringWithFormat en de teken (C) -identificatie. Wanneer we --lengte noemen, keren we niet alleen het gehele lengte-getal terug, maar trekken we er ook van af, wat is hoe onze lus langs de string beweegt.
Als alles goed is gegaan, moeten alle NSString's die al deel uitmaken van ons project zich houden aan onze nieuwe categorie. Nu kunt u zien waarom categorieën zo nuttig zijn!
Ok, nu zouden al onze NSString-objecten onze reverseString-methode moeten hebben. Om het samen te vatten, zou onze code er zo uit moeten zien:
@interface NSString (reverse) - (NSString *) reverseString; @end @implementation NSString (reverse) - (NSString *) reverseString int length = [self length]; NSMutableString * reversedString; reversedString = [[NSMutableString alloc] initWithCapacity: length]; while (length> 0) [reversedString appendString: [NSString stringWithFormat: @ "% C", [self characterAtIndex: - length]]]; return [reversedString autorelease]; @end
Elk codeblok (interface en implementatie) moet volgens conventie in hun eigen bestanden staan. We noemen categorieën echter een beetje anders. De twee bestanden die we hebben gemaakt, hebben de naam: NSString + reverse.h (interface) en NSString + reverse.m (implementatie).
Dit is een gebruikelijke naamgevingsconventie volgens het patroon van de naam van de klasse waaraan we een categorie toevoegen, een plusteken en de naam van onze categorie. Voordat we verder gaan, onthoud dat we nog steeds ons headerbestand moeten opnemen in het hoofdproject. Dus nu zou onze code er ongeveer zo uit moeten zien:
NSString * testString = @ "Gewoon een test"; [testString reverseString]; NSLog (@ "Omgekeerd: '% @'", testString);
Als alles volgens plan zou verlopen, zou de console een omgekeerde versie van "Just a test" moeten registreren!
Als alles niet volgens plan verloopt, controleert u of u de code voor reverseString correct hebt gekopieerd en zorgt u ervoor dat u het header (* .h) -bestand voor de categorie opneemt in uw hoofdcodebestand..
Zoals je kunt zien, zijn categorieën echt heel handig (vooral met strings). Ze hebben een breed scala aan toepassingen in elk project, een gebruik dat ik gebruik is validatie. Op deze manier kan ik al mijn validatie op één plek bewaren en hoef ik geen ingewikkelde subklassen te gebruiken.
Dit is niet alleen het einde van de tutorial van vandaag, dit is het einde van de serie over de fundamenten van Objective-C. In de laatste verschillende zelfstudies hebben we de volgende onderwerpen behandeld:
Ik hoop dat je deze serie leuk vond, en als je tot nu toe slechts een of twee van de tutorials hebt gelezen, moedig ik je aan om op dag 1 te beginnen en een zelfstudie per dag te lezen. Aan het einde van de serie moet je voldoende zelfvertrouwen hebben om binnen een week je eigen code te kunnen schrijven!
Als je vragen hebt over de getoonde serie of voorbeelden, of als je een extra tutorial over een ander gebied van Objective-C programmeren wilt, kun je hieronder een reactie achterlaten.
Als je vragen hebt over Objective-C zelf, een project waar je aan werkt of gewoon wat technisch advies, aarzel dan niet om me een vermelding of direct bericht te sturen op Twitter of mijn website te bezoeken en je weg te vinden naar de Contact Formulier!
Nu we klaar zijn, zijn de uitdagingen eindeloos. Ik raad u ten zeerste aan om een pen op papier te zetten en een eerste app te kiezen die van begin tot einde moet worden opgebouwd. Kom met een idee en een ontwerp, pas dan alle principes toe die je uit deze serie hebt geleerd en laat ons weten wat je bedacht!
Bedankt voor het lezen!
Accentsconagua