Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Public to Private

Reply
Thread Tools

Public to Private

 
 
Ajay Martin
Guest
Posts: n/a
 
      11-16-2006
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?


 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      11-16-2006
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


 
Reply With Quote
 
 
 
 
Phlip
Guest
Posts: n/a
 
      11-16-2006
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

 
Reply With Quote
 
Salt_Peter
Guest
Posts: n/a
 
      11-16-2006

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.

 
Reply With Quote
 
Pete C
Guest
Posts: n/a
 
      11-17-2006
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;
}

 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      11-17-2006
* 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?
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      11-17-2006
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


 
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