Public to Private

Discussion in 'C++' started by Ajay Martin, Nov 16, 2006.

  1. Ajay Martin

    Ajay Martin Guest

    Why would it be reasonable for someone to argue that it is incorrect to
    allow a public member inherited from a public base class to be redefined as
    private?
     
    Ajay Martin, Nov 16, 2006
    #1
    1. Advertising

  2. Ajay Martin wrote:
    > Why would it be reasonable for someone to argue that it is incorrect
    > to allow a public member inherited from a public base class to be
    > redefined as private?


    Could be due to the same views that cause people to continue the
    discussions whether 'square' should inherit from 'rectangle' or
    vice versa, and whether it should be done publicly or privately.

    C++ is not an OO language. It's a language with elements of OOP.
    Live and let live, I say. If somebody wants to argue against
    redeclaring a public inherited member as private, let them prove
    their point. But don't stop them from arguing.

    Why would it be reasonable for a dog to lick its ...? Ask the
    dog.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Nov 16, 2006
    #2
    1. Advertising

  3. Ajay Martin

    Phlip Guest

    Ajay Martin wrote:

    > Why would it be reasonable for someone to argue that it is incorrect to
    > allow a public member inherited from a public base class to be redefined as
    > private?


    Firstly, it's "reasonable" in our industry for anyone to argue
    anything. The ability to propose and debate techniques is a critical
    aspect of being a software engineer.

    Now discuss whether to actually do it.

    There's no syntactic reason not to do that.

    The technical reason is "principle of least surprise". The Liskov
    Substitution Principle implies that two objects that share an interface
    should share it semantically, not just syntactically. Client code,
    calling those objects, shouldn't be able, in the normal course of the
    client's activities, to tell the difference between the two items.

    There are other ways to use object polymorphically besides pointers or
    references to base classes. If you use one, such as generics, you might
    surprise a client, when a public member suddenly becomes private.

    So don't do that, and add it to the list of things your team knows not
    to do.

    --
    Phlip
     
    Phlip, Nov 16, 2006
    #3
  4. Ajay Martin

    Salt_Peter Guest

    Ajay Martin wrote:
    > Why would it be reasonable for someone to argue that it is incorrect to
    > allow a public member inherited from a public base class to be redefined as
    > private?


    Lets suppose that the derived class needs access to the public member
    but protects the user of the class by not providing public access to
    it. Why should that be forbidden? Why should a critical public member
    be forced to expose itself? Its called encapsulation, is it not?
    So reasonable it is not - its counter-productive. Its like saying that
    deriving from base is a waist of time.

    Now, if he/she argued that a virtual member function was made private,
    then the arguement may hold. Although, even that could be warranted in
    the case that the inheritance scheme is less than perfect.
     
    Salt_Peter, Nov 16, 2006
    #4
  5. Ajay Martin

    Pete C Guest

    Ajay Martin wrote:
    > Why would it be reasonable for someone to argue that it is incorrect to
    > allow a public member inherited from a public base class to be redefined as
    > private?


    For me, it would be illogical and potentially confusing (I don't say
    "incorrect") to do this, because the member may still be changed via a
    pointer (or reference) to the base class type. So the derived class
    will have to treat the member as though it were public anyway.

    So to redefine the member as private won't add any meaningful access
    control, and will be counter-intuitive for users of the derived class.
    I can't think of a good reason to do it, but it's best to keep an open
    mind in case a good reason turns up later.

    Example:

    struct Base
    {
    int member;
    };

    struct Derived : public Base
    {
    private:
    using Base::member;
    };

    int main()
    {
    Derived derived;

    // This is illegal: "member" is private in Derived
    derived.member = 1;

    // But access via pointer-to-base-class is OK!
    Base *pb = &derived;
    pb->member = 1;
    }
     
    Pete C, Nov 17, 2006
    #5
  6. * Pete C:
    >
    > So to redefine the member as private won't add any meaningful access
    > control, and will be counter-intuitive for users of the derived class.
    > I can't think of a good reason to do it, but it's best to keep an open
    > mind in case a good reason turns up later.


    In the case of a spaghetti system it's sometimes useful to replace

    class Something: public Spaghetti
    {
    public:
    ...
    };

    with

    class Something: protected Spaghetti
    {
    public:
    Spaghetti& asSpaghetti() { return *this; }
    Spaghetti const& asSpaghetti() const { return *this; }

    using SpaghettiClass::memberD;
    using SpaghettiClass::memberZ;
    ...
    };

    in order to ascertain what's actually /used/ (by Something's client
    code) of all that stuff inherited from Spaghetti.

    Of course one may end up finding that most of the spaghetti stuff is
    used, in which case the gain is only knowing that class Something is not
    a good place to start cleaning up the system, and any insights come by
    while adding necessary 'using' clauses to get the thing to compile.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Nov 17, 2006
    #6
  7. Pete C wrote:
    > Ajay Martin wrote:
    >> Why would it be reasonable for someone to argue that it is incorrect
    >> to allow a public member inherited from a public base class to be
    >> redefined as private?

    >
    > For me, it would be illogical and potentially confusing (I don't say
    > "incorrect") to do this, because the member may still be changed via a
    > pointer (or reference) to the base class type. So the derived class
    > will have to treat the member as though it were public anyway.
    >
    > So to redefine the member as private won't add any meaningful access
    > control, and will be counter-intuitive for users of the derived class.
    > I can't think of a good reason to do it, but it's best to keep an open
    > mind in case a good reason turns up later.
    >
    > Example:
    >
    > struct Base
    > {
    > int member;
    > };
    >
    > struct Derived : public Base
    > {
    > private:
    > using Base::member;
    > };
    >
    > int main()
    > {
    > Derived derived;
    >
    > // This is illegal: "member" is private in Derived
    > derived.member = 1;
    >
    > // But access via pointer-to-base-class is OK!
    > Base *pb = &derived;
    > pb->member = 1;
    > }


    You misread the question. It contains the term "redefined". You just
    re*declared* 'member' in 'Derived', you didn't *redefine* it. And for
    what it's worth, everybody else seemed to think the question was about
    member functions, not data.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Nov 17, 2006
    #7
    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,376
    smith
    Dec 8, 2004
  2. SpamProof
    Replies:
    0
    Views:
    583
    SpamProof
    Oct 21, 2003
  3. Kevin Spencer
    Replies:
    2
    Views:
    3,314
    Kevin Spencer
    Sep 15, 2004
  4. qazmlp
    Replies:
    19
    Views:
    798
    Daniel T.
    Feb 4, 2004
  5. DaveLessnau
    Replies:
    3
    Views:
    429
    Howard
    May 16, 2005
Loading...

Share This Page