Post #112,726
8/4/03 10:20:45 PM
8/4/03 10:30:10 PM
|
IS A vs HAS A
One key question I always ask when designing classes and figuring out inheritance is "Is the child object an IS A relationship to the parent?" Most of the time, the answer is no.
I have a guy at work right now that wants to inherit everything from a generic logging class called ILOG. I've been trying to explain that server objects HAVE logging, but they aren't logging. He doesn't agree.
But the IS A/HAS A question, I think, is a good way to figure out if you need to inherit or not.
Basic OO 101.
Glen Austin
Edited by gdaustin
Aug. 4, 2003, 10:30:10 PM EDT
|
Post #112,732
8/5/03 8:16:32 AM
|
Quite.
While working with an incomplete object API with implementation mistakes, we often have to decide when adding a new class if we're doing an IS A or a HAS A interface. The distinction is most useful.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #112,741
8/5/03 9:29:59 AM
|
I missed that course
Basic OO 101. No, literally ... I haven't taken any programming courses since Turbo Pascal in '81. So while I've picked up most of the techniques I don't know the terminology. When you say "IS A/HAS A" ... what's that mean? I think I get it, but I'm not sure. ===
Implicitly condoning stupidity since 2001.
|
Post #112,743
8/5/03 9:36:46 AM
|
Shorthand for relationships
Circle IS A(n) Shape - any place you can use a shape, you can use a circle
Database HAS A Connection - a database isn't a connection, but it uses one
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #112,745
8/5/03 9:40:20 AM
|
Re: Shorthand for relationships
Translate into message passing parlance?
-drl
|
Post #112,756
8/5/03 10:51:07 AM
|
snicker
"HAS A": an object passes messages to another object.
"IS A": an object is silent. It already is the other object.
I'm gonna go build my own theme park! With Blackjack! And hookers! In fact, forget the park!
|
Post #112,748
8/5/03 10:02:12 AM
|
ISA/HASA are good for a first approximation
but don't always tell the whole story. ISA in particular carries meanings from the real world that don't always translate well in the software world. For example: a square ISA rectangle, but inheriting a square from a rectangle might not be a good idea (there is a square/rectangle debate that regularly breaks out on comp.object every six months).
Furthermore, we use ISA in different ways. My car ISA Saturn, and a Saturn ISA car. The first ISA relates a individual car to a class of cars. The second ISA relates a class of cars to a larger class of cars. The latter is an inheritance relationship, and the former is a instantiation relationship.
All I'm saying is that ISA/HASA is a good first cut, but don't get hung up them when you get down to nitty-gritties.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #112,749
8/5/03 10:07:20 AM
|
So what does it get you?
This came up in an "Extends vs Implements" debate. As I'm not a Java programmer, I'm not sure what this implies. Are they actually different constructs or just different ways of conceptualizing the process?
===
Implicitly condoning stupidity since 2001.
|
Post #112,751
8/5/03 10:25:51 AM
|
Specialization vs. Generalization
A Saturn IS A Car is a specialization relationship, meaning that a Saturn is a special kind of car.
If you start with a car base class, assuming you had functions like honk, turn left, turn right, stop, accelerate, etc. Then you could create a Saturn, but use it as a car. You could create any kind of car. Kind of like when you're at the car rental agency. Any car will do, as long as it holds you.
However, if you require detail at the specialization level, then you may want to know specific details of the car, like where the transmission dipstick is, or how many RPMs or horsepower a Saturn has (not many).
I don't see much of "A Car IS A Saturn", except in broken inheritance. At this point, you're trying to hide the details the base class, in an inherited class. This is usually a bad idea. The problem there is that you still have to implement the base class function, but then you have to make it do nothing. At the point you do this, you drive the people using your classes nuts. ("What! This used to work!)
You want the more general classes higher in the heirarchy, and the more specific down lower.
My 2 cents.
Glen
|
Post #112,759
8/5/03 10:59:43 AM
|
Code
# Code showing my_car ISA Saturn ISA Car\n\nclass Car; end\n\n# A Saturn ISA Car \n# (Specialization or Inheritance ... a Class named Saturn\n# inherits from the class named Car)\n\nclass Saturn < Car; end\n\n# My car ISA Saturn \n# (Instantiation ... An instance of a Saturn class is created\n# and bound to the name "my_car")\n\nmy_car = Saturn.new --
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #112,762
8/5/03 11:22:29 AM
|
Thanks, but what would HASA look like?
===
Implicitly condoning stupidity since 2001.
|
Post #112,807
8/5/03 5:31:03 PM
|
HASA
class Server
{
LoggingClass myLog;
};
Server myServer;
myServer.myLog.Log( LoggingClass::LOG_DEBUG, "Writing to the Log" );
The End.
|
Post #112,810
8/5/03 5:53:29 PM
|
See, that's where I always get tripped up
People have such heated debates about differences between things (ISA/HASA in this case) and pros/cons thereof that I assume there must be more to it than it sounds like; that I must be missing something because I never took the classes where they taught the terminology.
These two examples show different ways of doing something. It seems clear (to me) that they would work differently, and each is appropriate in its own way. I don't understand how anyone could say that one is "right" and one is "wrong". It depends on what you're trying to do.
Actually this feels like something someone wrote in here a little while ago: (Can't find the link.) It seems so obvious It didn't occur to me anyone would have bothered to name it.
===
Implicitly condoning stupidity since 2001.
|
Post #118,383
9/21/03 5:36:50 PM
|
There is a point to naming the useless stuff
Two points in fact.
The first is that if you don't name it, then you have to explain it every time the difference matters. (That or else get tripped up because you meant one thing and someone heard the other.)
The second is that some people think it impressive to know a lot of made-up words.
Sometimes it is hard to tell where the difference is between words that exist for the first and the second reasons. However I have encountered enough people with serious confusion about when they might want to have is-a vs has-a that I consider having phrases that distinguish that to have real value in technical communication.
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #118,428
9/22/03 10:37:14 AM
|
Clarification
I wasn't suggesting that ISA/HASA are the same thing. Quite the opposite: I think they are so fundamentally different that I don't understand having this distinction. It seems to me like having a special term to define the difference between variables and pancakes. They're just different things.
Okay, I'm exaggerating. But are there people who know both of these methods that need it pointed out that they're different?
===
Implicitly condoning stupidity since 2001.
|
Post #118,500
9/22/03 10:04:26 PM
|
Yes
More specifically, I have seen people propose designs where people reach for is-a in lots of places where they really needed to reach for has-a. You can virtually see the lightbulb go off when you explain the difference and explain why they really need the other.
The biggest contributing cause that I see for this are people who think that inheritance is good because it is OO and therefore they should use inheritance. But inheritance traditionally is an is-a relationship - that isn't the right hammer when you have a has-a relationship to model.
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #118,558
9/23/03 10:51:27 AM
|
That's why I shouldn't be a teacher
There are some things that just seem so clear to me I don't even understand the question. It's like, "What part are you missing?"
===
Implicitly condoning stupidity since 2001.
|
Post #112,763
8/5/03 11:47:35 AM
|
The example of a stack (see post above) is a good one
As to when to not use inheritance. A stack while you may think of it as a specialization of a List (Vector in Java) it is a bad candidate for inheritance because it actually offers a much smaller set of functionality then a regular list. Therefore, if stack inherits from Vector everything that Vector offers (including removing an arbitrary elemen and deleting an arbitrary element) is now part of the public interface of your stack and can be called.
Inheritance is best used when you the descendent class is the parent plus. For example, a SortedCollection extends OrderedCollection in Smalltalk.
|
Post #112,752
8/5/03 10:31:43 AM
|
My car is a Saturn
Is actually not an inheritance relationship.
It is an instantiation of a specific class (Saturn) of a base class (car).
So My car is a Saturn isn't inheritance.
Unless you want to create a newspecialized Saturn car class, with new properties/functions like (This was MY CAR ( A Saturn )):
WornCarpets
FoodPasteOnBackseat
RadiatorLeak()
CrackWinshield()
etc.
;-)
Glen Austin
|
Post #113,310
8/9/03 2:07:51 PM
|
hierarchies and the real world
but don't always tell the whole story. ISA in particular carries meanings from the real world that don't always translate well in the software world.
Indeed. The real world is not tree-shaped for the most part when you get right down to it. Hierarchies may be a convenient mental model for analysis (for some people), but if you base your software model on it you will often be bitten in the long run. The bottom line is that almost nothing I can identify in the real business world is truly hierarchical in the longer run.
The biggest problem (but not the only) is that tree leafs assume mutual exclusiveness of some properties. If you subclass vehicles into cars and boats, you assume that something cannot be BOTH a car and a boat. But when marketing comes out with one you are hosed and have a lot of reshuffling of your methods and attributes that risk breaking existing code. Same with "data structures". If you use a class that is a "stack", you may later want to inspect or use the same data in non-stack ways. If you follow this to its logical conclusion, then you will end up pushing all possible data structure operations to the top of the hierarchy, and end up re-inventing a (non-relational) database. Using trees to manage or limit what attributes and behavior a thing can get is a dead-end.
________________
oop.ismad.com
|
Post #113,325
8/9/03 3:51:57 PM
|
Nonsense
The bottom line is that almost nothing I can identify in the real business world is truly hierarchical in the longer run. Maybe you can't find them because you're blind. Let's see, the whole of the web is a Tree. The html that you are perusing is a Tree. The threads that you are responding to are a Tree. One need look no further than to the very concept of a Document to find them. Indeed, the Real World is chalk full of Trees. What you actually mean to say is that (a). you don't think Types can be structured on a hierarchical basis - which is totally different to a rant that says that trees don't exist; and (b). you think a Relational Model more closely resembles the real world - not noting that relational design is a hard process that is fraught with many complexities. If you subclass vehicles into cars and boats, you assume that something cannot be BOTH a car and a boat. That's just a diamond shape of inheritance which is addressed by multiple inheritance. You don't give any cause to believe that an imperative scheme broken down along procedural boundaries is any more adept at sharing code betwixt the car data structures and boat data structures. You now have a car, a boat and a car-boat data structure or you have a massive data structure that handles every variation that you possibly throw at it. Just because the methods get wrapped up in the object, this does not make it any more susceptible to problems of combining data structures. The only difference between what you propose and OO is that you don't encapsulate the methods within the data structures. Which means all your procedures have to cope with all the variations.
|
Post #112,770
8/5/03 12:09:43 PM
8/21/07 6:36:01 AM
|
Not quite that simple
But it depends on the language.
For instance, C++ has private inheritance. This means "is implemented in terms of". For your logging thing privately inheriting loggability into stuff might make sense. Especially since your methods want access to the logging but you don't want clients playing with it.
In a dynamic language - inheritance is primarily used to share code - not so much for isa type stuff. Of course here delegation is simpler to implement. The rigidity of interfaces doesn't really exist - you need only implement as much interface as your client requires. Plus, its trivial to put an object in between and forward the messages to different objects. ie you can do something like
doesNotUnderstand: aMessage
delegates do: [:each | (each respondsTo: aMessage selector) ifTrue: [each perform: aMessage selector withArguments: aMessage arguments]]
and to be complete
respondsTo: aSelector
delegates do: [:each | (each respondsTo: aSelector) ifTrue: [^true]].
^false
This gives you the functional equivalent of multiple inheritance using delegation.
I do notice that I use inheritance much less in the dynamic languages than in the static ones. Inheritance is practically the only tool you have in java. Delegation is a pain to implement if the interface is very large at all because you have to write the forwarding messages all yourself.
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #112,774
8/5/03 12:26:10 PM
|
Thing I love/hate about smalltalk
doesNotUnderstand: aMessage
delegates do: [:each | (each respondsTo: aMessage selector) ifTrue: [each perform: aMessage selector withArguments: aMessage arguments]]
and to be complete
respondsTo: aSelector
delegates do: [:each | (each respondsTo: aSelector) ifTrue: [^true]].
^false I can never tell if it's pseudo-code or the real thing. ===
Implicitly condoning stupidity since 2001.
|
Post #112,777
8/5/03 12:41:34 PM
|
Similar to Python in that fashion
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #112,779
8/5/03 12:50:32 PM
8/21/07 6:36:13 AM
|
Its real
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #112,781
8/5/03 12:57:38 PM
8/21/07 6:36:18 AM
|
Forgot to mention: key driver is "substitutability"
isa implies I can provide one of these when it wants one of those.
ie - if the client expects a car - I can give it a Saturn, or a Chevy (a Ford wouldn't quite do I think :-P )
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #113,312
8/9/03 2:12:31 PM
|
Techies at Hertz
"I know you wanted a Cadillac, but polymorphism dictates that a Chevy Sprint is perfectly substitutable for one."
________________
oop.ismad.com
|
Post #113,327
8/9/03 3:53:19 PM
|
And if your Table or Data Structure is...
...not capable of handling a Cadillac, you're also out of luck.
|
Post #113,416
8/10/03 9:19:08 PM
8/21/07 12:45:06 PM
|
Mostly
"I know you wanted a Cadillac, but polymorphism dictates that a Chevy Sprint is perfectly substitutable for one." Sure, unless the client relies on openNorthStarNavigation - then things will go south fast. Of course, if the client does not rely on that feature, then the substitution is fine.
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #113,424
8/11/03 12:03:54 AM
|
Or perhaps that ....
MaxCarCapacity which returns 4 (maybe) for the Sprint and 6 for the Cadillac.
Ask the party of 6 driving 2 hours from Tulsa to Bentonville which object they want...
|
Post #112,805
8/5/03 4:42:32 PM
|
Code sharing vs. polymorphism
In a dynamic language - inheritance is primarily used to share code - not so much for isa type stuff. Of course here delegation is simpler to implement. The rigidity of interfaces doesn't really exist - you need only implement as much interface as your client requires...I do notice that I use inheritance much less in the dynamic languages than in the static ones. Inheritance is practically the only tool you have in java. Delegation is a pain to implement if the interface is very large at all because you have to write the forwarding messages all yourself.
I think you hit the nail on the head here. Inheritance should be about code sharing, but in a static language it's also how polymorphism is implemented. That overloading of inheritance makes it more difficult to for a beginner to design classes properly. I think the trick in Java is to stick with interfaces for polymorphism and use inheritance only for code sharing.
Plus, its trivial to put an object in between and forward the messages to different objects. ie you can do something like...
It's interesting how the next big thing in Java is AOP while along you could do the same thing in Smalltalk with "doesNotUnderstand".
Regards,
John
|
