On Aug 25, 2006, at 2:23 AM, Wagner Truppel wrote:
Alan Snyder wrote:
As a result, adding a new method to an interface will require
clients to change their code, even if they're not interested in
actually using the new method. Cocoa delegate clients couldn't
care less and won't *have* to change.
Or you can just define a new subinterface, as in LayoutManager and
LayoutManager2.
Yes, of course, but that's a big kludge, no?
Ian Joyner wrote:
Delegation is distinct from interfaces & far more powerful. It
is part of the runtime as you mentioned, but Cocoa==Obj-C like
JavaVM==Java. Java actually took the concept of interfaces from
Objective-C where they are called protocols.
I never said that delegation and interfaces are the same thing.
I said that delegation can be implemented using interfaces.
IMHO, Interfaces are a poor way to implement delegation; once
fixed they cannot be easily extended without breaking client code.
Well interfaces are just really the poor man's multiple
inheritance, although the argument for interfaces and against MI
is claimed to be theoretical. Thing is that, like Karl says, if
you want to add something to the interface then every implementing
class has to be changed. In practice, it would be much easier, to
add to a real class a default method, so that implementing classes
would not be affected.
Adding default methods to a real class is precisely what the
Adapter pattern does but then it forces implementers to subclass
the Adapter and you lose the freedom to choose the implementer's
superclass.
I'm now convinced that there are real advantages to Obj-C's
protocols as compared to Java's interfaces. Because I'm new to Obj-
C and never gave much detailed thinking to the differences between
protocols and interfaces, I was under the impression that
everything you could do with protocols (in particular, implement
Cocoa's delegation mechanism) could be *easily* done with interfaces.
I've now revised my position. Sure, it's possible to implement the
delegation mechanism using interfaces, but there is at least one
situation which is much more easily handled by Obj-C's protocols
than by Java's interfaces, namely, an after-the-fact addition of a
new method to the delegation protocol. While Java implementations
struggle with kludges or with forcing clients to change their code,
the Obj-C implementation couldn't be any smoother.
After having written WebObjects systems in Objective-C and moving to
Java when Apple translated all of WO to Java, the thing I missed most
were Categories which allowed one to add methods to a class without
subclassing.
Categories provide three conveniences:
* they allow a team to partition a large class into category files
and each contribute only to their own category, yet all be
contributing to the underlying Class.
* they allow the user of a class in a library/framework to
supplement the methods in that class with new methods of his/her own
choosing
* they allow the user to override faulty methods in the existing
library with their own fixes.
Without categories, extensions to classes come in two forms,
subclasses and utility classes. I've never gotten used to, or liked,
the proliferation of utility classes, in which every method is a
class method, that came with the transition to Java. Basically, this
devolves back to procedural programming under the label OO.
For instance, if the vendor supplied String class doesn't have a
couple methods that I really want, say, isValidEmailAddress, or
userNameFromEmailAddress, I can just create a Category file on String
and add these two methods. From then on, I just write "if
(myString.isValidEmailAddress())" rather than the clumsier "if
(StringUtility.isValidEmailAddress(myString))". There's a definite
"tacked on" feel to the latter.
There were obvious dangers to this for both security and debugging,
and I remember spending several hours on more than one occasion
debugging a problem and wondering why a method was not working as
documented, only to find that someone had overridden the method in a
category. Despite that, I also remember the relative OO purity of
coding WebObjects in Objective C where nearly everything I did was
done with a message to an object.
Regards,
Jerry
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
