Re: Subclass of NSMutableDictionary hanging
Re: Subclass of NSMutableDictionary hanging
- Subject: Re: Subclass of NSMutableDictionary hanging
- From: Nick Forge <email@hidden>
- Date: Mon, 5 Mar 2007 09:23:09 +1100
On 04/03/2007, at 11:41 PM, Philip Q wrote:
On 05/03/07, Nick Forge <email@hidden> wrote:
How do you define the difference between "has-a" and "is-a" when I'm
extending the features of what is basically an NSMutableDictionary? I
would've thought that that "is-a" NSMutableDictionary, since my class
(which is now a wrapper btw, which works great) has no other instance
(or static) data other then an NSMutableDictionary.
To use an example, say you wanted to implement a stack using an
NSArray to hold the objects.
Your stack class would have an "has-a" relationship with the
NSMutableArray (ie. it would have an internal NSMutableArray as
opposed to a sub-classed, "is-a" relationship) because otherwise you'd
be guilty of 'inheritance for implementation' where you've taken an
NSMutableArray to use a small sub-set of it's functionality, haven't
added anything new, and dangerously leave it open to abuse (eg. users
of your stack class could call -insertObject:atIndex:, violating what
it is to be a stack).
Are you saying that the only reason to subclass is to have different
(of modified) behaviour to pre-existing methods?
The only reason you should sub-class is to provide a different
internal behaviour of a class while allowing the classes to share a
common interface (see: Liskov substitution principle).
Is your "design philosophy" one based in many languages, or mostly in
Cocoa? I'm interested in hearing peoples opinions, since I have a lot
of programming experience, but very little real OOP experience.
Many of the best OO concepts are general and can be applied to any OO
language. Additional features of each language just change how you
implement these concepts.
If you were programming in say, Java, would it be "wrong" to subclass
an equivalent of NSMutableDictionary just to add some custom init and
instance variable accessor methods?
It depends -- do those new methods actually change the functionality
of the dictionary, or do you really just want to abuse sub-classing to
avoid wrapping a dictionary.
I think the question to ask is: are you adding anything new to the
*dictionary*, OR changing the way in which the *dictionary* works?
Well, neither really. After thinking about this for a while, it
dawned on me what you're getting at: encapsulation. As I said I don't
have a lot of real world OOP experience - but it is obvious why I
shouldn't subclass NSMutableDictionary in my situation because of the
principle of encapsulation. I know that that's what you were getting
at, but I wasn't quite "getting" what you were saying.
However, Objective-C provides something that Java doesn't: categories.
Okay, I don't see any circumstances in the near future where sub-
classing of NSxxx data classes is going to be necessary - but can you
give me any links or pointers [ ;-) ] to any info on categories? Is
it something similar to multiple inheritance?
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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