ssimmons@convex.com (Steve Simmons) (02/21/91)
> From: garry@ithaca.uucp (Garry Wiegand) > Organization: Ithaca Software > Date: 21 Feb 91 07:30:10 GMT > Newsgroups: comp.object,comp.lang.c++ > Subject: Re: Object-Oriented Metrics > pkr@media01.UUCP (Peter Kriens) writes: >> 6. Too many classes. >> ... For example I saw >> a class button with a Help, Shuffle and Play subclass. The >> only thing these classes did was print their name and >> call a procedure. This was much better if the button class >> had an instance variable for the name and action. > I was arguing exactly this point a few days ago with a MacApp fan. > He claimed that overriding a method - by deriving a new class from > "Button" - was *exactly* the most elegant way to program menus in > MacApp C++. > > I argued that creating classes for which there would probably only > ever be one instance seemed syntactically clumsy (in C++). I argued > further that if you instead got involved with pointers-to-functions > as part of the Button instance data (as Peter suggests) then you've > fallen back into the plain-C style of being object-oriented and thus > C++ hasn't done you much good. Just to add some gasoline to this fire.... The purpose of a base class and a subclass is that there are some operational equivalence between the two. That is, there is a common set of identical operations that can be performed on the objects. If the operations of one class is a superset of another, then that class should be a derived subclass. If there is just an intersection of both classes, then it would be nice to derive the two classes from a common base class, if possible. My point is the following... Don't base the need for the class definitions on the number of instantiations.... Base the need on the number and type of operations to be performed on that class.... In some cases, I have a base class that is never even instantiated, only its derived classes are instantiated. This allows me to share interfaces among many classes.... Your argument is fair about it being a waste when all of the operations were the same and only the data in one member was different.... However, reality is that TIME WILL TELL... Some of the derived classes may sooner or later need unique primitives... Remember you write object oriented for the future with the expectation that the code will change.... Do I practice what I preach.... most of the time.... but I got deadlines like everyone else... Thank you. Steve Simmons