On Aug 25, 2006, at 4:31 AM, Jerry W. Walker wrote:
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.
My understanding, after reading the link Shawn suggested <http://
developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/
Articles/chapter_4_section_7.html#//apple_ref/doc/uid/TP30001163-CH7-
BAJJABHJ> (btw, Shawn, thanks!), is that categories are the mechanism
behind implementing informal protocols, which form the backbone of
Cocoa's delegation, so I guess that's a fourth advantage to having
categories.
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.
If taken to an extreme, I completely agree with you, but one can view
such utility classes exactly for what they are, namely, providers of
a service. In that sense, it's perfectly fine to have objects that
have no internal state but exist only to provide services to other
objects.
Not being familiar with WebObjects, I can't comment on whether the
proliferation of such classes when Apple transitioned from WO in Obj-
C to WO in Java was warranted or whether it was merely due to poor re-
design.
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.
Another danger I see with categories, beyond security and debugging,
is that they may be responsible for bloating a class with too many
responsibilities or with responsibilities that have no business being
in that class. I'm a big fan of the idea that classes should have the
smallest number possible of clear and well-defined responsibilities.
In that respect, it might be argued that adding email address
validation to what is considered a general-purpose String class is
tantamount to adding responsibilities that should not belong to that
class. If we're adding email validation, why not also add
hyphenation, grammar-checking, and translation to and from a number
of other languages? (Obviously, I'm exaggerating.)
If one is not writing a library or framework, using categories to add
extra functionality to general-purpose classes costs only one's own
time and money. But if one's writing a library or framework for
others to use, I think it's essential to keep the functionality of
each class as tightly defined as possible, in which case having
separate utility classes makes perfect sense to me.
Wagner
============
Heisenberg may have been here.
_______________________________________________
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
