Hi Fons,
My comment was not meant as criticism of the design
of the mentioned class, not at all. There is no need
to justify that you prefered to use not pure virtual
function in your class..
I just wanted to point out that this class
is not what is usually understood under the term "abstract class"
- as this one is something more "strict".
So I had a look in three books that are lying on
my table to see opinion of "others":
E.Gamma, R.Helm, ... - Design Patterns:
"An abstract class is ... It will defer some or all of its
implementation to its operations defined in subclasses;
hence an abstract class cannot be instantiated. ...
Class that aren't abstract are called concrete classes."
I.Pohl - OO Programming Using C++:
"...an abstract class. This is a class containing one or more
pure virtual functions, ..."
J.Barton, L.Nackman Scient. and Eng..C++:
"An abstract base class is a .. base class with at least one
pure virtual function. ...
!!But also
Other authors use the term abstract class in the same
way that we use the term interface class; (what is your
interpretation, too)"
And in one more:
S.Mayers: Effective C++ (50 ways ...)
".. is an abstract class; its pure virtual function ..
marks it as such."
That were books on C++ - but the terms "abstract class"
and "interface" are defined in OO metodology as well.
Let's have a look at
G. Booch, J. Rumbaugh, I. Jacobson: The UML:
In glossary:
"abstract class A class that cannot be instantiated.
..
interface A collection of operation that are used
to specify a service of a class or a component."
So UML does distinction between these two terms:
"Interfaces are similar to abstract classes (for example
neither may have direct instances), but they are different
enough to warrant being separate modeling elements in the
UML. An abstract base class may have attributes, but
an interface may not. Furthermore ..."
And a few more:
"An interface specifies a contract for a class or
a component without dictating its implementation.
A class or component may realize many interfaces.
.."
So only Barton & Nackman admits your interpretation
of abstract class (but they use the standard interpretation
in their book) - but this book was issued in 1994
- just before ML were unified to UML (1995).
As UML is now commonly adopted as standard,
I think, we should not use the term "abstract interface"
for the class discussed.
Best regards,
Ivana
P.S.
> Another extreme is a class with 100 methods and only one pure abstract (=0)
> method. I would not call such an interface a real abstract interface. There
> the single pure abstract method is just a reminder to provide the one required
> "user" method.
Such class *is* an abstract class as due to this
one pure virtual method it cannot be instantiated.
It *realizes* the interface defined by this abstract
method.
==============================================================
e-mail: Ivana.Hrivnacova@cern.ch
address: PPE Division; 160-1-016; CERN; 1211 Geneve; Switzerland
phone: (022)-767-9749
Home institute: NPI Rez near Prague, Czech Republic
==============================================================
On Fri, 3 Mar 2000, Fons Rademakers wrote:
> Hi Ivana,
>
> an interface without pure abstract (=0) methods can still be abstract.
> Pure abstract methods require an implementation in a derived class, where
> the compiler will check that the required methods are provided. But there
> is nothing wrong with an abstract interface without pure abstract methods.
> You loose the extra check of the compiler, but it is easier to implement
> just a subset of methods in a derived class without the compiler nagging you
> to override all methods. In that case very clear documentation is necessary
> telling you what is expected to make a concrete implementation.
>
> Another extreme is a class with 100 methods and only one pure abstract (=0)
> method. I would not call such an interface a real abstract interface. There
> the single pure abstract method is just a reminder to provide the one required
> "user" method.
>
>
> Cheers, Fons.
>
>
>
> Ivana Hrivnacova wrote:
> >
> > Hi Valery,
> >
> > Just one comment for not confusing C++ beginners
> > by using incorrect terminology:
> >
> > On Thu, 2 Mar 2000, Valeri Fine (Faine) wrote:
> >
> > > TPadView3D is an abstract interface between TPad and some concrete
> > > 3D viewer. So it must be linked with very TPad but should impose no extra
> > > dependencies since all its methods look as follows:
> > >
> > > inline void TPadView3D::ExecuteEvent(Int_t, Int_t, Int_t) { }
> > > inline void TPadView3D::Paint(Option_t *) { }
> > > inline void TPadView3D::Size(Int_t, Int_t) { }
> > > inline void TPadView3D::PaintBeginModel(Option_t *) { }
> > > inline void TPadView3D::PaintEnd(Option_t *) { }
> > > inline void TPadView3D::PaintScene(Option_t *) { }
> > > inline void TPadView3D::PaintPolyMarker(TPolyMarker3D *, Option_t *) { }
> > > inline void TPadView3D::PaintPolyLine(TPolyLine3D *, Option_t *) { }
> > > inline void TPadView3D::PaintPoints3D(const TPoints3DABC *,Option_t *){ }
> > > inline void TPadView3D::SetAttNode(TNode *, Option_t *) { }
> > > inline void TPadView3D::SetLineAttr(Color_t ,Int_t ,Option_t *) { }
> > > inline void TPadView3D::UpdateNodeMatrix(TNode *, Option_t *) { }
> > > inline void TPadView3D::UpdatePosition(Double_t ,Double_t ,Double_t ,TRotMatrix *, Option_t *){ }
> >
> > This is not an abstract interface as it does not contain any
> > abstract method. The abstract methods look like this:
> >
> > > inline void TPadView3D::ExecuteEvent(Int_t, Int_t, Int_t) = 0;
> > > inline void TPadView3D::Paint(Option_t *) = 0;
> > ... etc.
> >
> > Making a method abstract enforces all derived classes to
> > provide implementation of this method. If you omit this
> > implementation than you will not be able to instantiate
> > such derived class.
> > (Compiler will give you error on "new MyDerivedClass" if
> > implementation of any abstract method is missing.)
> >
> > This is used in interfaces for ensuring that all interface
> > implementation will provide the required methods.
> >
> > Best regards,
> >
> > Ivana Hrivnacova
> >
> > ==============================================================
> > e-mail: Ivana.Hrivnacova@cern.ch
> > address: PPE Division; 160-1-016; CERN; 1211 Geneve; Switzerland
> > phone: (022)-767-9749
> > Home institute: NPI Rez near Prague, Czech Republic
> > ==============================================================
>
> --
> Org: CERN, European Laboratory for Particle Physics.
> Mail: 1211 Geneve 23, Switzerland
> E-Mail: Fons.Rademakers@cern.ch Phone: +41 22 7679248
> WWW: http://root.cern.ch/~rdm/ Fax: +41 22 7677910
>
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:20 MET