Creating an abstract class in Objective-C

Question

I m originally a Java programmer who now works with Objective-C  I d like to create an abstract class  but that doesn t appear to be possible in Objective-C  Is this possible   If not  how close to an abstract class can I get in Objective-C

User · Answer

A simple example of creating an abstract class     Declare a protocol  protocol AbcProtocol  lt NSObject gt   - void fnOne  - void fnTwo    optional  - void fnThree    end     Abstract class  interface AbstractAbc   NSObject lt AbcProtocol gt    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

User · Answer

The solution I came up with is    Create a protocol for everything you want in your  abstract  class Create a base class  or maybe call it abstract  that implements the protocol  For all the methods you want  abstract  implement them in the  m file  but not the  h file  Have your child class inherit from the base class AND implement the protocol    This way the compiler will give you a warning for any method in the protocol that isn t implemented by your child class   It s not as succinct as in Java  but you do get the desired compiler warning

User · Answer

Just riffing on  Barry Wark s answer above  and updating for iOS 4 3  and leaving this for my own reference    define mustOverride    throw  NSException exceptionWithName NSInvalidArgumentException reason  NSString stringWithFormat    s must be overridden in a subclass category     PRETTY FUNCTION    userInfo nil   define methodNotImplemented   mustOverride     then in your methods you can use this  -  void  someMethod        mustOverride       or methodNotImplemented    same thing      Notes  Not sure if making a macro look like a C function is a good idea or not  but I ll keep it until schooled to the contrary  I think it s more correct to use NSInvalidArgumentException  rather than NSInternalInconsistencyException  since that s what the runtime system throws in response to doesNotRecognizeSelector being called  see NSObject docs

User · Answer

If you are used to the compiler catching abstract instantiation violations in other languages  then the Objective-C behavior is disappointing   As a late binding language it is clear that Objective-C cannot make static decisions on whether a class truly is abstract or not  you might be adding functions at runtime      but for typical use cases this seems like a shortcoming  I would prefer the compiler flat-out prevented instantiations of abstract classes instead of throwing an error at runtime   Here is a pattern we are using to get this type of static checking using a couple of techniques to hide initializers          Base h  define UNAVAILABLE   attribute    unavailable  Default initializer not available         protocol MyProtocol  lt NSObject gt  - void  dependentFunction   end   interface Base   NSObject        protected       weak id lt MyProtocol gt   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     lt MyProtocol gt   end   implementation Derived - instancetype  initDerived       self   super initFromDerived       if  self            self- gt  protocolHelper  self            return self        Implement the missing function - void dependentFunction      end

User · Answer

You can use a method proposed by  Yar  with some modification     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     Here you will get a message like    lt Date gt  ProjectName 7921 1967092   lt Class where method not implemented gt  - method not implemented  lt Date gt  ProjectName 7921 1967092      Terminating app due to uncaught exception  NSInvalidArgumentException   reason   -  lt Base class  if inherited or same if not gt   lt Method name gt   must be overridden in a subclass category    Or assertion   NSAssert   self respondsToSelector  selector  lt MethodName gt       Not implemented      In this case you will get    lt Date gt  ProjectName 7926 1967491      Assertion failure in -  lt Class Name gt   lt Method name gt     Users kirill Documents Projects root  lt ProjectName gt  Services Classes ViewControllers YourClass 53   Also you can use protocols and other solutions - but this is one of the simplest ones

User · Answer

Probably this kind of situations should only happen at development time  so this might work   -  id myMethodWithVar  id var      NSAssert NO    You most override myMethodWithVar        return nil

User · Answer

Instead of trying to create an abstract base class  consider using a protocol  similar to a Java interface   This allows you to define a set of methods  and then accept all objects that conform to the protocol and implement the methods  For example  I can define an Operation protocol  and then have a function like this   -  void performOperation  id lt Operation gt  op         do something with operation     Where op can be any object implementing the Operation protocol   If you need your abstract base class to do more than simply define methods  you can create a regular Objective-C class and prevent it from being instantiated  Just override the -  id init function and make it return nil or assert false   It s not a very clean solution  but since Objective-C is fully dynamic  there s really no direct equivalent to an abstract base class

User · Answer

