Override public virtual Functions with private Functions?

Discussion in 'C++' started by Chris Gordon-Smith, May 26, 2008.

  1. 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
     
    Chris Gordon-Smith, May 26, 2008
    #1
    1. Advertising

  2. Chris Gordon-Smith

    dizzy Guest

    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
     
    dizzy, May 26, 2008
    #2
    1. Advertising

  3. Daniel T. wrote:

    > Chris Gordon-Smith <> 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
     
    Chris Gordon-Smith, May 26, 2008
    #3
  4. Chris Gordon-Smith

    James Kanze Guest

    On May 26, 2:56 pm, Chris Gordon-Smith <>
    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:
    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
     
    James Kanze, May 27, 2008
    #4
  5. Chris Gordon-Smith

    anon Guest

    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?
     
    anon, May 27, 2008
    #5
  6. Chris Gordon-Smith

    Barry Guest

    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
     
    Barry, May 27, 2008
    #6
  7. Chris Gordon-Smith

    James Kanze Guest

    On May 27, 10:29 am, anon <> 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:
    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
     
    James Kanze, May 27, 2008
    #7
  8. James Kanze wrote:

    > On May 26, 2:56 pm, Chris Gordon-Smith <>
    > 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
     
    Chris Gordon-Smith, May 27, 2008
    #8
  9. Daniel T. wrote:

    > Chris Gordon-Smith <> wrote:
    >> James Kanze wrote:
    >> > Chris Gordon-Smith <> 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
     
    Chris Gordon-Smith, May 27, 2008
    #9
  10. Chris Gordon-Smith

    Daniel T. Guest

    On May 27, 8:56 am, Chris Gordon-Smith <>
    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.
     
    Daniel T., May 27, 2008
    #10
  11. Daniel T. wrote:

    > On May 27, 8:56 am, Chris Gordon-Smith <>
    > 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
     
    Chris Gordon-Smith, May 27, 2008
    #11
  12. Chris Gordon-Smith

    Daniel Pitts Guest

    Chris Gordon-Smith wrote:
    > Daniel T. wrote:
    >
    >> On May 27, 8:56 am, Chris Gordon-Smith <>
    >> 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/>
     
    Daniel Pitts, May 27, 2008
    #12
  13. Daniel Pitts wrote:

    > Chris Gordon-Smith wrote:
    >> Daniel T. wrote:
    >>
    >>> On May 27, 8:56 am, Chris Gordon-Smith <>
    >>> 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
     
    Chris Gordon-Smith, May 28, 2008
    #13
  14. Chris Gordon-Smith

    James Kanze Guest

    On May 27, 1:59 pm, "Daniel T." <> wrote:
    > Chris Gordon-Smith <> wrote:
    > > James Kanze wrote:
    > > > Chris Gordon-Smith <> 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:
    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
     
    James Kanze, May 28, 2008
    #14
  15. Chris Gordon-Smith

    James Kanze Guest

    On May 28, 2:01 am, Chris Gordon-Smith <>
    wrote:
    > Daniel Pitts wrote:
    > > Chris Gordon-Smith wrote:
    > >> Daniel T. wrote:


    > >>> On May 27, 8:56 am, Chris Gordon-Smith <>
    > >>> 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().

    --
    James Kanze (GABI Software) email:
    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
     
    James Kanze, May 28, 2008
    #15
  16. James Kanze wrote:

    > On May 28, 2:01 am, Chris Gordon-Smith <>
    > wrote:
    >> Daniel Pitts wrote:
    >> > Chris Gordon-Smith wrote:
    >> >> Daniel T. wrote:

    >
    >> >>> On May 27, 8:56 am, Chris Gordon-Smith <>
    >> >>> 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
     
    Chris Gordon-Smith, May 28, 2008
    #16
  17. Chris Gordon-Smith

    James Kanze Guest

    On May 28, 6:13 pm, Chris Gordon-Smith <>
    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:
    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
     
    James Kanze, May 28, 2008
    #17
  18. On May 28, 9:12 pm, James Kanze <> wrote:
    > On May 28, 6:13 pm, Chris Gordon-Smith <>
    > 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
     
    Chris Gordon-Smith, May 29, 2008
    #18
  19. Chris Gordon-Smith

    Daniel Pitts Guest

    Chris Gordon-Smith wrote:
    > On May 28, 9:12 pm, James Kanze <> wrote:
    >> On May 28, 6:13 pm, Chris Gordon-Smith <>
    >> 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/>
     
    Daniel Pitts, May 29, 2008
    #19
  20. Daniel Pitts wrote:

    > Chris Gordon-Smith wrote:
    >> On May 28, 9:12 pm, James Kanze <> wrote:
    >>> On May 28, 6:13 pm, Chris Gordon-Smith <>
    >>> 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
     
    Chris Gordon-Smith, May 29, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Charles A. Lackman
    Replies:
    1
    Views:
    1,362
    smith
    Dec 8, 2004
  2. qazmlp
    Replies:
    19
    Views:
    797
    Daniel T.
    Feb 4, 2004
  3. DaveLessnau
    Replies:
    3
    Views:
    428
    Howard
    May 16, 2005
  4. John Goche
    Replies:
    10
    Views:
    753
    Marcus Kwok
    Dec 8, 2006
  5. puzzlecracker
    Replies:
    8
    Views:
    906
    werasm
    Sep 29, 2007
Loading...

Share This Page