COMPGROUPS.NET | Search | Post Question | Groups | Stream | About | Register

Override public virtual Functions with private Functions?

  • Follow


Hello All

I have a base class called Action_Request, and a set of classes
corresponding to different kinds of Action_Request, each of which inherits
from Action_Request. Eg:-

class  Add_Molecule_Req: public Action_Request{
//  ......
};

I manipulate the various derived classes polymorphically through
Action_Requests's public interface, using its virtual functions.
Currently the overriding functions in the derived classes (including the
destructor, which overrides Action_Request's virtual destructor), are
declared public.

My program compiles if I make them private, and doing this would seem to
have the advantage that these functions must then always be invoked
polymorphically through Action_Request's public interface, which is what I
want.

My questions are:-

i)   Is overriding public virtual functions with private functions good
practice?
ii)  Are there any disadvantages?

Chris Gordon-Smith
www.simsoup.info
0
Reply use.address (75) 5/26/2008 12:56:35 PM 

Chris Gordon-Smith <use.address@my.homepage> wrote:

> I have a base class called Action_Request, and a set of classes
> corresponding to different kinds of Action_Request, each of which inherits
> from Action_Request. Eg:-
> 
> class  Add_Molecule_Req: public Action_Request{
> //  ......
> };
> 
> I manipulate the various derived classes polymorphically through
> Action_Requests's public interface, using its virtual functions.
> Currently the overriding functions in the derived classes (including the
> destructor, which overrides Action_Request's virtual destructor), are
> declared public.
> 
> My program compiles if I make them private, and doing this would seem to
> have the advantage that these functions must then always be invoked
> polymorphically through Action_Request's public interface, which is what I
> want.
> 
> My questions are:-
> 
> i)   Is overriding public virtual functions with private functions good
> practice?
> ii)  Are there any disadvantages?

I tend to follow the guideline, "make it private if you can, public if 
you must." I consider such code "good practice".

The only disadvantage is that someone with a object of some 
ActionRequest sub-class will have to up-cast the object.
0
Reply daniel_t (1960) 5/26/2008 1:35:36 PM 


Chris Gordon-Smith wrote:

> My questions are:-
> 
> i)   Is overriding public virtual functions with private functions good
> practice?
> ii)  Are there any disadvantages?

In general you should separate interface (the public API the base class
provides) from configurability (the overriding feature). This is also
called the Template Method Pattern and is described in detail here:
http://www.gotw.ca/publications/mill18.htm

-- 
Dizzy
0
Reply dizzy (91) 5/26/2008 1:43:54 PM 

Daniel T. wrote:

> Chris Gordon-Smith <use.address@my.homepage> wrote:
> 
>> I have a base class called Action_Request, and a set of classes
>> corresponding to different kinds of Action_Request, each of which
>> inherits from Action_Request. Eg:-
>> 
>> class  Add_Molecule_Req: public Action_Request{
>> //  ......
>> };
>> 
>> I manipulate the various derived classes polymorphically through
>> Action_Requests's public interface, using its virtual functions.
>> Currently the overriding functions in the derived classes (including the
>> destructor, which overrides Action_Request's virtual destructor), are
>> declared public.
>> 
>> My program compiles if I make them private, and doing this would seem to
>> have the advantage that these functions must then always be invoked
>> polymorphically through Action_Request's public interface, which is what
>> I want.
>> 
>> My questions are:-
>> 
>> i)   Is overriding public virtual functions with private functions good
>> practice?
>> ii)  Are there any disadvantages?
> 
> I tend to follow the guideline, "make it private if you can, public if
> you must." I consider such code "good practice".
> 
Sounds sensible to me. What I hadn't appreciated (because I hadn't really
thought about it), is that private methods in derived class can override
public methods in the base.

> The only disadvantage is that someone with a object of some
> ActionRequest sub-class will have to up-cast the object.

In my case that is not a problem, because manipulation should only ever take
place through the base. If I ever attempt manipulation through a derived
class pointer I will get a compiler error. Upcasting would be possible, but
would be working against my basic design principle.

Chris Gordon-Smith
www.simsoup.info
0
Reply use.address (75) 5/26/2008 3:54:20 PM 

