About Inheritance design

[Jonathan Bartlett]

A few things:

If name and price are the ONLY things changing, it seems silly to make
multiple classes. Just have one class, Weapon.

w = new Weapon("Rifle", 20);

If you have other variance that would really call for inheritance, it is
best to keep the implementation in the subclasses.

For example, if later you decided that price would be based on more than
just the class, and more than just a single variable (like pricing based
on some sort of formula), then your "price" integer becomes wasted
baggage in your new class.

For as long as possible, you should put delay putting actual variables
in base classes.

Jon

 

[Tony Johansson]

Hello!!

Assume we have the following a base class called Weapon and three derived
classes called
MooseRifle, Winchester and Shotgun.

These weapons have the followings attributes a name and a price. So I would
be able to ask a weapon object about
the name and the price.

So there must be a getName that return a string and a getPrice that return
an int. The price and the name is set in the c-tor for each derived class.

I ask you where do you suggest to place the attribute price and name and the
methods getName and getPrice?
My suggestion is to put these in the Weapon class together of course with
the getName and the getPrice because the derived classes would inherit
everything from the base class Weapon. Do you agree.?

A question here?. This would make the Weapon class a concreate class and not
an abstract class. But it seems strange
to be able to create an object of class Weapon. An object of class Weapon
doesn't have any price and have no name it's only the object of the derived
classes that have price and names.

It would be rather meaningsless to put in a pure virtual funktion in the
Weapon class just to make the class abstract.

Give me a comment about this.

Many thanks

//Tony

 

[Victor Bazarov]

Assume we have the following a base class called Weapon and three derived
classes called
MooseRifle, Winchester and Shotgun.

These weapons have the followings attributes a name and a price. So I would
be able to ask a weapon object about
the name and the price.

So there must be a getName that return a string and a getPrice that return
an int. The price and the name is set in the c-tor for each derived class.

I ask you where do you suggest to place the attribute price and name and the
methods getName and getPrice?
My suggestion is to put these in the Weapon class together of course with
the getName and the getPrice because the derived classes would inherit
everything from the base class Weapon. Do you agree.?

Given certain assumptions (like the const-ness of the price and the name),
I do. Then again, you didn't provide enough information, and that's why
I have to resort to assuming.

A question here?. This would make the Weapon class a concreate class and not
an abstract class. But it seems strange
to be able to create an object of class Weapon. An object of class Weapon
doesn't have any price and have no name it's only the object of the derived
classes that have price and names.

Seems reasonable.

It would be rather meaningsless to put in a pure virtual funktion in the
Weapon class just to make the class abstract.

Why not? If Weapon has to be abstract, make its destructor virtual (and
you actually should, if Weapon is to be used polymorphically) and pure,
while providing its implementation.

V

 

[Howard]

Hello!!

Assume we have the following a base class called Weapon and three derived
classes called
MooseRifle, Winchester and Shotgun.

These weapons have the followings attributes a name and a price. So I
would be able to ask a weapon object about
the name and the price.

So there must be a getName that return a string and a getPrice that return
an int. The price and the name is set in the c-tor for each derived class.

I ask you where do you suggest to place the attribute price and name and
the methods getName and getPrice?

In the base class (Weapon). You could make the member variables protected,
and the accessors public. Then just have the constructor for each derived
class set the values for the price and name. Alternatively, you could skip
storing the name and price in variables altogether, and simply use virtual
functions, where each derived class returns a literal constant value. I
prefer the first approach, unless you're trying to minimize the memory
footprint. (But even in that case, you could make the variables static, so
that all class instances share the same variables.)

My suggestion is to put these in the Weapon class together of course with
the getName and the getPrice because the derived classes would inherit
everything from the base class Weapon. Do you agree.?

Yep.

A question here?. This would make the Weapon class a concreate class and
not an abstract class.

Implementing one or more functions does *not* make the class "concrete". It
is an abstract class as long as it contains at least *one* pure virtual
member function.

But it seems strange
to be able to create an object of class Weapon. An object of class Weapon
doesn't have any price and have no name it's only the object of the
derived classes that have price and names.

It would be rather meaningsless to put in a pure virtual funktion in the
Weapon class just to make the class abstract.

If all you want is to prevent instantiation of a Weapon object directly, and
only allow it via a derived class construction, then I think that you can
just make the Weapon class constructor protected instead of public. (On the
other hand, as you develop the class hierarchy more, you may end up
introducing a pure virtual function, anyway.)

-Howard

 

[Tony Johansson]

Hello!!

If there is different price and name for each derived class then this price
attribute and the name attribute must be put in each derived class. Is that
correct?

So this getName and getPrice is made pure virtual in class Weapon

//Tony.

 

[Victor Bazarov]

If there is different price and name for each derived class then this price
attribute and the name attribute must be put in each derived class. Is that
correct?

First of all, please don't top-post.

Second, no, if those "attributes" simply have different _values_ they
should be member variables but where you put them depends on your design
and your desire, not on the fact that they are different.

So this getName and getPrice is made pure virtual in class Weapon

Whatever. I think you should digest the advice given before attempting
to ask more questions.

[...]

V