Been reading the GOF book and started to make the distinction between
Class and Interface inheritance. One question though:

Do pure abstract classes have representations? (data members?)
What about abstract classes?

Should abstract classes have a destructor and or constructor? What
about pure abstract classes?

What are the conditions that must be satisfied for a class to be

A) Pure Abstract class
B) Abstract Class

Regards

Merlin

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Merlin" <merlin2769@hotmail.com> wrote in message
news:12235816.0405171116.8cd0c37@posting.google.com...
 > Been reading the GOF book and started to make the distinction between
 > Class and Interface inheritance. One question though:
 >
 > Do pure abstract classes have representations? (data members?)

My understanding is that abstract classes are not part of the
object-orientation concept.  Object-orientation states that a class may have
attributes (which are encapsulated, i.e. hidden) and operations, which can
be invoked by the outside world.  That's all about objects.

Abstract classes came about because of programming language implementation
of object-orientation concepts.
One school of object-oriented programming languages (OOPL) claims that there
are two types of classes: concrete and abstract.  Concrete classes can be
instantiated; but abstract ones cannot, because some of its operations do
not have methods (i.e. are not implemented).

Then some OOPLs further identify pure abstract classes.  These are abstract
classes with:
(1) all operations do not have methods (i.e. are not implemented)
(2) no attributes

 > Should abstract classes have a destructor and or constructor? What
 > about pure abstract classes?

Whether C++ abstract (pure or not) classes should define constructors and
destructors depends on the design principles for any C++ class.

 > What are the conditions that must be satisfied for a class to be
 >
 > A) Pure Abstract class
 > B) Abstract Class

Answered above.

:) Joon Yew



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Merlin" <merlin2769@hotmail.com> wrote in message
news:12235816.0405171116.8cd0c37@posting.google.com...
 > Been reading the GOF book and started to make the distinction between
 > Class and Interface inheritance. One question though:
 >
 > Do pure abstract classes have representations? (data members?)
 > What about abstract classes?

I don't think there are any concrete rules about "pure abstract classes" in
C++, if it makes since to have data members, include them.  In Java I
believe Interface classes can not have data members

 >
 > Should abstract classes have a destructor and or constructor? What
 > about pure abstract classes?

If the abstract class contains data members then you'll need a a constructor
and virtual destructor since the intention is to inherite the class.  If no
data members are present than a destructor and constructor is not needed.

 >
 > What are the conditions that must be satisfied for a class to be
 >
 > A) Pure Abstract class
 > B) Abstract Class

An Abstract Class contains a pure virtual function, a function that uses the
"virtual" keyword and is followed by "= 0".  A Pure Abstract Class contains
only pure virtual functions.  If you provide data members in your Abstract
Class you need to provide a constructor and a virtual destructor.  An
Abstract Class can not be instantiated, telling both the user and the
compiler how it was intended to be used.  Also, an Abstract Class prevents
the class from being passed to a function by value.

class PureAbstractClass
{
     virtual int size() = 0;
};

class AbstractClass
{
     virtual int size() = 0;
     void DoSomething()
     {}
};

Scott


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <12235816.0405171116.8cd0c37@posting.google.com>,
  merlin2769@hotmail.com (Merlin) wrote:

 > Been reading the GOF book and started to make the distinction between
 > Class and Interface inheritance.

I presume you mean the distinction between implementation and interface
inheritance:  all C++ inheritance is from classes.  Item 36 of Meyers'
"Effective C++" discusses this.

 >One question though:
 >
 > Do pure abstract classes have representations? (data members?)
 > What about abstract classes?

An abstract class is defined to be any class with at least one pure
virtual function.  It may also have data members.  The term 'pure
abstract class' (or 'protocol class') indicates that there are no data
members.

 > Should abstract classes have a destructor and or constructor? What
 > about pure abstract classes?

