Je suis à l'origine un programmeur Java qui travaille maintenant avec Objective-C. Je voudrais créer une classe abstraite, mais cela ne semble pas possible dans Objective-C. Est-ce possible?

Sinon, à quelle distance d'une classe abstraite puis-je obtenir en Objective-C?

En règle générale, les classes Objective-C sont abstraites par convention uniquement - si l'auteur documente une classe comme abstraite, ne l'utilisez pas sans la sous-classer. Cependant, il n'y a pas d'application au moment de la compilation qui empêche l'instanciation d'une classe abstraite. En fait, rien n'empêche un utilisateur de fournir des implémentations de méthodes abstraites via une catégorie (c'est-à-dire au moment de l'exécution). Vous pouvez forcer un utilisateur à remplacer au moins certaines méthodes en levant une exception dans l'implémentation de ces méthodes dans votre classe abstraite:

[NSException raise:NSInternalInconsistencyException 
            format:@"You must override %@ in a subclass", NSStringFromSelector(_cmd)];

Si votre méthode retourne une valeur, c'est un peu plus facile à utiliser

@throw [NSException exceptionWithName:NSInternalInconsistencyException
                               reason:[NSString stringWithFormat:@"You must override %@ in a subclass", NSStringFromSelector(_cmd)]
                             userInfo:nil];

comme alors vous n'avez pas besoin d'ajouter une déclaration de retour de la méthode.

Si la classe abstraite est vraiment une interface (c'est-à-dire qu'elle n'a pas d'implémentation de méthode concrète), l'utilisation d'un protocole Objective-C est l'option la plus appropriée.

Non, il n'y a aucun moyen de créer une classe abstraite dans Objective-C.

Vous pouvez vous moquer d'une classe abstraite - en faisant appeler les méthodes / sélecteurs doesNotRecognizeSelector: et donc lever une exception rendant la classe inutilisable.

Par exemple:

- (id)someMethod:(SomeObject*)blah
{
     [self doesNotRecognizeSelector:_cmd];
     return nil;
}

Vous pouvez également le faire pour init.

Juste en riffant sur la réponse de @Barry Wark ci-dessus (et en mettant à jour pour iOS 4.3) et en laissant cela pour ma propre référence:

#define mustOverride() @throw [NSException exceptionWithName:NSInvalidArgumentException reason:[NSString stringWithFormat:@"%s must be overridden in a subclass/category", __PRETTY_FUNCTION__] userInfo:nil]
#define methodNotImplemented() mustOverride()

puis dans vos méthodes, vous pouvez utiliser cette

- (void) someMethod {
     mustOverride(); // or methodNotImplemented(), same thing
}

Remarques: Je ne sais pas si faire une macro ressemble à une fonction C est une bonne idée ou non, mais je vais le garder jusqu'à ce que vous appreniez le contraire. Je pense qu'il est plus correct d'utiliser NSInvalidArgumentException(plutôt que NSInternalInconsistencyException) car c'est ce que le système d'exécution lance en réponse à l' doesNotRecognizeSelectorappel (voir la NSObjectdocumentation).

La solution que j'ai trouvée est:

1. Créez un protocole pour tout ce que vous voulez dans votre classe "abstraite"
2. Créez une classe de base (ou appelez-la peut-être abstraite) qui implémente le protocole. Pour toutes les méthodes que vous souhaitez "abstraites", implémentez-les dans le fichier .m, mais pas dans le fichier .h.
3. Demandez à votre classe enfant d'hériter de la classe de base ET implémentez le protocole.

De cette façon, le compilateur vous donnera un avertissement pour toute méthode du protocole qui n'est pas implémentée par votre classe enfant.

Ce n'est pas aussi succinct qu'en Java, mais vous obtenez l'avertissement du compilateur souhaité.

À partir de la liste de diffusion Omni Group :

Objective-C n'a pas la construction du compilateur abstrait comme Java pour le moment.

Donc, tout ce que vous faites est de définir la classe abstraite comme toute autre classe normale et d'implémenter des talons de méthodes pour les méthodes abstraites qui sont vides ou signalent la non-prise en charge du sélecteur. Par exemple...

- (id)someMethod:(SomeObject*)blah
{
     [self doesNotRecognizeSelector:_cmd];
     return nil;
}

Je fais également ce qui suit pour empêcher l'initialisation de la classe abstraite via l'initialiseur par défaut.