On May 26, 2:56 pm, Chris Gordon-Smith <use.addr...@my.homepage>
wrote:

> I have a base class called Action_Request, and a set of
> classes corresponding to different kinds of Action_Request,
> each of which inherits from Action_Request. Eg:-

> class  Add_Molecule_Req: public Action_Request{
> //  ......
> };

> I manipulate the various derived classes polymorphically
> through Action_Requests's public interface, using its virtual
> functions.  Currently the overriding functions in the derived
> classes (including the destructor, which overrides
> Action_Request's virtual destructor), are declared public.

> My program compiles if I make them private, and doing this
> would seem to have the advantage that these functions must
> then always be invoked polymorphically through
> Action_Request's public interface, which is what I want.

> My questions are:-

> i)   Is overriding public virtual functions with private functions good
> practice?
> ii)  Are there any disadvantages?

It's more a style issue than anything else.  My personal
guidelines are to never change the access of a virtual function
in the derived class, since I find it confusing that the same
function has different access depending on the static type used
to access it.  The disadvantage that I see is that someone
working on the derived class, later, may think that the
functions in question cannot be called from outside the class.
And of course, making them private does sort of violate the LSP:
if I have a Derived, I can't call them, although I could if I
had a Base.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
Reply james.kanze (9594) 5/27/2008 7:55:13 AM 

dizzy wrote:
> Chris Gordon-Smith wrote:
> 
>> My questions are:-
>>
>> i)   Is overriding public virtual functions with private functions good
>> practice?
>> ii)  Are there any disadvantages?
> 
> In general you should separate interface (the public API the base class
> provides) from configurability (the overriding feature). This is also
> called the Template Method Pattern and is described in detail here:
> http://www.gotw.ca/publications/mill18.htm
> 

Interesting article. It says that in some cases the destructor should be 
made protected. I have never thought about it before, and it made me 
wonder why would anyone make the destructor private or protected.
So, the question is what are uses of such destructor?
0
Reply anon3413 (206) 5/27/2008 8:29:33 AM 

anon wrote:
> dizzy wrote:
>> Chris Gordon-Smith wrote:
>>
>>> My questions are:-
>>>
>>> i)   Is overriding public virtual functions with private functions good
>>> practice?
>>> ii)  Are there any disadvantages?
>>
>> In general you should separate interface (the public API the base class
>> provides) from configurability (the overriding feature). This is also
>> called the Template Method Pattern and is described in detail here:
>> http://www.gotw.ca/publications/mill18.htm
>>
> 
> Interesting article. It says that in some cases the destructor should be 
> made protected. I have never thought about it before, and it made me 
> wonder why would anyone make the destructor private or protected.
> So, the question is what are uses of such destructor?

Considering a class wrapping only static function as helper or factory 
function, we should make the dtor private not to allow any instance.

We can also make the dtor private and with a static function "destroy" 
to allow instance created only by new (no stack allocation)

making the dtor protected, then child class publicly/protectedly 
derived from from still has access to it. at this time, you can never 
delete a pointer to the base class.

-- 
Best Regards
Barry
0
Reply dhb2000 (345) 5/27/2008 9:00:33 AM 

On May 27, 10:29 am, anon <a...@no.no> wrote:
> dizzy wrote:

> Interesting article. It says that in some cases the destructor
> should be made protected. I have never thought about it
> before, and it made me wonder why would anyone make the
> destructor private or protected.  So, the question is what are
> uses of such destructor?

If the destructor is protected or private, you cannot allocate
static or automatic instances of the type, and you cannot call
delete on pointers to the type.  In client code; you can still
do pretty much anything you want in the implementation of the
class itself.

Private destructors might make sense if the class itself
controls its lifetime: the only time it should be destructed is
in response to some external event (in which case, it does a
delete this).  This is often the case for entity classes, for
example.

Protected destructors make a lot of sense for classes which are
designed to be used as base classes (and only as base classes),
but which don't have a virtual destructor.  Classes like
std::iterator<>, for example.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
Reply james.kanze (9594) 5/27/2008 9:03:02 AM 

James Kanze wrote:

