Re: [NEWBIE]: Categories, etc vs subclassing
Re: [NEWBIE]: Categories, etc vs subclassing
- Subject: Re: [NEWBIE]: Categories, etc vs subclassing
- From: Scott Stevenson <email@hidden>
- Date: Wed, 20 Oct 2004 01:24:12 -0700
On Oct 20, 2004, at 1:05 AM, J Tichenor wrote:
from many design articles and books, that subclassing should always
come as the last step. Composition first, then if possible use of
delegation, categories and protocol extensions. Then, if none of those
will work, subclassing. But rarely on cocoa-dev are those other
methods suggested. Almost always subclassing is the first way to go.
Just wondered if my readings were wrong, and the other methods of
extension are far more limited than implied, or if subclassing is just
so much a habit?
Based on what I've seen, many of the questions that come in are
(understandably) the more difficult things to do. They're difficult
because they're usually asking for fundamentally different behavior
than what a given class provides. Fundamentally different behavior
often requires subclassing.
It's not so much that subclassing is bad in Cocoa, as you shouldn't
subclass just because that's what you would do in another framework. In
many other object-oriented language/frameworks, subclassing is the only
way to get anything done.
If categories, protocols, delegation, and Objective-C's
dynamically-typed nature work for a given situation, use those tools
instead because that path will make things much simpler, reliable and
easier to maintain in the future. But there are certain things that
only subclassing can do. I think it just happens that those are things
that people tend to ask about here.
- Scott
--
http://treehouseideas.com/
http://theobroma.treehouseideas.com/ [blog]
_______________________________________________
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