RE: Convenience Methods
RE: Convenience Methods
- Subject: RE: Convenience Methods
- From: Jeff Laing <email@hidden>
- Date: Thu, 27 Sep 2007 12:35:33 +1000
> From: Greg Titus [mailto:email@hidden]
> This is just my opinion, but I think that YES, absolutely,
> subclassesshould know and depend upon the implementation details of their
> superclasses.
At this point, we part ways on the theory but thats fine.
> To assume that you don't have to know how your own
> superclass works is taking object-oriented theory too far, and just
Um, this strikes me as really hard to defend. Encapsulation is all about
being able to wrap up "how" a class does its thing inside that class, and
just worry about "what" it does.
> leads to overly defensive programming, which means more redundant
In this particular case, we've ended up with what I'd call "overly defensive
programming" in the SUPERCLASS because it has no idea whether someone will
come along and subclass it, so it complicates up its calls to alloc. Thats
just pushing the problem from the guy who knew he wanted to subclass into
the guy who didn't know.
Thats no big deal, except that it becomes mandatory to do "best-practices"
when defining your classes since you can never tell whether you'll be
subclassed a year from now. And the original poster wanted to know what was
"best practice", returning id or myclass*.
> code. Not to mention the belief that you can just ignore how your
> superclass is implemented leads to all sorts of bad code and
> complacency. If you know what your superclass is doing, you write
I dont understand how relying on my superclass to honor its interface
contracts results in complacency or bad code. I'd be interested in more
faulty examples here.
> (By a framework boundary I mean where your superclass is
> in a different framework than the subclass. A subclass of NSView in
> your own application, for instance.)
which is, of course, why Apple recommend against subclassing NSString, etc.
> But certainly in your own "Animals" framework, you better know how
> your Animal superclass works, and you ought to take advantage
> of that fact to write as little code as possible.
You are saying that if Dog is part of the Animals framework, I can code it
one way, but if I move it to another framework (which happens solely because
of organisational differences on my development team), I should code it
differently?
> Apple advises using this pattern
> rather than subclassing for class clusters:
I don't see Animal as a class cluster here.
> Finally, the design of Objective-C and Cocoa tends to lead to fairly
> flat and broad inheritance hierarchies. There aren't that many deep
> subclasses of subclasses of subclasses like you tend to find in some
> other frameworks.
I think I understand what you are saying here, and the conclusion is
primarily that I still need to work on removing the C++isms from my thinking
about Objective-C.
I have another pet project which had developed a class hierarchy something
like:
basic_plugin
file_format_plugin
format_1_plugin
format_2_plugin
processing_plugin
process_1_plugin
process_2_plugin
The 'basic_plugin' is a class that I use across all my applications, but it
isn't in a framework, the source code is just copied into each application
(along with the basic_plugin_manager that handles plugin folders etc at
application startup). file_format_plugin and processing_plugin are both
specific to the current application, but neither of them want to concern
themselves with the implementation of the basic_plugin logic, they just want
to populate the standard entry methods and know that the level above them do
the right thing. Similiarly, some instances of format_1_plugin, etc are not
built as part of the application at all, since they expect to be something
developable by a 3rd party. I can definitely see where adding in common
superclasses under 'processing_plugin' for plugins that do similiar things
is also quite likely.
Do those lowest-level plugins really need to know about the internals all
the way up the tree, or just up one level? Or can they rely on the theory
that says "my superclass knows what he's doing and honors his interface
contracts". Which would imply that "if the method says it returns
basic_plugin*, then thats all it returns". Clumsy, not quite what you'd
like, but 100% explicit and predictable.
> Patterns like delegation keeps the number of
> subclasses you need to write yourself to a minimum.
... but are irrelevant to the sorts of problems I'm thinking about.
> of your own code ought to be a single step away from one of a few
> "hub" superclasses: NSObject, NSView, NSWindowController. That means
I'm somewhat surprised that most examples that people wheel out to discuss
why Cocoa class hierarchies are shallow tend to be user-interface related.
There are other domains of problems that *do* have deeply nested hierarchies
for application specific reasons that a shallow hierarchy+nesting do not
fit.
> If he reimplements a superclass and doesn't check to see whether any
> subclasses were depending upon the previous implementation,
> I'd bitch at "the other guy" until he fixes it.
No, he didn't reimplement the superclass. He looked at a class that had a
method of the form
+ fooFromBar:(Bar*)b
{
Foo *foo = [[[self class] alloc] initWithBar:b];
}
and because some other part of the system told him that we was spending a
significant amount of time doing that particular function (lets not get
distracted onto algorithm design, he's making a mistake, remember), he sees
that that [self class] seems a bit wasteful. So he changed it to
+ (Foo*)fooFromBar:(Bar*)b
{
Foo *foo = [[Foo alloc] initWithBar:b];
}
and then he tested his changes to death in his own test harnesses, none of
which exercised "subclassing Foo". How does he tell that someone else
depended on that fairly subtle behaviour?
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden