Re: Class clusters - infinite loop?
Re: Class clusters - infinite loop?
- Subject: Re: Class clusters - infinite loop?
- From: Wade Tregaskis <email@hidden>
- Date: Sun, 26 Jun 2005 11:19:15 +1000
When the specialization is internal - that is, when BigDataHolder
and SmallDataHolder expose identical public APIs, with the only
difference being the private implementation - then using public
subclasses breaks encapsulation. It becomes the caller's
responsibility to decide which of the subclasses are more
appropriate, and to make that decision the caller would have to be
aware of internal implementation details it wouldn't otherwise need
to care about.
That's why I suggested a factory class, which could create the most
appropriate instance based on some given parameters. No, it's not as
elegant as the init methods on the class(es) themselves doing it, but
at least you can cleanly subclass everything - including the factory
class.
I'm not sure what you mean by "bane of extensibility", anyway. I've
extended NSArray and NSDictionary class clusters both ways, by
adding new behavior to the superclass with a category, and by
implementing a new data storage subclass with its own set of
primitive methods. It's not quite rocket surgery.
Perhaps a specific example would help. Most class clusters never
return self from their init methods - they allocate a new instance of
whichever specific hidden subclass they're going to use, and release
self. How then are you supposed to call [super init] (or equivalent)
in your subclass? You can't. Which means you probably can't rely on
any of the superclass behaviour.
*Sometimes* there are secret hidden initialisers that you can call
directly, but as soon as you start poking around in that area, well,
that makes encapsulation just one big joke.
To reiterate my earlier example with NSOutputStream, what I wanted to
do was create a subclass of it which performs a cryptographic
operation on the data as it goes out - a SHA1 hash, for example.
Now, it seems NSOutputStream is a cluster with at least 3 private
subclasses for each of it's three modes of operation. I don't want
to subclass three private classes, or extend them with categories.
The may change in future. Also, I don't need the redundancy. All I
want is the documented public behaviour of NSOutputStream.
Imho a better solution to this is one of two things:
a) Do what I did with my NSOutputStream subclass, which is to
completely reimplement the superclass behaviour and use an internal
reference to another vanilla NSOutputStream to inherit it's
functionality. Gross, but workable. In terms of class clusters,
this is quite an elegant solution - you have a single public class,
which can do whatever it wants internally, without breaking the
ability to subclass or otherwise extend it.
b) Do a behaviour union - have a flag that indicates the internal
behaviour of your class, i.e. merge your private subclasses directly
into the public one. Granted, this isn't an option if performance is
a key issue, or if the private subclasses significantly differ in
functionality (such as, what methods are defined, etc). But it
usually works, and quite nicely. Any of it's main disadvantages -
performance, memory wastage, etc - are going to be pretty trivial; if
you care that much, you shouldn't be using ObjC to start with.
Just my thoughts. I do like classes that automagically do the right
thing, whatever that may be, but I don't think class clusters are the
way to go about it.
Wade Tregaskis (AIM/iChat, Yahoo & Skype: wadetregaskis, ICQ:
40056898, MSN: email@hidden, AV iChat & email:
email@hidden, Jabber: email@hidden)
-- Sed quis custodiet ipsos custodes?
_______________________________________________
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