> On May 26, 2:56 pm, Chris Gordon-Smith <use.addr...@my.homepage>
> wrote:
> 
>> I have a base class called Action_Request, and a set of
>> classes corresponding to different kinds of Action_Request,
>> each of which inherits from Action_Request. Eg:-
> 
>> class  Add_Molecule_Req: public Action_Request{
>> //  ......
>> };
> 
>> I manipulate the various derived classes polymorphically
>> through Action_Requests's public interface, using its virtual
>> functions.  Currently the overriding functions in the derived
>> classes (including the destructor, which overrides
>> Action_Request's virtual destructor), are declared public.
> 
>> My program compiles if I make them private, and doing this
>> would seem to have the advantage that these functions must
>> then always be invoked polymorphically through
>> Action_Request's public interface, which is what I want.
> 
>> My questions are:-
> 
>> i)   Is overriding public virtual functions with private functions good
>> practice?
>> ii)  Are there any disadvantages?
> 
> It's more a style issue than anything else.  My personal
> guidelines are to never change the access of a virtual function
> in the derived class, since I find it confusing that the same
> function has different access depending on the static type used
> to access it.  The disadvantage that I see is that someone
> working on the derived class, later, may think that the
> functions in question cannot be called from outside the class.
> And of course, making them private does sort of violate the LSP:
> if I have a Derived, I can't call them, although I could if I
> had a Base.

Thanks for this - interesting. As I understand it, the Liskov Substitution
Principle (LSP) is about maintaining the "is a" relationship between the
derived class and the base class. What I am trying to do is to use the base
class to provide a common interface to a set of classes that can be used
polymorphically. Does the LSP apply in this case?

Chris Gordon-Smith
www.simsoup.info
0
Reply use.address (75) 5/27/2008 11:28:55 AM 

James Kanze <james.kanze@gmail.com> wrote:
> Chris Gordon-Smith <use.addr...@my.homepage> wrote:
> 
> > My questions are:-
> >
> > i)  Is overriding public virtual functions with private functions
> >     good practice?
> > ii) Are there any disadvantages?
> 
> It's more a style issue than anything else.  My personal guidelines
> are to never change the access of a virtual function in the derived
> class, since I find it confusing that the same function has
> different access depending on the static type used to access it.

That's true.

> The disadvantage that I see is that someone working on the derived
> class, later, may think that the functions in question cannot be
> called from outside the class.

Which is exactly what the OP wants them to think. :-)

Thinking about it, the OP might be better off if he made the base class 
member-function private and provide a specialized interface for those 
who are allowed to call it.
0
Reply daniel_t (1960) 5/27/2008 11:55:07 AM 

Chris Gordon-Smith <use.address@my.homepage> wrote:
> James Kanze wrote:
> > Chris Gordon-Smith <use.addr...@my.homepage> wrote:

> > > My questions are:-
> > >
> > > i)  Is overriding public virtual functions with private
> > >     functions good practice?
> > > ii) Are there any disadvantages?
> > 
> > ... making them private does sort of violate the LSP: if I have a
> > Derived, I can't call them, although I could if I had a Base.
> 
> As I understand it, the Liskov Substitution Principle (LSP) is
> about maintaining the "is a" relationship between the derived class
> and the base class.

Note that James said it "sort of" violated the LSP, in actual fact it 
doesn't violate the LSP at all. Although this isn't a mark against it, 
it is also not a mark for it. :-)

Something to think about. If some user of the derived class does up-cast 
and then call the base class member-function, would that necessarily be 
an error?
0
Reply daniel_t (1960) 5/27/2008 11:59:06 AM 

Daniel T. wrote:

> Chris Gordon-Smith <use.address@my.homepage> wrote:
>> James Kanze wrote:
>> > Chris Gordon-Smith <use.addr...@my.homepage> wrote:
> 
>> > > My questions are:-
>> > >
>> > > i)  Is overriding public virtual functions with private
>> > >     functions good practice?
>> > > ii) Are there any disadvantages?
>> > 
>> > ... making them private does sort of violate the LSP: if I have a
>> > Derived, I can't call them, although I could if I had a Base.
>> 
>> As I understand it, the Liskov Substitution Principle (LSP) is
>> about maintaining the "is a" relationship between the derived class
>> and the base class.
> 
> Note that James said it "sort of" violated the LSP, in actual fact it
> doesn't violate the LSP at all. Although this isn't a mark against it,
> it is also not a mark for it. :-)
> 
> Something to think about. If some user of the derived class does up-cast
> and then call the base class member-function, would that necessarily be
> an error?

