Xref: utzoo comp.lang.c++:3377 comp.lang.eiffel:201 comp.lang.smalltalk:1089 Path: utzoo!utgpu!watmath!maytag!watvlsi!fchan From: fchan@watvlsi.waterloo.edu (Francis Chan) Newsgroups: comp.lang.c++,comp.lang.eiffel,comp.lang.smalltalk Subject: Re: Use of inheritance for classification? Keywords: sub-class, super-class Message-ID: <4369@watvlsi.waterloo.edu> Date: 19 May 89 22:19:32 GMT References: <30582@apple.Apple.COM> <6365@brunix.UUCP> <6685@brunix.UUCP> <24537@agate.BERKELEY.EDU> <6743@brunix.UUCP> <26381@watmath.waterloo.edu> Reply-To: fchan@watvlsi.waterloo.edu (Francis Chan) Organization: U. of Waterloo, Ontario Lines: 57 It seems we have a consensus that there are two ways to look at when to sub-classify: 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 if how a message is handled in the sub-class instance is different from that of the super-class instance; e.g. the "LINKABLES" and "BI-LINKABLES" objects handling of say, an "unlink" message. 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. 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. I have some problems with the Car & Honda CRX examples... 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..). It is to provide you with a very clean interface and also the added protection via encapsulation. 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. 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! Well that's my 2 cents worth... Please note, no flames intended if that's what they appear to be. All this is my view point of the sub-classing issue. FLAME-RETARDENT suit is on. Francis Chan