Re: Apple should get behind Cocoa Java

On Aug 25, 2006, at 8:25 AM, Wagner Truppel wrote:

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

I actually like the idea of common operations on strings being able to be added to a string class. There are many times in any language that a string is used to build another object. In that sense the design pattern is that a String creates the other object, much like a Factory method. Consider in Java, the URL class. It has a constructor URL(String spec). In fact all the constructors require either a String or another URL object, so the String is the basis for building the URL. With categories, we could enhance the basic String class such that we could add the method public URL toURL() to the String class.

What's cool with categories is that you don't actually bloat the base class, but can use the category just within your application. Thus if your app uses lots of URLs or email addresses, the Factory method could be added to the NSString class with a category. In a sense, this is like subclassing, but without the need to change all of your references to your subclass. In fact, since you might be using other frameworks that return the base class, categories allows you to extend the functionality of those frameworks. That's where categories really show their power, since they eliminate the need for glue code utility classes. Since many classes are actually clusters (Factory classes), the real class they return to you isn't always known, which is what can break subclassing & why it is common for Factory classes to be declared final. Categories allows you to add the missing methods without having to rewrite the whole class.

References:
	>Re: Re: Apple should get behind Cocoa Java (From: Wagner Truppel <email@hidden>)
	>Re: Apple should get behind Cocoa Java (From: "Jerry W. Walker" <email@hidden>)
	>Re: Apple should get behind Cocoa Java (From: Wagner Truppel <email@hidden>)