I don't think I would call it an error, but it would not be how I intend the
class to be used. The code that uses my class is now more complex, because
sometimes it uses the base class interface directly, and sometimes uses it
by up-casting. 

Chris Gordon-Smith
www.simsoup.info
0
Reply use.address (75) 5/27/2008 12:56:34 PM 

On May 27, 8:56=A0am, Chris Gordon-Smith <use.addr...@my.homepage>
wrote:
> Daniel T. wrote:

> > If some user of the derived class does up-cast
> > and then call the base class member-function, would that necessarily be
> > an error?
>
> I don't think I would call it an error, but it would not be how I intend t=
he
> class to be used. The code that uses my class is now more complex, because=

> sometimes it uses the base class interface directly, and sometimes uses it=

> by up-casting.

That latter comment is a strong reason to go ahead and make the member-
function public in the derived class.
0
Reply daniel_t (1960) 5/27/2008 5:50:48 PM 

Daniel T. wrote:

> On May 27, 8:56 am, Chris Gordon-Smith <use.addr...@my.homepage>
> wrote:
>> Daniel T. wrote:
> 
>> > If some user of the derived class does up-cast
>> > and then call the base class member-function, would that necessarily be
>> > an error?
>>
>> I don't think I would call it an error, but it would not be how I intend
>> the class to be used. The code that uses my class is now more complex,
>> because sometimes it uses the base class interface directly, and
>> sometimes uses it by up-casting.
> 
> That latter comment is a strong reason to go ahead and make the member-
> function public in the derived class.

Not really. The fact that up-casting would be necessary is a strong
indication that the class is not intended to be used in this way. By only
using the base class interface we keep the calling code simple and avoid
any up-casting.

Chris Gordon-Smith
www.simsoup.info
0
Reply use.address (75) 5/27/2008 9:08:48 PM 

Chris Gordon-Smith wrote:
> Daniel T. wrote:
> 
>> On May 27, 8:56 am, Chris Gordon-Smith <use.addr...@my.homepage>
>> wrote:
>>> Daniel T. wrote:
>>>> If some user of the derived class does up-cast
>>>> and then call the base class member-function, would that necessarily be
>>>> an error?
>>> I don't think I would call it an error, but it would not be how I intend
>>> the class to be used. The code that uses my class is now more complex,
>>> because sometimes it uses the base class interface directly, and
>>> sometimes uses it by up-casting.
>> That latter comment is a strong reason to go ahead and make the member-
>> function public in the derived class.
> 
> Not really. The fact that up-casting would be necessary is a strong
> indication that the class is not intended to be used in this way. By only
> using the base class interface we keep the calling code simple and avoid
> any up-casting.
> 
> Chris Gordon-Smith
> www.simsoup.info
> 
The real question is, why don't you want people to call 
Derived->baseMethod()? What harm comes from it, and what benefit comes 
from preventing it?

Polymorphic methods work the same whether you have a pointer/reference 
to a Base or Derived class. That's *why* they are virtual.


-- 
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
0
Reply newsgroup.spamfilter (920) 5/27/2008 10:56:12 PM 

Daniel Pitts wrote:

> Chris Gordon-Smith wrote:
>> Daniel T. wrote:
>> 
>>> On May 27, 8:56 am, Chris Gordon-Smith <use.addr...@my.homepage>
>>> wrote:
>>>> Daniel T. wrote:
>>>>> If some user of the derived class does up-cast
>>>>> and then call the base class member-function, would that necessarily
>>>>> be an error?
>>>> I don't think I would call it an error, but it would not be how I
>>>> intend the class to be used. The code that uses my class is now more
>>>> complex, because sometimes it uses the base class interface directly,
>>>> and sometimes uses it by up-casting.
>>> That latter comment is a strong reason to go ahead and make the member-
>>> function public in the derived class.
>> 
>> Not really. The fact that up-casting would be necessary is a strong
>> indication that the class is not intended to be used in this way. By only
>> using the base class interface we keep the calling code simple and avoid
>> any up-casting.
>> 
>> Chris Gordon-Smith
>> www.simsoup.info
>> 
> The real question is, why don't you want people to call
> Derived->baseMethod()? What harm comes from it, and what benefit comes
> from preventing it?