- (id)init
{
     [self doesNotRecognizeSelector:_cmd];
     [self release];
     return nil;
}

Au lieu d'essayer de créer une classe de base abstraite, envisagez d'utiliser un protocole (similaire à une interface Java). Cela vous permet de définir un ensemble de méthodes, puis d'accepter tous les objets conformes au protocole et d'implémenter les méthodes. Par exemple, je peux définir un protocole d'opération, puis avoir une fonction comme celle-ci:

- (void)performOperation:(id<Operation>)op
{
   // do something with operation
}

Où op peut être n'importe quel objet implémentant le protocole d'opération.

Si vous avez besoin de votre classe de base abstraite pour faire plus que simplement définir des méthodes, vous pouvez créer une classe Objective-C régulière et empêcher qu'elle ne soit instanciée. Remplacez simplement la fonction - (id) init et faites-la retourner nil ou assert (false). Ce n'est pas une solution très propre, mais comme Objective-C est entièrement dynamique, il n'y a vraiment pas d'équivalent direct à une classe de base abstraite.

Ce fil est un peu ancien, et la plupart de ce que je veux partager est déjà là.

Cependant, ma méthode préférée n'est pas mentionnée, et AFAIK il n'y a pas de support natif dans le Clang actuel, alors c'est parti…

Tout d'abord, et surtout (comme d'autres l'ont déjà souligné), les classes abstraites sont quelque chose de très rare dans Objective-C - nous utilisons généralement la composition (parfois par délégation) à la place. C'est probablement la raison pour laquelle une telle fonctionnalité n'existe pas déjà dans le langage / compilateur - à part les @dynamicpropriétés, que l'IIRC a ajoutées dans ObjC 2.0 accompagnant l'introduction de CoreData.

Mais étant donné que (après une évaluation minutieuse de votre situation!) Vous êtes arrivé à la conclusion que la délégation (ou la composition en général) n'est pas bien adaptée pour résoudre votre problème, voici comment je le fais:

1. Implémentez chaque méthode abstraite dans la classe de base.
2. Faites cette mise en œuvre [self doesNotRecognizeSelector:_cmd];…
3. … Suivi de __builtin_unreachable();pour faire taire l'avertissement que vous obtiendrez pour les méthodes non nulles, vous indiquant «le contrôle a atteint la fin de la fonction non nulle sans retour».
4. Vous pouvez soit combiner les étapes 2. et 3. dans une macro, soit annoter l' -[NSObject doesNotRecognizeSelector:]utilisation __attribute__((__noreturn__))dans une catégorie sans implémentation afin de ne pas remplacer l'implémentation d'origine de cette méthode, et inclure l'en-tête de cette catégorie dans le PCH de votre projet.

Personnellement, je préfère la version macro car cela me permet de réduire le plus possible le passe-partout.

C'est ici:

// Definition:
#define D12_ABSTRACT_METHOD {\
 [self doesNotRecognizeSelector:_cmd]; \
 __builtin_unreachable(); \
}

// Usage (assuming we were Apple, implementing the abstract base class NSString):
@implementation NSString

#pragma mark - Abstract Primitives
- (unichar)characterAtIndex:(NSUInteger)index D12_ABSTRACT_METHOD
- (NSUInteger)length D12_ABSTRACT_METHOD
- (void)getCharacters:(unichar *)buffer range:(NSRange)aRange D12_ABSTRACT_METHOD

#pragma mark - Concrete Methods
- (NSString *)substringWithRange:(NSRange)aRange
{
    if (aRange.location + aRange.length >= [self length])
        [NSException raise:NSInvalidArgumentException format:@"Range %@ exceeds the length of %@ (%lu)", NSStringFromRange(aRange), [super description], (unsigned long)[self length]];

    unichar *buffer = (unichar *)malloc(aRange.length * sizeof(unichar));
    [self getCharacters:buffer range:aRange];

    return [[[NSString alloc] initWithCharactersNoCopy:buffer length:aRange.length freeWhenDone:YES] autorelease];
}
// and so forth…

@end

Comme vous pouvez le voir, la macro fournit l'implémentation complète des méthodes abstraites, réduisant la quantité nécessaire de passe-partout au minimum absolu.

Une option encore meilleure serait de faire pression sur l' équipe Clang pour fournir un attribut de compilateur pour ce cas, via des demandes de fonctionnalités. (Mieux, car cela permettrait également des diagnostics au moment de la compilation pour les scénarios où vous sous-classe, par exemple NSIncrementalStore.)

