Concrete class

[mead]

What kind of classes is qualified as "concrete classes"?

When should a member function in a class defined as "pure virtual" and when
as "virtual"?

Thanks!

 

[Leor Zolman]

What kind of classes is qualified as "concrete classes"?

One you can instantiate. directly. In the ubiquitous "Shape" class
example, with a base class named "Shape" and then derived classes such
as "Circle", "Rectangle", etc., it makes sense to say
Circle c;
but not
Shape s;

(Although
Shape *s
would make perfect sense, as long as you don't try to do:
Shape *s = new Shape;

When should a member function in a class defined as "pure virtual" and when
as "virtual"?

That's actually quite related to your first question. The way to make
a class be abstract is to give it at least one pure virtual function.
If a base class contains one or more pure virtual functions, there are
really two things going on. One is that the class is abstract; but for
that alone, a single pure virtual function would have been sufficient.
The other thing going on is that classes which derive from the base
class must implement /each/ of the pure virtual functions they inherit
in order to qualify as a concrete class. So if a derived class only
implements 7 out of 8 of the pure virtual functions it inherits, it is
still an abstract class. But a further derived class will inherit only
a single pure virtual function, and that further derived class would
become concrete by implementing that one function.
-leor

 

[mead]

One you can instantiate. directly. In the ubiquitous "Shape" class
example, with a base class named "Shape" and then derived classes such
as "Circle", "Rectangle", etc., it makes sense to say
Circle c;
but not
Shape s;

(Although
Shape *s
would make perfect sense, as long as you don't try to do:
Shape *s = new Shape;

If "Shape" has a pure virtual function and this function is implemented in
Circle class as derived, then Circle becomes a class that can be
instantiate, thus Circle is concrete class but Shape isn't. Is it correct?

If Shape has no pure virtual function but virtual function(s), will it be a
concrete class?

That's actually quite related to your first question. The way to make
a class be abstract is to give it at least one pure virtual function.
If a base class contains one or more pure virtual functions, there are
really two things going on. One is that the class is abstract; but for
that alone, a single pure virtual function would have been sufficient.
The other thing going on is that classes which derive from the base
class must implement /each/ of the pure virtual functions they inherit
in order to qualify as a concrete class. So if a derived class only
implements 7 out of 8 of the pure virtual functions it inherits, it is
still an abstract class. But a further derived class will inherit only
a single pure virtual function, and that further derived class would
become concrete by implementing that one function.
-leor

When defining a pure virtual function and when defining a virtual function
in a class?

 

[Victor Bazarov]

If "Shape" has a pure virtual function and this function is implemented in
Circle class as derived, then Circle becomes a class that can be
instantiate, thus Circle is concrete class but Shape isn't. Is it correct?

Yes.

If Shape has no pure virtual function but virtual function(s), will it be a
concrete class?

The fact that virtual functions are all defined (not pure) basically
indicates that the class has specific behaviour. That usually means
that the class is concrete.

[..]
When defining a pure virtual function and when defining a virtual function
in a class?

I am not sure I understand the question (it's not a proper English
sentence), but, usually, you define a virtual function pure only if
it doesn't make sense (or is impossible) to specify any concrete
definition for it. Take the same Shape vs Circle example Leor gave
and try to declare/define the member function 'getArea'. I always
was a believer that doing it is much better way to understand than
listening to or reading an explanation.

Victor

 

[Leor Zolman]

If "Shape" has a pure virtual function and this function is implemented in
Circle class as derived, then Circle becomes a class that can be
instantiate, thus Circle is concrete class but Shape isn't. Is it correct?

Yes, assuming no (other) unimplemented pure virtuals in Circle.

If Shape has no pure virtual function but virtual function(s), will it be a
concrete class? Yes.


When defining a pure virtual function and when defining a virtual function
in a class?

Are you asking when is it appropriate to define a function as pure virtual
vs. just plain virtual? I was trying to answer that in what I said above.
The short version: make it pure virtual if you require a derived class to
implement it in order for that derived class to qualify as a concrete
class. Or, just make /something/ virtual (typically the destructor) if you
want a class to be abstract but not to require some derived class to
necessarily have to implement anything in particular.
-leor


If you have a more specific question, ask away...
-leor

 

[Kutty Banerjee]

What kind of classes is qualified as "concrete classes"?

When should a member function in a class defined as "pure virtual" and when
as "virtual"?

Thanks!

Hi,
may i answer your question a little differently. its good practise to
program to an interface. by interface in c++ i mean an
abstract class with ALL pure virtual functions.
So imagine you have your example of Shape and Circle. If you use the
above philosophy then it means that your Shape is an interface. This is a
lil different philosophy and there will be some non takers
for this but as a thumb rule almost never have a class with pure virtual
function and some non pure virtual functions. So if there is a
class with a pure virtual function, then let it just have such as those. You
can imagine this to be an interface.
The benefit of doing this is to keep the inheritance hierarchy at a low
depths!!

kutty

 

[mead]

Hi,
may i answer your question a little differently. its good practise to
program to an interface. by interface in c++ i mean an
abstract class with ALL pure virtual functions.
So imagine you have your example of Shape and Circle. If you use the
above philosophy then it means that your Shape is an interface. This is a
lil different philosophy and there will be some non takers
for this but as a thumb rule almost never have a class with pure virtual
function and some non pure virtual functions. So if there is a
class with a pure virtual function, then let it just have such as those. You
can imagine this to be an interface.
The benefit of doing this is to keep the inheritance hierarchy at a low
depths!!

kutty

I like what you said about "program to an interface." However, "The benefit
of doing this is to keep the inheritance hierarchy at a low depths" is
confusing since adding an interface is always making inheritance hierarchy
deeper. Am I right on this?

 

[Kutty Banerjee]

I like what you said about "program to an interface." However, "The benefit
of doing this is to keep the inheritance hierarchy at a low depths" is
confusing since adding an interface is always making inheritance hierarchy
deeper. Am I right on this?

Hi,
Yes i was not clear on the part about keeping hierarchy depths low. Consider
the
following example.

Method One:
class A
method 1
method 2
method 3
//All virtual methods!!

Class B: public A
method 1
method 2
method 3
//All the above methods are different implementations than those of
//class A.

Class Cublic B
method 1
method 2
method 3
method 4
method 5


So we have three level hierarchy here!! how to make this two level?
to begin with, class B should inherit from Class X where class X is
the interface of class A(exact same method signaturres but no body, so
abstract class)
There must be another interface Class Y with methods 4 and 5.
Class C now inherits from abstract classes X and Y ( im mixing abstract
class and interface intentionally)
and not from class B. If however Class C must have exactly the same
funcftionality for methods 1,2, 3
as those of class B then instead of inheriting from class B it could use
delegation. and if it doesnt ,
then completely forget about class B.

So finally we have class A inheriting from abstract class X and Class B
inheriting from abstract class X, Y.
If necessary it will delegate to Class B (meaning have composition of Class
B ). but in short we have two levels
of inheritance now.

kutty

 

[DaKoadMunky]

The benefit of doing this is to keep the inheritance hierarchy at a low
depths!

Why is this a benefit?

When is such a rule best applied?

Citing your example, what if there is a legitimate "isa" relationship between
class C and class B? Do you still support class C containing a B and
delegating to it and providing appropriate conversion operators so that the
substitutiability of a C for a B is maintained?

 

[Kutty Banerjee]

depths!

Why is this a benefit?

When is such a rule best applied?

Citing your example, what if there is a legitimate "isa" relationship between
class C and class B? Do you still support class C containing a B and
delegating to it and providing appropriate conversion operators so that the
substitutiability of a C for a B is maintained?

Hi,
this is a contentious issue in the world of OO and is called inheritance vs
delegation (composition).
In fact if there is a genuine isa relation between c and b classes, thats
when delegation comes to the
rescue. The advantage of using delegation is as follows:

Ask your self the question why would C be isa B? Well maybe because B has
say 3 virtual (or may not be virtual)
that it uses as is (does not override) and in addition has 2 other methods
of its own. Rite? Now in this case since
C uses the same interface as B(refer to the initial eg i d given), therefore
it still has the 3 methods of B only that
inside each of these methods , it invokes a contained B objects
corresponding methods. with me so far?

Question is what is the advantage of doing this. wait, lets see the
disadvantages of this first!! You are increasing the
size of the object. Since you are delegating, therefore there is an extra
overhead involved, so purists could even
argue that it is making things slower . Correct!!

Advantage? Consider that instead of class B, there is a class D which has
hte same methods of B but implements
them differently. At runtime you want your class C to choose either the
implementation of B or D . Thats where
delegation comes to the rescue. Delegation gives you runtime flexibility
whereas inheritance gives you compile
time flexibility.

Last question? In the original example i have talked about inheriting from
interface (aka abstract class with only
pure virtual methods). So each class inherits from the interface. Isnt this
inheritance too? shouldnt we get rid of this
too? the answer is, try and differentiate between class inheritance and
interface inheritance. Interfae inheritance is
what i just mentioned. Class inheritance is what we got rid of .