The benefit is standardisation and simplification. The base and its derived
classes are designed to be used polymorphically in a standard way through
the base class's interface. Using the interfaces of the various derived
classes would go against this and increase overall complexity and introduce
the possibility of error. If the classes are used in the way intended,
there is no need to call using the derived class's interface.

> 
> Polymorphic methods work the same whether you have a pointer/reference
> to a Base or Derived class. That's *why* they are virtual.
> 
> 

Chris Gordon-Smith
www.simsoup.info
0
Reply use.address (75) 5/28/2008 12:01:23 AM 

On May 27, 1:59 pm, "Daniel T." <danie...@earthlink.net> wrote:
> Chris Gordon-Smith <use.addr...@my.homepage> wrote:
> > James Kanze wrote:
> > > Chris Gordon-Smith <use.addr...@my.homepage> wrote:
> > > > My questions are:-

> > > > i)  Is overriding public virtual functions with private
> > > >     functions good practice?
> > > > ii) Are there any disadvantages?

> > > ... making them private does sort of violate the LSP: if I have a
> > > Derived, I can't call them, although I could if I had a Base.

> > As I understand it, the Liskov Substitution Principle (LSP) is
> > about maintaining the "is a" relationship between the derived class
> > and the base class.

> Note that James said it "sort of" violated the LSP, in actual fact it
> doesn't violate the LSP at all. Although this isn't a mark against it,
> it is also not a mark for it. :-)

It depends on how you consider the LSP.  It most definitely
violates the usual understanding of LSP.  Typically, in C++,
this violation won't be visible, since client code expecting a
Base will take a Base* or a Base&, and won't see the fact that
the functions are private in the derived class.  It might become
visible, however, in the presense of templates.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
Reply james.kanze (9594) 5/28/2008 9:36:23 AM 

On May 28, 2:01 am, Chris Gordon-Smith <use.addr...@my.homepage>
wrote:
> Daniel Pitts wrote:
> > Chris Gordon-Smith wrote:
> >> Daniel T. wrote:

> >>> On May 27, 8:56 am, Chris Gordon-Smith <use.addr...@my.homepage>
> >>> wrote:
> >>>> Daniel T. wrote:
> >>>>> If some user of the derived class does up-cast
> >>>>> and then call the base class member-function, would that necessarily=

> >>>>> be an error?
> >>>> I don't think I would call it an error, but it would not be how I
> >>>> intend the class to be used. The code that uses my class is now more
> >>>> complex, because sometimes it uses the base class interface directly,=

> >>>> and sometimes uses it by up-casting.
> >>> That latter comment is a strong reason to go ahead and make the member=
-
> >>> function public in the derived class.

> >> Not really. The fact that up-casting would be necessary is a strong
> >> indication that the class is not intended to be used in this way. By on=
ly
> >> using the base class interface we keep the calling code simple and avoi=
d
> >> any up-casting.

> >> Chris Gordon-Smith
> >>www.simsoup.info

> > The real question is, why don't you want people to call
> > Derived->baseMethod()? What harm comes from it, and what benefit comes
> > from preventing it?

> The benefit is standardisation and simplification. The base
> and its derived classes are designed to be used
> polymorphically in a standard way through the base class's
> interface.

One of the characteristics of inheritance is normally that the
Base class' interface is part of the derived class' interface,
i.e. if I have something like:

    struct Base { void f() ; } ;
    struct Derived : Base { void g() ; } ;

then the "interface" defined by Derived includes both f() and
g().

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
Reply james.kanze (9594) 5/28/2008 9:40:02 AM 

James Kanze wrote:

