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/pandersson%
40gmail.com
This email sent to email@hidden
