ISA/HASA are good for a first approximation

Post #112,748 by JimWeirich 8/5/03 10:02:12 AM Reply	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 by drewk 8/5/03 10:07:20 AM Reply	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 by gdaustin 8/5/03 10:25:51 AM Reply	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 by JimWeirich 8/5/03 10:59:43 AM Reply	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 by drewk 8/5/03 11:22:29 AM Reply	Thanks, but what would HASA look like? === Implicitly condoning stupidity since 2001.
Post #112,807 by gdaustin 8/5/03 5:31:03 PM Reply	HASA class Server { LoggingClass myLog; }; Server myServer; myServer.myLog.Log( LoggingClass::LOG_DEBUG, "Writing to the Log" ); The End.
Post #112,810 by drewk 8/5/03 5:53:29 PM Reply	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 by ben_tilly 9/21/03 5:36:50 PM Reply	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 by drewk 9/22/03 10:37:14 AM Reply	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 by ben_tilly 9/22/03 10:04:26 PM Reply	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 by drewk 9/23/03 10:51:27 AM Reply	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 by bluke 8/5/03 11:47:35 AM Reply	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 by gdaustin 8/5/03 10:31:43 AM Reply	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 by tablizer 8/9/03 2:07:51 PM Reply	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 by ChrisR 8/9/03 3:51:57 PM Reply	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.

Welcome to IWETHEY!