Xref: utzoo comp.lang.c++:3412 comp.lang.eiffel:204 comp.lang.smalltalk:1096 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!sdcsvax!ucsdhub!calmasd!wlp From: wlp@calmasd.Prime.COM (Walter Peterson) Newsgroups: comp.lang.c++,comp.lang.eiffel,comp.lang.smalltalk Subject: Re: Use of inheritance for classification? Summary: Not really... Keywords: sub-class, super-class Message-ID: <329@calmasd.Prime.COM> Date: 23 May 89 07:27:42 GMT References: <30582@apple.Apple.COM> <6365@brunix.UUCP> <4369@watvlsi.waterloo.edu> Organization: Prime - San Diego R&D (Object and Data Management Group) Lines: 238 In article <4369@watvlsi.waterloo.edu>, fchan@watvlsi.waterloo.edu (Francis Chan) writes: > It seems we have a consensus that there are two ways to look at ^^^^^^^^^ > when to sub-classify: No, I would not say that we have reached a consensus. ("1. general agreement, 2. group solidarity in sentiment and belief" -- Webster's 9th Collegiate Dictionary). In fact, we are far from it; the mere presentation of opposing points of view does not constitute a consensus. > > One is the knowledge based approach of sub-classing when there is a case ^^^^^^^^^^^^^^^^^^^^^^^^ > of IS-A or LIKE-A relations between the super-class and sub-class; e.g. > the good old "Dog IS-A mammal" example. > > The other view is the code-sharing approach which promotes sub-classing ^^^^^^^^^^^^^^^^^^^^^ I have some serious reservations about both of these terms. First, the idea that the IS-A hierarchy is restricted to knowledge based applications is not strictly correct. The IS-A hierarchy with its HAS-A relations certainly is a significant part of semantic networks and other forms of knowledge representation, but it has nearly universal applications. The very term "code-sharing" worries me. In object-oriented programming code is NOT shared, *BEHAVIOR* is shared; the mechanism for sharing behavior is inheritance. Let me go back to the case of the frisbee-catching dog that got me going on this topic. In that example, the oringinal poster had a class called "frisb-o-pup" multiply inheriting from both class "dog" and class "frisbee-catcher". My objection to that scheme was based on all of the different behaviors that dogs can perform. That scheme would have separate classes for "frisbee-catching" dogs, "guide-dog" dogs, "shepherd" dogs. It would be further complicated by a sheep dog that was also a good frisbee catcher (on his day off from herding sheep); would that be an instance of the class "frisb-o-shep-o-pup" ? Lets further complicate the scheme. People also catch frisbees, some better than others. How would we represent Joe Blow, a programmer, programming manager, Vietnam veteran, world-class amatuer frisbee player, etc. ? I hope that everyone can see that it would be ridiculous to create a class that inherits from "person", "programmer", "manager", "frisbee-catcher", etc. Joe IS-A person; he *DOES* or *HAS* these other attributes. This may sound like a knowledge representation or knowledge base scheme, but what if the application that we are talking about is the personel system from Joe's company ? Not quite what one thinks of when one hears the term "knowledge base" is it ? > .... > > I guess it all boils down to what your application is intended to do. > If you are doing a knowledge base, then the former sub-classification > scheme seems pretty amenable whereas if you are doing a user-interface, > the latter scheme may be more appropriate. The IS-A hierarchy is totally appropriate for a user interface. What kinds of objects are we dealing with in a user interface ? Windows, buttons, "volume" controls ( like the bell loudness on a MacIntosh ), icons, screen coordinates, etc. A text window IS-A window as is a graphics window; the bell loudness IS-A "volume" control as is the screen brightness control and so on. A user interface is no different, conceputually, from any other application they all have objects that have behaviors and/or attributes. The fact that some of these objects may be more or less abstract than others is really immaterial. In the knowledge representation realm the object-oriented programmer may be faced with the problem of representing philosophical or religious beliefs, which are far from being what most people think of as being "objects" but they can still be represented in the object-oriented paradigm, just as well as cars, trucks frisbee-catching dogs and programmers. My own experience with object-oriented programming is in the area of CAD/CAM systems and the data management systems to support them. While there are some elements of knowledge representation in CAD, as there is in ANY program, it is not a true knowledge representation application. > But in general, it seems > that both type of schemes tend to overlap alot. And if it doesn't you > can make it so by abstracting to an even higher level e.g. BI-LINKABLES > and LINKABLES are sub-classes of LINKOBJECTS and instances of > LINKOBJECTS have a body while instances of LINKABLES have a body > (inherited from LINKOBJECTS) as well as links to the right, etc. Thus, > filling the body would be handled by methods inherited from the > LINKOBJECTS class while linking and unlinking would be handled > specifically by the sub-class methods. Common code pieces (read > common code segments within methods) could be handled as methods > belonging to a super-class. Why is there an alarm bell going off in my head and a sign flashing the word "Kludge" ? This statement really worries me. It worries me because this is NOT the only time or place that I have seen it. In fact, I have seen it all too often. Lets all remember that object-oriented design and programming ALLOWS us to design and write better software; it does not and can not PREVENT us from writting BAD code. > > I have some problems with the Car & Honda CRX examples... You are not alone; I have a LOT of problems with it. > > The very fact that class Car was defined to come in a number of colors, > then that's all the colors any sub-class of Car will have. It is very > constraining, true but that is the whole idea of Object-Oriented > Programming in the first place (or have I got that wrong..). You have it partly wrong. Part of the idea of object-oriented programming is to constrain us to use pre-written classes ( written by the compiler designer, our project team members, or even by ourselves ) correctly. This requires some forethought. Object-oriented programming should (note: *should*) stop or limit the all too common practice of throwing something at the computer and beating on it until it "works"; sort-of. The Car - Honda CRX and the frisbee-catching dog example are very poorly thought out, as is shown by the problems with representing a simple paint job, or a multiply talented pooch. Thought and an appreciation of the problem being modeled are what we need in OOPS, not patches. > > The fact that there are more colors, and that a paint shop can paint > your Car a different color doesn't matter. All that means is that the > specification of Car is incorrect. What you could say is that Car has a > value that is a member of the class CarPaint. Meanwhile the class > CarPaint will specify what colors are available. Higher level classes > should not be specific.... let the sub-classes do that. Be specific > only if you know that all the sub-classes will not affect the value in > any way. > Close, but not quite there yet. Lets agree that all cars have an attribute called COLOR (COLOUR for our friends in the U.K.). Now, what, based upon our common knowledge of cars, can we say about car colors ? First of all we can say that ALL cars have color ( at least I have not seen a totally transparent cars ). From this we can say that the color attribute should be defined on the class CAR rather than on its sub-classes (we may actually define COLOR on some super-class of CAR, like VEHICLE, but for now lets not). Now the question is: should we constrain COLOR or not and if we do, how ? A quick look arround the streets of Southern California tells me that cars can come in all colors of the spectrum. So a VERY broad constraint might be desirable. We could have a VERY large enumerated type called 'color' that would have thousands of color names as its constants, but that would be rather cumbersome. We would have to take into account all of the odd "designer" colors like 'Candy Burgundy Sparkle'; it is a daunting thought to even consider any resonably broad enumerated type for car colors. We can solve the problem by allowing the COLOR attribte for cars to be a simple character string. Now we need to consider another factor about car colors; two- three- and more tone cars are frequently seen. How do we handle this ? The simplest way is to define COLOR as an aggregate, specifically a set, since we would only want "blue" to appear once for each blue car. So how would we deal with the model-T, which came "in any color you want so long as it is black" ? THAT is a job for the sub-class "model-T". "model-T" can have its own color methods that over-ride the more general methods on CAR. These over-ride methods constrain model-Ts to all be INSTANTIATED as black. Note the emphasis on INSTANTIATED; since customizing cars is so common and so easy, methods should be allowed to change the color, upholstery, wheels, etc. To facilitate keeping track of these changes we might consider adding a boolean CUSTOMIZED field to class CAR so that all instances of it and its sub-classes could tell us if they have been modified. Things that are never or very seldom customized, like the frame would not have methods that would allow us to customize them. We could add a CUSTOM-CAR sub-class to CAR that would allow for the really weird ones. We can do a lot of things to improve this class hierarchy definition; there is no one right answer. There are however any number of WRONG answers. Most of the solutions for the CAR hierarchy that have been posted here are wrong. > Most of us are having classification problems because we aren't taught > to program in that mode. If your very first computer language was > object-oriented and you have been using it for awhile (love these > non-specific words), abstraction would probably be the easiest > thing in the world. Global variables ... aieee! Avoid like the > plaque! Modularization is the Law! *mount soapbox* Most of us were never *taught* anything useful ( 1/2 :-) ). The most important thing that anyone ( and I might say programmers in particular ) can be taught is how to THINK. I have seen too much reacting, too much copying what others have done and far too little originality and creative thought on the part of programmers to believe that our university computer science departments are doing a very good job in this area. If your first language was an object-oriented language, you may actually be at a disadvantage; you don't know just how bad things can be ! My first language, 17 years ago, was assembly; believe me, I KNOW how bad it can be. I can appreciate object-oriented programming and the potential which it represents. That potential will only be realized if designers and programmers use it properly, and that requires thought. The bad designs that I have seen here do not so much represent a lack of understanding of the object-oriented paradigm as they do a lack of thought about the consequences of the design decisions involved. My experience with about 3 years of object-oriented programming tell me that OOPS requires more thought than other design and programming paradigms. That increase in thought WILL be worth it. If you spend the time 'up-front' to think about your design, the detailed design and coding of the methods will be easy. Next time you ( that is all of us, not just the author of the posting being followed up here ) have a design problem; STOP. Put the keyboard out of the way. Put the pencil and paper away. THINK. Then put it down on paper as an object model ( you can use the keyboard if and only if you have the necessary CASE software to draw your model on the screen ). See if you have created any problems for youself like the Honda CRX or the "frisb-o-shep-o-pup". If you have, DO NOT try to "patch" it up or find work-arrounds; RE-DESIGN you object model. Start that redesign by going back to step one: THINK. *dismount soapbox* -- Walt Peterson. Prime - San Diego R&D (Object and Data Management Group) "The opinions expressed here are my own."