> On May 28, 2:01 am, Chris Gordon-Smith <use.addr...@my.homepage>
> wrote:
>> Daniel Pitts wrote:
>> > Chris Gordon-Smith wrote:
>> >> Daniel T. wrote:
> 
>> >>> On May 27, 8:56 am, Chris Gordon-Smith <use.addr...@my.homepage>
>> >>> wrote:
>> >>>> Daniel T. wrote:
>> >>>>> If some user of the derived class does up-cast
>> >>>>> and then call the base class member-function, would that
>> >>>>> necessarily be an error?
>> >>>> I don't think I would call it an error, but it would not be how I
>> >>>> intend the class to be used. The code that uses my class is now more
>> >>>> complex, because sometimes it uses the base class interface
>> >>>> directly, and sometimes uses it by up-casting.
>> >>> That latter comment is a strong reason to go ahead and make the
>> >>> member- function public in the derived class.
> 
>> >> Not really. The fact that up-casting would be necessary is a strong
>> >> indication that the class is not intended to be used in this way. By
>> >> only using the base class interface we keep the calling code simple
>> >> and avoid any up-casting.
> 
>> >> Chris Gordon-Smith
>> >>www.simsoup.info
> 
>> > The real question is, why don't you want people to call
>> > Derived->baseMethod()? What harm comes from it, and what benefit comes
>> > from preventing it?
> 
>> The benefit is standardisation and simplification. The base
>> and its derived classes are designed to be used
>> polymorphically in a standard way through the base class's
>> interface.
> 
> One of the characteristics of inheritance is normally that the
> Base class' interface is part of the derived class' interface,
> i.e. if I have something like:
> 
>     struct Base { void f() ; } ;
>     struct Derived : Base { void g() ; } ;
> 
> then the "interface" defined by Derived includes both f() and
> g().

True enough. In the case of my Action_Requests however, I don't want to use
the derived class' interface. I always want to call polymorphically through
the base interface. 

Chris Gordon-Smith
www.simsoup.info
0
Reply use.address (75) 5/28/2008 4:13:36 PM 

On May 28, 6:13 pm, Chris Gordon-Smith <use.addr...@my.homepage>
wrote:
> James Kanze wrote:

    [...]
> True enough. In the case of my Action_Requests however, I
> don't want to use the derived class' interface. I always want
> to call polymorphically through the base interface.