Yes, since derived classes will need to call them.  Since abstract
classes (pure or not) are obviously intended for derivation, you will
almost certainly want either a virtual or a protected destructor.   A
pure abstract class may however not need to declare any constructors
explicitly, since with no data members to initialise, the
compiler-generated default one should be OK.

Best wishes,
Matthew Collett

-- 
Those who assert that the mathematical sciences have nothing to say
about the good or the beautiful are mistaken.          -- Aristotle


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Merlin" <merlin2769@hotmail.com> wrote in message
news:12235816.0405171116.8cd0c37@posting.google.com...
 > Been reading the GOF book and started to make the distinction between
 > Class and Interface inheritance. One question though:
 >
 > Do pure abstract classes have representations? (data members?)

No.

 > What about abstract classes?

They may, or they may not.

 >
 > Should abstract classes have a destructor and or constructor? What
 > about pure abstract classes?
 >

Every class in C++ has constructor and destructor.
They may be explicit, written by programmer, or implicit,
generated by compiler, but they are there.

Base classes (pure abstract or not) should have their destructor
explicitly declared as "virtual".

IMO, generally there is no point in having non-default
constructors in a pure abstract class. Since there are
no data members to initialize or behavior to implement,
it is not clear what such constructor may do.

 > What are the conditions that must be satisfied for a class to be
 >
 > A) Pure Abstract class

No data members, all methods are pure virtual, and
without implementation (yes, pure virtual method may
have an implementation). All base classes (if any)
are pure abstract.

 > B) Abstract Class

Some methods are pure virtual.

Ivan

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

merlin2769@hotmail.com (Merlin) wrote in message
news:<12235816.0405171116.8cd0c37@posting.google.com>...
> Been reading the GOF book and started to make the distinction between
> Class and Interface inheritance. One question though:
>
> Do pure abstract classes have representations? (data members?)
> What about abstract classes?
>
> Should abstract classes have a destructor and or constructor? What
> about pure abstract classes?
>
> What are the conditions that must be satisfied for a class to be
>
> A) Pure Abstract class
> B) Abstract Class

When I use the term "pure ABC" I mean a C++ class that can be used as an
interface: no implementation (in C++ all methods are pure virtual) and no
non-constant data members.  An abstract class is just a class with at least
one
pure virtual method and can have data and implementation.

Abstract class X should have a virtual destructor if you are going to delete
an object using a pointer or reference to X.

--
/"\
\ /
 X   ASCII Ribbon Campaign - Non HTML Mail
/ \      http://www.nonhtmlmail.org/

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

merlin2769@hotmail.com (Merlin) wrote in message
news:<12235816.0405171116.8cd0c37@posting.google.com>...

> Been reading the GOF book and started to make the distinction between
> Class and Interface inheritance.

