Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Override public virtual Functions with private Functions?

Reply
Thread Tools

Override public virtual Functions with private Functions?

 
 
Chris Gordon-Smith
Guest
Posts: n/a
 
      05-26-2008
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
 
Reply With Quote
 
 
 
 
dizzy
Guest
Posts: n/a
 
      05-26-2008
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

 
Reply With Quote
 
 
 
 
Chris Gordon-Smith
Guest
Posts: n/a
 
      05-26-2008
Daniel T. wrote:

> Chris Gordon-Smith <(E-Mail Removed)> 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
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-27-2008
On May 26, 2:56 pm, Chris Gordon-Smith <(E-Mail Removed)>
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:(E-Mail Removed)
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
 
Reply With Quote
 
anon
Guest
Posts: n/a
 
      05-27-2008
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?
 
Reply With Quote
 
Barry
Guest
Posts: n/a
 
      05-27-2008
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
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-27-2008
On May 27, 10:29 am, anon <(E-Mail Removed)> 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:(E-Mail Removed)
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
 
Reply With Quote
 
Chris Gordon-Smith
Guest
Posts: n/a
 
      05-27-2008
James Kanze wrote:

> On May 26, 2:56 pm, Chris Gordon-Smith <(E-Mail Removed)>
> 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
 
Reply With Quote
 
Chris Gordon-Smith
Guest
Posts: n/a
 
      05-27-2008
Daniel T. wrote:

> Chris Gordon-Smith <(E-Mail Removed)> wrote:
>> James Kanze wrote:
>> > Chris Gordon-Smith <(E-Mail Removed)> 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
 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      05-27-2008
On May 27, 8:56*am, Chris Gordon-Smith <(E-Mail Removed)>
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd loyola MCSE 4 11-15-2006 02:40 AM
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd loyola Microsoft Certification 3 11-14-2006 05:18 PM
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd loyola MCSD 3 11-14-2006 05:18 PM
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd realexxams@yahoo.com Microsoft Certification 0 05-10-2006 02:35 PM
microsoft.public.dotnet.faqs,microsoft.public.dotnet.framework,microsoft.public.dotnet.framework.windowsforms,microsoft.public.dotnet.general,microsoft.public.dotnet.languages.vb Charles A. Lackman ASP .Net 1 12-08-2004 07:08 PM



Advertisments