In that case, you probably also want a factory which returns the
actual instances, so that the client code doesn't even know that
the derived classes exist.  (And of course, in that case,
whether the virtual functions are public or are private in the
derived class really doesn't matter, since the client code
doesn't have access to the derived class definition.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
Reply james.kanze (9594) 5/28/2008 8:12:35 PM 

On May 28, 9:12 pm, James Kanze <james.ka...@gmail.com> wrote:
> On May 28, 6:13 pm, Chris Gordon-Smith <use.addr...@my.homepage>
> wrote:
>
> > James Kanze wrote:
>
>     [...]
>
> > True enough. In the case of my Action_Requests however, I
> > don't want to use the derived class' interface. I always want
> > to call polymorphically through the base interface.
>
> In that case, you probably also want a factory which returns the
> actual instances, so that the client code doesn't even know that
> the derived classes exist.  (And of course, in that case,
> whether the virtual functions are public or are private in the
> derived class really doesn't matter, since the client code
> doesn't have access to the derived class definition.)
>

Yes. I have something like this. I make objects of the derived class
by reading input from a file. Depending on the kind of 'request' in
the file. I make an object of the appropriate derived class. Once this
has been done, nothing in the client code that manipulates the objects
knows about the derived classes.

(Hope this posting gets through OK. I can't get onto my news server at
the moment and so have had to go onto Google groups.)

Chris Gordon-Smith
www.simsoup.info
0
Reply c.gordonsmith 5/29/2008 8:42:34 AM 

Chris Gordon-Smith wrote:
> On May 28, 9:12 pm, James Kanze <james.ka...@gmail.com> wrote:
>> On May 28, 6:13 pm, Chris Gordon-Smith <use.addr...@my.homepage>
>> wrote:
>>
>>> James Kanze wrote:
>>     [...]
>>
>>> True enough. In the case of my Action_Requests however, I
>>> don't want to use the derived class' interface. I always want
>>> to call polymorphically through the base interface.
>> In that case, you probably also want a factory which returns the
>> actual instances, so that the client code doesn't even know that
>> the derived classes exist.  (And of course, in that case,
>> whether the virtual functions are public or are private in the
>> derived class really doesn't matter, since the client code
>> doesn't have access to the derived class definition.)
>>
> 
> Yes. I have something like this. I make objects of the derived class
> by reading input from a file. Depending on the kind of 'request' in
> the file. I make an object of the appropriate derived class. Once this
> has been done, nothing in the client code that manipulates the objects
> knows about the derived classes.
> 
> (Hope this posting gets through OK. I can't get onto my news server at
> the moment and so have had to go onto Google groups.)
> 
> Chris Gordon-Smith
> www.simsoup.info
> 
If you want to "hide" the implementation classes from client code, put 
them into a anonymous namespace.  That way, they can't ever access the 
symbols that represent them, and they can only ever have access to your 
instance through base class pointers or references.

-- 
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
0
Reply newsgroup.spamfilter (920) 5/29/2008 5:08:14 PM 

Daniel Pitts wrote:

> Chris Gordon-Smith wrote:
>> On May 28, 9:12 pm, James Kanze <james.ka...@gmail.com> wrote:
>>> On May 28, 6:13 pm, Chris Gordon-Smith <use.addr...@my.homepage>
>>> wrote:
>>>
>>>> James Kanze wrote:
>>>     [...]
>>>
>>>> True enough. In the case of my Action_Requests however, I
>>>> don't want to use the derived class' interface. I always want
>>>> to call polymorphically through the base interface.
>>> In that case, you probably also want a factory which returns the
>>> actual instances, so that the client code doesn't even know that
>>> the derived classes exist.  (And of course, in that case,
>>> whether the virtual functions are public or are private in the
>>> derived class really doesn't matter, since the client code
>>> doesn't have access to the derived class definition.)
>>>
>> 
>> Yes. I have something like this. I make objects of the derived class
>> by reading input from a file. Depending on the kind of 'request' in
>> the file. I make an object of the appropriate derived class. Once this
>> has been done, nothing in the client code that manipulates the objects
>> knows about the derived classes.
>> 
>> (Hope this posting gets through OK. I can't get onto my news server at
>> the moment and so have had to go onto Google groups.)
>> 
>> Chris Gordon-Smith
>> www.simsoup.info
>> 
> If you want to "hide" the implementation classes from client code, put
> them into a anonymous namespace.  That way, they can't ever access the
> symbols that represent them, and they can only ever have access to your
> instance through base class pointers or references.
> 

Interesting. I just tried that, but now unfortunately my program won't link
because my factory class can't see the derived class' constructor.

Chris Gordon-Smith
www.simsoup.info
0
Reply use.address (75) 5/29/2008 5:39:31 PM 

Chris Gordon-Smith wrote:
> Daniel Pitts wrote:
> 
>> Chris Gordon-Smith wrote:
>>> On May 28, 9:12 pm, James Kanze <james.ka...@gmail.com> wrote:
>>>> On May 28, 6:13 pm, Chris Gordon-Smith <use.addr...@my.homepage>
>>>> wrote:
>>>>
>>>>> James Kanze wrote:
>>>>     [...]
>>>>
>>>>> True enough. In the case of my Action_Requests however, I
>>>>> don't want to use the derived class' interface. I always want
>>>>> to call polymorphically through the base interface.
>>>> In that case, you probably also want a factory which returns the
>>>> actual instances, so that the client code doesn't even know that
>>>> the derived classes exist.  (And of course, in that case,
>>>> whether the virtual functions are public or are private in the
>>>> derived class really doesn't matter, since the client code
>>>> doesn't have access to the derived class definition.)
>>>>
>>> Yes. I have something like this. I make objects of the derived class
>>> by reading input from a file. Depending on the kind of 'request' in
>>> the file. I make an object of the appropriate derived class. Once this
>>> has been done, nothing in the client code that manipulates the objects
>>> knows about the derived classes.
>>>
>>> (Hope this posting gets through OK. I can't get onto my news server at
>>> the moment and so have had to go onto Google groups.)
>>>
>>> Chris Gordon-Smith
>>> www.simsoup.info
>>>
>> If you want to "hide" the implementation classes from client code, put
>> them into a anonymous namespace.  That way, they can't ever access the
>> symbols that represent them, and they can only ever have access to your
>> instance through base class pointers or references.
>>
> 
> Interesting. I just tried that, but now unfortunately my program won't link
> because my factory class can't see the derived class' constructor.
> 
> Chris Gordon-Smith
> www.simsoup.info
Using the anonymous namespace approach requires that anything using the 
"hidden" namespace are in the same compilation unit (same file basically)

so you have a factory.h file which declares your factory and base class, 
and a factory.cc file which defines the factory, base, and hidden 
concrete classes.

-- 
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
0
Reply newsgroup.spamfilter (920) 5/29/2008 6:56:22 PM
comp.lang.c++ 49416 articles. 22 followers.

23 Replies
25 Views

(page loaded in 0.245 seconds)

Similiar Articles:

Changing access specifiers during inheritance - comp.lang.c++ ...
... class that contains virtual functions (either pure virtual or non-pure virtual functions) and override them with a different access specifier (i.e. private vs. public).

Solution to "cannot instantiate abstract class due to following ...
... supposedly overriding function lacks "const" qualifier > virtual int getNumber(); Ibid. > private: > int n; > }; > > class D: public virtual B ...

Problem with pthreads C++ wrapper class on Linux - comp ...
Derive from this // class and override the function call ... public ThreadFunction { public: virtual void ... I think it's a call to a pure virtual function from a ...

Java Collections List : Converting from List '
I have a function that returns a list like ... select; } @Override public java ... public class Column > { > private final String string1; > private ...

Best design for my classes to avoid code duplication? - comp.lang ...
class BasicDevice : public IDevice { public: virtual ... }; class SomeSpecificDevice : private ... just call the Create virtual function to make a factory of ...

glut and (Visual)C++ - comp.graphics.api.opengl
The callback functions are ... World > { > private: > static World* m_this; // set to "this" in constuctor > [...] > public: > World(); > virtual ...

catching std::exception by value - comp.lang.c++.moderated ...
I have the following code: class foobar_error: public std::logic ... If you wanted, you could override the what() virtual function again in your foobar_error class.

Vptr - comp.lang.c++.moderated
So the static data member of a class Y derived from X and overriding the virtual function ... Base() {} }; class Derived1 : public Base { public: virtual void ...

Iterating over a String - comp.lang.java.help
... data; } @Override public Iterator<Character> iterator() { return new StringIterator(data); } private ... simple string-to-number function ...

Swing uses bad features - comp.lang.java.gui
However, due to polymorphism, if I override ... String requested_text = null; private String converted_text = null; public ... So we are talking about "normal" virtual ...

Const constructor - comp.lang.c++.moderated
... the non const class should also have private ... class ArrayAccessInterface { public: virtual ... mention this before, but I can't afford virtual functions ...

What is "plain old data" type (POD)? - comp.lang.c++.moderated ...
... no virtual functions; and if all their non-static data members are public ... Private or protected non-static data members, 4. Base classes, 5. Virtual functions, 6.

nitializing a static vector <> of integers (this static vector
... interface): class SignalHandlerBase { public: virtual ... SignalHandler (); > > //Remaining member function declarations omitted for brevity > ... > private ...

ptr versus const ptr& - comp.lang.c++.moderated
... class: template<class X> class ptr { private: X* inner_ptr; public ... NOTE: these methods are like Lisp's eq function ... to following ... > class B { > public: > virtual ...

Bridge patterns and protected inheritance? - comp.lang.c++ ...
class base_handle { private: base_body * _body ... base_body& base_body(const base_body& src); virtual ... multiple inheritance ... comp.lang.c++.moderated functions ...

Overriding public virtual functions with private functions in C++ ...
Is there is any reason to make the permissions on an overridden C++ virtual function different from the base class? Is there any danger in doing so?

Private Virtual Functions - Microsoft Corporation: Software ...
The way private virtual functions are handled in derived ... ref class Foo { protected: virtual void g(); }; ref class Bar : Foo { public: virtual void g() override; };

7/28/2012 4:13:19 AM


Reply:



Privacy Policy | All Times Are GMT(UTC) | powered by