This thread is kind of old  and most of what I want to share is already here  However  my favorite method is not mentioned  and AFAIK there   s no native support in the current Clang  so here I go    First  and foremost  as others have pointed out already  abstract classes are something very uncommon in Objective-C     we usually use composition  sometimes through delegation  instead  This is probably the reason why such a feature doesn   t already exist in the language compiler     apart from  dynamic properties  which IIRC have been added in ObjC 2 0 accompanying the introduction of CoreData  But given that  after careful assessment of your situation   you have come to the conclusion that delegation  or composition in general  isn   t well suited to solving your problem  here   s how I do it   Implement every abstract method in the base class  Make that implementation  self doesNotRecognizeSelector  cmd         followed by   builtin unreachable    to silence the warning you   ll get for non-void methods  telling you    control reached end of non-void function without a return     Either combine steps 2  and 3  in a macro  or annotate - NSObject doesNotRecognizeSelector   using   attribute      noreturn     in a category without implementation so as not to replace the original implementation of that method  and include the header for that category in your project   s PCH   I personally prefer the macro version as that allows me to reduce the boilerplate as much as possible  Here it is     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  gt    self length            NSException raise NSInvalidArgumentException format   quot Range    exceeds the length of      lu  quot   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  As you can see  the macro provides the full implementation of the abstract methods  reducing the necessary amount of boilerplate to an absolute minimum  An even better option would be to lobby the Clang team to providing a compiler attribute for this case  via feature requests   Better  because this would also enable compile-time diagnostics for those scenarios where you subclass e g  NSIncrementalStore   Why I Choose This Method  It get   s the job done efficiently  and somewhat conveniently  It   s fairly easy to understand   Okay  that   builtin unreachable   may surprise people  but it   s easy enough to understand  too   It cannot be stripped in release builds without generating other compiler warnings  or errors     unlike an approach that   s based on one of the assertion macros   That last point needs some explanation  I guess  Some  most   people strip assertions in release builds   I disagree with that habit  but that   s another story     Failing to implement a required method     however     is bad  terrible  wrong  and basically the end of the universe for your program  Your program cannot work correctly in this regard because it is undefined  and undefined behavior is the worst thing ever  Hence  being able to strip those diagnostics without generating new diagnostics would be completely unacceptable  It   s bad enough that you cannot obtain proper compile-time diagnostics for such programmer errors  and have to resort to at-run-time discovery for these  but if you can plaster over it in release builds  why try having an abstract class in the first place

User · Answer

The answer to the question is scattered around in the comments under the already given answers  So  I am just summarising and simplifying here   Option1  Protocols  If you want to create an abstract class with no implementation use  Protocols   The classes inheriting a protocol are obliged to implement the methods in the protocol    protocol ProtocolName    list of methods and properties  end   Option2  Template Method Pattern  If you want to create an abstract class with partial implementation like  Template Method Pattern  then this is the solution  Objective-C - Template methods pattern

User · Answer

I usually just disable the init method in a class that I want to abstract   -  instancetype   unavailable init     This is an abstract class    This will generate an error at compile time whenever you call init on that class  I then use class methods for everything else   Objective-C has no built-in way for declaring abstract classes

User · Answer

In fact  Objective-C doesn t have abstract classes  but you can use Protocols to achieve the same effect  Here is the sample   CustomProtocol h   import  lt Foundation Foundation h gt    protocol CustomProtocol  lt NSObject gt   required -  void methodA   optional -  void methodB   end   TestProtocol h   import  lt Foundation Foundation h gt   import  CustomProtocol h    interface TestProtocol   NSObject  lt CustomProtocol gt    end   TestProtocol m   import  TestProtocol h    implementation TestProtocol  -  void methodA     NSLog   methodA          -  void methodB     NSLog   methodB          end

User · Answer

Cocoa doesn   t provide anything called abstract  We can create a class abstract which gets checked only at runtime  and at compile time this is not checked

User · Answer

more of a related suggestion   I wanted to have a way of letting the programmer know  do not call from child  and to override completely  in my case still offer some default functionality on behalf of the parent when not extended    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   The advantage is that the programmer will SEE the  override  in the declaration and will know they should not be calling  super       Granted  it is ugly having to define individual return types for this  but it serves as a good enough visual hint and you can easily not use the  override   part in a subclass definition   Of course a class can still have a default implementation when an extension is optional  But like the other answers say  implement a run-time exception when appropriate  like for abstract  virtual  classes   It would be nice to have built in compiler hints like this one  even hints for when it is best to pre post call the super s implement  instead of having to dig through comments documentation or    assume

