Re: Category or Protocol? (sidetrack)
Re: Category or Protocol? (sidetrack)
- Subject: Re: Category or Protocol? (sidetrack)
- From: Andrew White <email@hidden>
- Date: Wed, 20 Apr 2005 10:34:40 +1000
An interesting question, Jeff. Here's my take on it.
(apologies for the long quote...)
Jeff Laing wrote:
In C++, its mandatory to re-declare the methods of your superclass that you
override, and in practice, I've found that that makes for less bugs of one
sort, and more of another.
Objective-C doesn't have this requirement and I'm curious as to whether any
experts want to comment on whether its "good practice" to omit the
overridden method declarations.
On the plus side, its a lot easier to look at a header file and decide what
sorts of things the class must do. I *think* it also enforces that you
actually implement the overridden method at compile time, but I'm away from
my Mac so I can't confirm that.
Such decisions are made at link time. There's no requirement in C++ that a
method be implemented unless it's linked to, and because the implementation
could be in any file there is no easy way for the compiler to check.
However, the linker will complain about missing methods.
Objective-C can warn directly about this because each @implementation
section matches exactly one @interface, thus the @implementation can easily
check for missing methods.
On the minus side, well, its more typing that is presumably prone to subtle
typos, especially if you're like me and populate the .h, then cut/paste your
method prototypes across to the .m file and then fill it out. If you
copy/paste from the online documentation to set up your .h prototypes you're
fine, but if you then edit them into shape (to match local coding
conventions) and manage to lose a character in a method name, it can take
forever to find.
In Objective-C, I don't duplicate declarations in the interfaces of children.
(1) It introduces the problems described above. A slight spelling change
can cause a method that should be an override to be a completely different
method without any compiler warnings.
(2) I find it easier to think of the interface as the union of the
specifications. I need to chase back up the inheritance tree for all the
methods anyway (in C++ or Obj-C), so little is gained by double-declaring
methods (in child + parent).
(3) When looking an an implementation file, it's very easy to tell which
are overridden methods - they don't have a matching entry in the header
file (and don't cause "undeclared method" compiler warnings). In C++, it
can be difficult to tell at a glance whether a method is new or inherited
and overridden.
(4) While adding a redundant method declaration does not logically change
the header file, it does change it syntactically and thus require
recompilation of all associated implementation files. Ideally, only
changing the interface should require recompilation of other files;
changing the implementation should require recompilation only of the local
source file.
Regarding (4), in both C++ and Obj-C there is value in creating abstract
base classes with no data members that capture only the public interface.
Implementation details are provided by a derived class. Because both C++
and Objective-C require that data members are exposed in the header file,
this allows manipulation of data members (in the derived class) without
changing the interface. This provides both design-time and compile-time
advantages.
Compared to C++, Objective-C does have some quirks in this regard. The
first is that you can't create a true abstract base class without the
compiler complaining of unimplemented methods, so some form of default
implementation needs to be provided.
In contrast, C++ requires *all* methods (public or otherwise) to be
declared in a class interface. Objective-C categories allow methods to be
created on the fly. Sometimes it's easier to fill out the public interface
and data members in the main declaration and then use categories to add
other methods as required.
--
Andrew White
--------------------------------------------------------------------------
This email and any attachments may be confidential. They may contain legally
privileged information or copyright material. You should not read, copy,
use or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden