Re: Inheritance guidelines.
superheathen@yahoo.ca wrote:
While I think I have a reasonable grasp of C++ in general, I've never
really used it more than a convenient C. as such, I'm finding very
basic OO confusing, not so much the concept, but how everything should
be laid out in practice.
One of those is deciding whether or not a class should be inherited
or declared as an object in the class.
note: this isn't isn't a specific problem, just making pseudo code as
an example.
class RootProgramClass : public ConfigClass, public Window
{
}
vs.
class RootProgramClass
{
ConfigClass config;
Window window;
}
The only reason for public inheritance is to extend the class from
which you inherit. For example, you have a generic Window that does
not really do much, only knows how to report its own position, say,
and has a bunch of virtual functions to respond to some system
"messages", then any window you create will probably be descending
from that type... So, according to very early teachings on OOD,
the relationship between your CustomWindow and a generic Windows
exists and it's the "is-a" relationship. CustomWindow "is-a" Window.
Or, you have some kind of extended configuiration class that doesn't
just keep your configuration (and overrides some generic ConfigClass
behaviour), but also provides additional elements, like storing the
configuration settings somewhere special (like Internet). Then you
basically extend your ConfigClass, and the CustomConfigurator "is-a"
ConfigClass.
Now, speaking of your concrete example... Considering the names of
the classes, I'd probably go for the latter.
What is the purpose/functionality of 'RootProgramClass'? While you
didn't specify it, if I just suppose that it's like a singleton that
keeps some important things while your program is running, if it's
like what is often called "the Application object", then the program
"has-a" config and "has-a" window, but it isn't any of those things.
As you can see "is-a" and "has-a" are two fundamental types of entity
relationships in a design. NewsgroupReader "is-a" InternetUser, and
FtpUploaderDownloader "is-a" InternetUser. They share some common
traits and functionality, probably. ElectricCar "has-a" motor, and
at the same time ElectricCar "is-a" vehicle...
How about appropriate use of constructors?
Huh?
something tells me a
constructor taking arguments just to pass onto an inherited classes
constructor, to pass onto the final classes constructor, to initialize
the classes variables, isn't very good design. Are there ways to avoid
this mess and allow the programmer to initialize an double inherited
classes variables neatly.
Methinks you're approaching it from the wrong side. Don't design
the software or class hierarchy from the POV of using constructors.
Design from the POV of entity relationships. Design from the POV
of interfaces. Essentially, you need to say, "who and how is going
to use my class[es]?" Then you will have the initial layout of your
model represntation. Then you take a look at the implementation of
that first layout, and probably figure out the other pieces of the
framework (every solution has some kind of framework, even if it
doesn't name it that). Then you just keep going through the design
iterations until you have it finalized. By that time you will
probably have it half-implemented.
these are all newbish questions and it shames me to ask them,
unfortunately I'm nothing more than a hobbyist so don't have the
benefit of university level courses, etc.
any resources on good OO design, etc. would be appreciated.
Try 'comp.object', OOD is their very topic.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask