On Jul 8, 2009, at 10:16 PM, Jeff Laing wrote:
No, it doesn't. It would in fact violate the encapsulation principle
if your -dealloc method required your accessors to not rely on
certain
state.
The "ability to override accessors violates encapsulation" because
it adds additional restrictions to the accessor that the superclass
is not aware of.
If you can't write your override of an accessor in such a way that
you don't place additional restrictions on the superclass, you
shouldn't do it. Because its not possible for you to make the
assumption that "the superclass will never care" - without making
(unjustifiable) assumptions about the superclasses implementation.
My response was to someone presumably writing about Design Patterns,
I believe who wanted to know what was the best approach to take. My
opinion is that you should *not* assume that subclassers are idiots,
because it doesn't matter how much bullet-proofing you put in,
there's always going to be a worse idiot come along. Better to make
them all have to work carefully, than to avoid using things *they*
might screw up.
I'll agree with Jeff on his points here.
In my personal situation, I'm the only person working on code at my on-
the-side home business.
But, although I'm the only author, I have never had the need to
subclass any accessors. And, I've always called accessors from within
init and dealloc (as well as copyWithZone: and encodeWithCoder:).
Such code is in shipping apps (Mac OS X and later iPhone OS) starting
in 2004. The benefits of bottlenecking code through accessors like
this is it can really help in debugging. I know for a fact that every
access to a property does so via one line of code; easy to instrument
and only one breakpoint needed.
However, I also know that subclassing accessors may be needed. And in
those cases, I'm going to assume that the coder(s) will understand the
pitfalls.
In my opinion, this is one of those "all depends" situations.
___________________________________________________________
Ricky A. Sharp mailto:rsh...@instantinteractive.com
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