Pourquoi je choisis cette méthode

1. Il fait le travail de manière efficace et quelque peu pratique.
2. C'est assez facile à comprendre. (D'accord, cela __builtin_unreachable()peut surprendre les gens, mais c'est assez facile à comprendre aussi.)
3. Il ne peut pas être supprimé dans les versions de version sans générer d'autres avertissements ou erreurs du compilateur - contrairement à une approche basée sur l'une des macros d'assertion.

Ce dernier point nécessite quelques explications, je suppose:

Certaines personnes (la plupart?) Suppriment les assertions dans les versions. (Je ne suis pas d'accord avec cette habitude, mais c'est une autre histoire…) Le fait de ne pas implémenter une méthode requise - cependant - est mauvais , terrible , mauvais et, fondamentalement, la fin de l'univers pour votre programme. Votre programme ne peut pas fonctionner correctement à cet égard car il n'est pas défini et un comportement indéfini est la pire chose qui soit. Par conséquent, être en mesure de supprimer ces diagnostics sans générer de nouveaux diagnostics serait totalement inacceptable.

C'est déjà assez grave pour que vous ne puissiez pas obtenir de diagnostics de compilation corrects pour ces erreurs de programmation, et que vous ayez à recourir à la découverte au moment de l'exécution pour celles-ci, mais si vous pouvez les recouvrir dans les versions, pourquoi essayer d'avoir une classe abstraite dans le première place?

Utilisation @propertyet @dynamicpourrait également fonctionner. Si vous déclarez une propriété dynamique et ne donnez pas d'implémentation de méthode correspondante, tout sera compilé sans avertissements et vous obtiendrez une unrecognized selectorerreur au moment de l'exécution si vous essayez d'y accéder. C'est essentiellement la même chose que d'appeler [self doesNotRecognizeSelector:_cmd], mais avec beaucoup moins de frappe.

Dans Xcode (en utilisant clang, etc.), j'aime utiliser __attribute__((unavailable(...)))pour baliser les classes abstraites afin que vous obteniez une erreur / un avertissement si vous essayez de l'utiliser.

Il offre une certaine protection contre l'utilisation accidentelle de la méthode.

Exemple

Dans la @interfacebalise de classe de base, les méthodes "abstraites":

- (void)myAbstractMethod:(id)param1 __attribute__((unavailable("You should always override this")));

En allant plus loin, je crée une macro:

#define UnavailableMacro(msg) __attribute__((unavailable(msg)))

Cela vous permet de faire ceci:

- (void)myAbstractMethod:(id)param1 UnavailableMacro(@"You should always override this");

Comme je l'ai dit, ce n'est pas une véritable protection du compilateur, mais c'est à peu près aussi efficace que vous allez obtenir dans un langage qui ne prend pas en charge les méthodes abstraites.

La réponse à la question est dispersée dans les commentaires sous les réponses déjà données. Donc, je résume et simplifie simplement ici.

Option 1: protocoles

Si vous souhaitez créer une classe abstraite sans implémentation, utilisez «Protocoles». Les classes héritant d'un protocole sont obligées d'implémenter les méthodes dans le protocole.

@protocol ProtocolName
// list of methods and properties
@end

Option2: modèle de méthode de modèle

Si vous voulez créer une classe abstraite avec une implémentation partielle comme "Pattern Method Pattern", alors c'est la solution. Objective-C - Modèle de méthodes de modèle?

Une autre alternative

Il vous suffit de vérifier la classe dans la classe Abstract et d'affirmer ou d'exclure ce que vous voulez.

@implementation Orange
- (instancetype)init
{
    self = [super init];
    NSAssert([self class] != [Orange class], @"This is an abstract class");
    if (self) {
    }
    return self;
}
@end

Cela supprime la nécessité de passer outre init

(plus d'une suggestion connexe)

Je voulais avoir un moyen de faire savoir au programmeur "ne pas appeler de l'enfant" et de passer outre complètement (dans mon cas, toujours offrir certaines fonctionnalités par défaut au nom du parent lorsqu'il n'est pas étendu):

typedef void override_void;
typedef id override_id;

@implementation myBaseClass

// some limited default behavior (undesired by subclasses)
- (override_void) doSomething;
- (override_id) makeSomeObject;

// some internally required default behavior
- (void) doesSomethingImportant;

@end

L'avantage est que le programmeur VOIRa le "remplacement" dans la déclaration et saura qu'il ne doit pas appeler [super ..].

Certes, il est moche d'avoir à définir des types de retour individuels pour cela, mais cela sert de bon indice visuel et vous ne pouvez pas facilement utiliser la partie "override_" dans une définition de sous-classe.

Bien sûr, une classe peut toujours avoir une implémentation par défaut lorsqu'une extension est facultative. Mais comme le disent les autres réponses, implémentez une exception d'exécution le cas échéant, comme pour les classes abstraites (virtuelles).

Ce serait bien d'avoir intégré des astuces de compilateur comme celle-ci, même des astuces pour quand il est préférable de pré / post appeler l'implémentation du super, au lieu d'avoir à fouiller dans les commentaires / documentation ou ... à supposer.

Si vous êtes habitué à ce que le compilateur détecte des violations d'instanciation abstraites dans d'autres langues, le comportement d'Objective-C est décevant.

En tant que langage de liaison tardive, il est clair qu'Objective-C ne peut pas décider statiquement si une classe est vraiment abstraite ou non (vous pourriez ajouter des fonctions au moment de l'exécution ...), mais pour les cas d'utilisation typiques, cela semble être un défaut. Je préférerais que le compilateur empêche les instanciations des classes abstraites au lieu de générer une erreur lors de l'exécution.

Voici un modèle que nous utilisons pour obtenir ce type de vérification statique en utilisant quelques techniques pour masquer les initialiseurs:

//
//  Base.h
#define UNAVAILABLE __attribute__((unavailable("Default initializer not available.")));

@protocol MyProtocol <NSObject>
-(void) dependentFunction;
@end

@interface Base : NSObject {
    @protected
    __weak id<MyProtocol> _protocolHelper; // Weak to prevent retain cycles!
}

- (instancetype) init UNAVAILABLE; // Prevent the user from calling this
- (void) doStuffUsingDependentFunction;
@end

//
//  Base.m
#import "Base.h"

// We know that Base has a hidden initializer method.
// Declare it here for readability.
@interface Base (Private)
- (instancetype)initFromDerived;
@end

@implementation Base
- (instancetype)initFromDerived {
    // It is unlikely that this becomes incorrect, but assert
    // just in case.
    NSAssert(![self isMemberOfClass:[Base class]],
             @"To be called only from derived classes!");
    self = [super init];
    return self;
}

- (void) doStuffUsingDependentFunction {
    [_protocolHelper dependentFunction]; // Use it
}
@end

//
//  Derived.h
#import "Base.h"

@interface Derived : Base
-(instancetype) initDerived; // We cannot use init here :(
@end

//
//  Derived.m
#import "Derived.h"

// We know that Base has a hidden initializer method.
// Declare it here.
@interface Base (Private)
- (instancetype) initFromDerived;
@end

// Privately inherit protocol
@interface Derived () <MyProtocol>
@end

@implementation Derived
-(instancetype) initDerived {
    self= [super initFromDerived];
    if (self) {
        self->_protocolHelper= self;
    }
    return self;
}

// Implement the missing function
-(void)dependentFunction {
}
@end

Ce genre de situations ne devrait probablement se produire qu'au moment du développement, donc cela pourrait fonctionner:

- (id)myMethodWithVar:(id)var {
   NSAssert(NO, @"You most override myMethodWithVar:");
   return nil;
}

Vous pouvez utiliser une méthode proposée par @Yar (avec quelques modifications):

#define mustOverride() @throw [NSException exceptionWithName:NSInvalidArgumentException reason:[NSString stringWithFormat:@"%s must be overridden in a subclass/category", __PRETTY_FUNCTION__] userInfo:nil]
#define setMustOverride() NSLog(@"%@ - method not implemented", NSStringFromClass([self class])); mustOverride()

Ici, vous obtiendrez un message comme:

<Date> ProjectName[7921:1967092] <Class where method not implemented> - method not implemented
<Date> ProjectName[7921:1967092] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[<Base class (if inherited or same if not> <Method name>] must be overridden in a subclass/category'

Ou affirmation:

NSAssert(![self respondsToSelector:@selector(<MethodName>)], @"Not implemented");

Dans ce cas, vous obtiendrez:

<Date> ProjectName[7926:1967491] *** Assertion failure in -[<Class Name> <Method name>], /Users/kirill/Documents/Projects/root/<ProjectName> Services/Classes/ViewControllers/YourClass:53

Vous pouvez également utiliser des protocoles et d'autres solutions - mais c'est l'une des plus simples.

Le cacao ne fournit rien appelé abstrait. Nous pouvons créer un résumé de classe qui n'est vérifié qu'au moment de l'exécution, et au moment de la compilation, ce n'est pas vérifié.

Je désactive généralement la méthode init dans une classe que je souhaite abstraire:

- (instancetype)__unavailable init; // This is an abstract class.

Cela générera une erreur au moment de la compilation chaque fois que vous appelez init sur cette classe. J'utilise ensuite des méthodes de classe pour tout le reste.

Objective-C n'a aucun moyen intégré pour déclarer des classes abstraites.

En modifiant un peu ce que @redfood a suggéré en appliquant le commentaire de @ dotToString, vous avez en fait la solution adoptée par IGListKit d'Instagram .

1. Créez un protocole pour toutes les méthodes qui n'ont aucun sens à définir dans la classe de base (abstraite), c'est-à-dire qu'elles nécessitent des implémentations spécifiques chez les enfants.
2. Créez une classe de base (abstraite) qui n'implémente pas ce protocole. Vous pouvez ajouter à cette classe toutes les autres méthodes qui ont du sens d'avoir une implémentation commune.
3. Partout dans votre projet, si un enfant de AbstractClassdoit être entré ou sorti par une méthode, saisissez-le à la AbstractClass<Protocol>place.

Parce que AbstractClassn'implémente pas Protocol, la seule façon d'avoir une AbstractClass<Protocol>instance est de sous-classer. Comme AbstractClassseul ne peut être utilisé nulle part dans le projet, il devient abstrait.

Bien sûr, cela n'empêche pas les développeurs déconseillés d'ajouter de nouvelles méthodes se référant simplement à AbstractClass, ce qui finirait par autoriser une instance de la classe abstraite (plus maintenant).

Exemple réel: IGListKit a une classe de base IGListSectionControllerqui n'implémente pas le protocole IGListSectionType, cependant chaque méthode qui nécessite une instance de cette classe, demande en fait le type IGListSectionController<IGListSectionType>. Par conséquent, il n'y a aucun moyen d'utiliser un objet de type IGListSectionControllerpour quelque chose d'utile dans leur cadre.

En fait, Objective-C n'a pas de classes abstraites, mais vous pouvez utiliser des protocoles pour obtenir le même effet. Voici l'exemple:

CustomProtocol.h

#import <Foundation/Foundation.h>

@protocol CustomProtocol <NSObject>
@required
- (void)methodA;
@optional
- (void)methodB;
@end

TestProtocol.h

#import <Foundation/Foundation.h>
#import "CustomProtocol.h"

@interface TestProtocol : NSObject <CustomProtocol>

@end

TestProtocol.m

#import "TestProtocol.h"

@implementation TestProtocol

- (void)methodA
{
  NSLog(@"methodA...");
}

- (void)methodB
{
  NSLog(@"methodB...");
}
@end

Un exemple simple de création d'une classe abstraite

// Declare a protocol
@protocol AbcProtocol <NSObject>

-(void)fnOne;
-(void)fnTwo;

@optional

-(void)fnThree;

@end

// Abstract class
@interface AbstractAbc : NSObject<AbcProtocol>

@end

@implementation AbstractAbc

-(id)init{
    self = [super init];
    if (self) {
    }
    return self;
}

-(void)fnOne{
// Code
}

-(void)fnTwo{
// Code
}

@end

// Implementation class
@interface ImpAbc : AbstractAbc

@end

@implementation ImpAbc

-(id)init{
    self = [super init];
    if (self) {
    }
    return self;
}

// You may override it    
-(void)fnOne{
// Code
}
// You may override it
-(void)fnTwo{
// Code
}

-(void)fnThree{
// Code
}

@end

Vous ne pouvez pas simplement créer un délégué?

Un délégué est comme une classe de base abstraite dans le sens où vous dites quelles fonctions doivent être définies, mais vous ne les définissez pas réellement.

Ensuite, chaque fois que vous implémentez votre délégué (c'est-à-dire la classe abstraite), le compilateur vous avertit des fonctions facultatives et obligatoires pour lesquelles vous devez définir le comportement.

Cela ressemble à une classe de base abstraite pour moi.