User · Answer

Using  property and  dynamic could also work  If you declare a dynamic property and don t give a matching method implementation  everything will still compile without warnings  and you ll get an unrecognized selector error at runtime if you try to access it  This essentially the same thing as calling  self doesNotRecognizeSelector  cmd   but with far less typing

User · Answer

In Xcode  using clang etc  I like to use   attribute    unavailable        to tag the abstract classes so you get an error warning if you try and use it  It provides some protection against accidentally using the method  Example In the base class  interface tag the  quot abstract quot  methods  -  void myAbstractMethod  id param1   attribute    unavailable  quot You should always override this quot       Taking this one-step further  I create a macro   define UnavailableMacro msg    attribute    unavailable msg     This lets you do this  -  void myAbstractMethod  id param1 UnavailableMacro   quot You should always override this quot     Like I said  this is not real compiler protection but it s about as good as your going to get in a language that doesn t support abstract methods

User · Answer

Another alternative  Just check the class in the Abstract class and Assert or Exception  whatever you fancy    implementation Orange -  instancetype init       self    super init       NSAssert  self class      Orange class     This is an abstract class        if  self              return self     end   This removes the necessity to override init

User · Answer

Typically  Objective-C class are abstract by convention only   if the author documents a class as abstract  just don t use it without subclassing it  There is no compile-time enforcement that prevents instantiation of an abstract class  however  In fact  there is nothing to stop a user from providing implementations of abstract methods via a category  i e  at runtime   You can force a user to at least override certain methods by raising an exception in those methods implementation in your abstract class    NSException raise NSInternalInconsistencyException              format   You must override    in a subclass   NSStringFromSelector  cmd      If your method returns a value  it s a bit easier to use   throw  NSException exceptionWithName NSInternalInconsistencyException                                reason  NSString stringWithFormat   You must override    in a subclass   NSStringFromSelector  cmd                                userInfo nil     as then you don t need to add a return statement from the method   If the abstract class is really an interface  i e  has no concrete method implementations   using an Objective-C protocol is the more appropriate option

User · Answer

Can t you just create a delegate   A delegate is like an abstract base class in the sense that you say what functions need to be defined  but you don t actually define them   Then whenever you implement your delegate  i e abstract class  you are warned by the compiler of what optional and mandatory functions you need to define behavior for   This sounds like an abstract base class to me

User · Answer

No  there is no way to create an abstract class in Objective-C   You can mock an abstract class - by making the methods  selectors call doesNotRecognizeSelector  and therefore raise an exception making the class unusable   For example   -  id someMethod  SomeObject  blah         self doesNotRecognizeSelector  cmd        return nil      You can also do this for init

User · Answer

From the Omni Group mailing list   Objective-C doesn t have the abstract compiler construct like Java at this time   So all you do is define the abstract class as any other normal class and implement methods stubs for the abstract methods that either are empty or report non-support for selector  For example     -  id someMethod  SomeObject  blah         self doesNotRecognizeSelector  cmd        return nil      I also do the following to prevent the initialization of the abstract class via the default initializer   -  id init         self doesNotRecognizeSelector  cmd         self release        return nil

User · Answer

Changing a little what  redfood suggested by applying  dotToString s comment  you actually have the solution adopted by Instagram s IGListKit    Create a protocol for all the methods that make no sense to be defined in the base  abstract  class i e  they need specific implementations in the children  Create a base  abstract  class that does not implement this protocol  You can add to this class any other methods that make sense to have a common implementation  Everywhere in your project  if a child from AbstractClass must be input to or output by some method  type it as AbstractClass lt Protocol gt  instead    Because AbstractClass does not implement Protocol  the only way to have an AbstractClass lt Protocol gt  instance is by subclassing  As AbstractClass alone can t be used anywhere in the project  it becomes abstract   Of course  this doesn t prevent unadvised developers from adding new methods referring simply to AbstractClass  which would end up allowing an instance of the  not anymore  abstract class   Real world example  IGListKit has a base class IGListSectionController which doesn t implement the protocol IGListSectionType  however every method that requires an instance of that class  actually asks for the type IGListSectionController lt IGListSectionType gt   Therefore there s no way to use an object of type IGListSectionController for anything useful in their framework

[objective-c] Creating an abstract class in Objective-C

Examples related to objective-c

Examples related to abstract-class