Hello, Ivana,
No body argue about term "abstract class" or "abstract base class".
Very likely you did not get my answer yet.
All books you mentioned below do discuss "abstract base class"
but we were speaking about of "abstract interface".
As I explained there are two different things. Do your books provide any
standard definition "abstract inerface" ?
Anyway I do not think we should discuss this matter word wide.
Valery
----- Original Message -----
From: Ivana Hrivnacova <Ivana.Hrivnacova@cern.ch>
To: Fons Rademakers <Fons.Rademakers@cern.ch>
Cc: Valeri Fine (Faine) <fine@bnl.gov>; Damir Buskulic <buskulic@lapp.in2p3.fr>; ROOT mailing list <roottalk@pcroot.cern.ch>
Sent: 3 марта 2000 г. 14:19
Subject: Re: shouldn't need graf3d - abstract classes and interfaces
>
> 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