Re: Convenience Methods
Re: Convenience Methods
- Subject: Re: Convenience Methods
- From: Greg Titus <email@hidden>
- Date: Wed, 26 Sep 2007 18:44:07 -0700
On Sep 26, 2007, at 4:59 PM, Jeff Laing wrote:
Sometimes when I'm writing convenience constructors I might write
+ (MyClass *)myClassWithFoo:(int)f
{
return [[[self alloc] initWithFoo:f] autorelease];
}
where "self" is, of course, the class. A good reason to do that is
that it means that a subclass only has to override -initWithFoo: in
order to make +myClassWithFoo: work as expected.
I'm still undecided on whether this is a good thing or not.
After my Dog's example, it occurred to me that my uneasiness was
because of
an encapsulation thing again.
When you say "a subclass only has to override -initWithFoo:", how
did you
*know* that the superclass had done the right thing in its
myClassWithFoo: ?
Subclasses shouldn't depend on implementation detail in their
superclasses,
should they?
This is just my opinion, but I think that YES, absolutely, subclasses
should know and depend upon the implementation details of their
superclasses. To assume that you don't have to know how your own
superclass works is taking object-oriented theory too far, and just
leads to overly defensive programming, which means more redundant
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
less code in your subclass, and the overall effect is that you _can_
know what your superclasses are doing because as a whole there is
much less code to understand.
At framework boundaries the argument gets a little different. There I
think you need to take extra care with documentation and defensive
programming. (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.)
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.
If you don't want to depend upon the internals of a class then you
shouldn't be subclassing it. You should be using a Composite pattern.
Embed an instance of the other class as an instance inside your own
and pass along messages to it. Apple advises using this pattern
rather than subclassing for class clusters:
http://developer.apple.com/documentation/Cocoa/Conceptual/
CocoaFundamentals/CocoaObjects/chapter_3_section_9.html
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. Patterns like delegation keeps the number of
subclasses you need to write yourself to a minimum. The vast majority
of your own code ought to be a single step away from one of a few
"hub" superclasses: NSObject, NSView, NSWindowController. That means
you won't have to know the details of lots of superclasses above you
- there just aren't that many to learn.
If you wrote all the code then sure, you can be confident because
you can
look at it. But speaking as someone who works on a development
team that
works on *millions* of lines of code, I've gotten a lot more
paranoid about
assuming things about "the other guy" making changes that he's sure
won't
affect anyone...
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.
These days the code base on my project is only around 300k lines. But
I think that the exact same functionality could easily be twice as
many lines of code if we stressed OO-orthodoxy and redundant safety
over clean and minimal. And I have been in the several million plus
lines situation for years at a time in my former life as a
consultant, so I do have experience with quite large code bases.
-- Greg
_______________________________________________
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