The usual terminology is implementation and interface inheritance, I
think.  Just to avoid confusion due to the fact that they are both
implemented using the C++ construction `class'.

> One question though:

> Do pure abstract classes have representations? (data members?)  What
> about abstract classes?

From a C++ point of view, there is no such thing as a pure abstract
class; there are abstract classes, and non-abstract (or concrete)
classes.  From a design point of view, I would not generally consider
anything with data members an interface, although there might be
exceptions.

> Should abstract classes have a destructor and or constructor? What
> about pure abstract classes?

Any class that is designed to be a base class of a polymorphic hierarchy
needs a virtual destructor.  Any class that is to be used as an
interface is in this category.

The question is less obvious concerning constructors.  My experience is
that classes within a hierarchy, including the base class (which is the
interface) don't work well with C++ copy semantics.  For this reason, I
will sometimes declare a private copy constructor (and almost always a
private operator=).  And if there is a private copy constructor, there
are no other constructors except those you declare, so you also have to
declare a default constructor (normally protected, see below).

> What are the conditions that must be satisfied for a class to be

> A) Pure Abstract class
> B) Abstract Class

In C++, as I said, there is no such thing as a "pure abstract class"; as
a design question, it depends on what you want to do, but I would say
that it is a class without behavior or state.  This typically would mean
that the class have no data members, and that the non-virtual functions
are only concerned with verifying the contract, and all of them forward
to a virtual function for the actual behavior.

In C++, an abstract class is a class which has one or more pure virtual
functions.  From a design point of view, I would say that it is a class
which is not meant to be instantiated -- if it didn't have any pure
virtual functions (which would be rather surprising, but not
impossible), then all of its constructors should be protected; even if
it has pure virtual functions, I tend to make the constructors
protected.

--
James Kanze                                           GABI Software
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hi

Thank you all for your replies. I now have a better understanding of
abstract classes. While on the topic for any of you that own a copy of
GOF, on page 38
there is a class diagram showing the Glyph hierarchy. Two questions

Am I right to say that Image(or Graphic) would be another class that
should inherit from Glyph in order to follow from Fig 2.2 and Fig 2.3
on the previous page.

Secondly, why does Glyph have Insert() operation in its interface if
only some of the classes that inherit from it need this operation. The
interface for Glyph should be all the operations common to the classes
that derive from it. I have come across the ISP priciple by Robert C.
Martin that says this is a bad thing and designers should segregate
the interface and use multiple inheritance. The Glyph interface has
been polluted by Insert()...

If I am right then how can we resolve the issue without
overcomplicating the design.

Kind Regards

Merlin

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

kanze@gabi-soft.fr wrote:
<snip> 
> In C++, an abstract class is a class which has one or more pure virtual
> functions.
<snip>

How about a class that has a protected constructor and no public
constructors and whose members and friends do not construct it?
It's not necessarily polymorphic but neither is it concrete.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Ben Hutchings <do-not-spam-benh@bwsint.com> wrote in message
news:<slrncapgnn.1pc.do-not-spam-benh@shadbolt.i.decadentplace.org.uk>...
> kanze@gabi-soft.fr wrote:
> <snip> 
> > In C++, an abstract class is a class which has one or more pure virtual
> > functions.
> <snip>

> How about a class that has a protected constructor and no public
> constructors and whose members and friends do not construct it?  It's
> not necessarily polymorphic but neither is it concrete.

>From the standard (�10.4/2, second sentence): "A class is abstract if it
has at least one pure virtual funciton."  From the preceding sentence,
it is clear that the underlying premice is that no instance of the class
can exist.  Not that no instance happens to exist, because the functions
having a right to create one don't.  After all, you wouldn't consider
std::string abstract, even if the only thing I happened to do with it
was access npos.

--
James Kanze                                           GABI Software
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Merlin wrote:

> Secondly, why does Glyph have Insert() operation in its interface if
> only some of the classes that inherit from it need this operation. The
> interface for Glyph should be all the operations common to the classes
> that derive from it. I have come across the ISP priciple by Robert C.
> Martin that says this is a bad thing and designers should segregate
> the interface and use multiple inheritance. The Glyph interface has
> been polluted by Insert()...

The Glyph design is indeed a bit non-obvious...
Glyph is subclassed by 'MonoGlyph', which acts as a decorator, as well
as 'PolyGlyph', which acts as a composite.

A scene graph designer may then want to decorate a polyglyph (to
change the layout, change the background color, etc.), but in accordance
with the Decorator pattern he wants to make that indirection transparent:

// this produces a PolyGlyph
Glyph *vbox = layout_kit->vbox();

// now decorate with a MonoGlyph
Glyph *margin = layout_kit->margin(vbox, 10);

So, now you hand back the 'margin' decorator instead of the 'vbox',
but users of that glyph still want to be able to insert new glyphs !

The only way to make that possible (without the need for downcasting)
is by making the 'Glyph' interface absorb these interfaces, i.e. including the
composite specific API ('insert' et al.) and the decorator specific
API ('body' et al.).

(And in accordance with the decorator semantics, the MonoGlyph just passes
  calls to the PolyGlyph-specific calls down to its 'body'.)

I hope this makes the design a bit more clear...

Regards,
		Stefan

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]