Private member

[Alan]

On the book C# for Experienced Programmer by Deitel, page 152, Software
Engineering Observation 5.13:

'When one object of a class has a reference to another object of the same
class, the first object can access all the second object's data and methods
(including those that are private)'

Why?

I am not sure does that refers to:
1) The first object itself is pointing to the second object
OR
2) The first object has a member which is pointing to the second object ?

[Michael Culley]

"Alan" <NO**************@yahoo.com.au> wrote in message
news:u6*************@TK2MSFTNGP15.phx.gbl...

'When one object of a class has a reference to another object of the same
class, the first object can access all the second object's data and methods (including those that are private)'

I think I remember coming across this once. Have a look at the code below,
Class1 can call ShowMessage on an instance of itself but class2 cannot.

--
Michael Culley
using System;

namespace TestStuff
{
public class SomeClass
{
public SomeClass()
{
}

private void ShowMessage()
{
System.Windows.Forms.MessageBox.Show("ShowMessage called");
}

public void DoIt(SomeClass SC)
{
SC.ShowMessage();
}
}

public class SomeClass2
{
public SomeClass2()
{
}

public void DoIt(SomeClass SC)
{
SC.ShowMessage();//<---- error
}
}
}

[Jon Skeet [C# MVP]]

Alan <NO**************@yahoo.com.au> wrote:

On the book C# for Experienced Programmer by Deitel, page 152, Software
Engineering Observation 5.13:

'When one object of a class has a reference to another object of the same
class, the first object can access all the second object's data and methods
(including those that are private)'

Why?

I am not sure does that refers to:
1) The first object itself is pointing to the second object
OR
2) The first object has a member which is pointing to the second object ?

That sounds like a bad explanation for: "Private access is limited by
location of code, not the instance it's operating on."

In other words, any method in a type can use private members of another
instance of the type. For instance:

using System;

public class Test
{
int x;

Test (int x)
{
this.x = x;
}

static void Main(string[] args)
{
Test a = new Test(5);
Test b = new Test(0);
b.Foo(a);
}

void Foo (Test t)
{
Console.WriteLine (t.x);
}
}

Here, Foo called on b is still able to access the private members of t.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Mark Broadbent]

This is really bothering me.
Obviously Ive seen this before, but having read further books about OO
concepts, isn't this really breaking the encapsulation of the object? I
would have thought that for strict adherance to OO, access should be limited
by object/instance -or am I misguided?

Br,

Mark.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Alan <NO**************@yahoo.com.au> wrote:

On the book C# for Experienced Programmer by Deitel, page 152, Software
Engineering Observation 5.13:

'When one object of a class has a reference to another object of the same
class, the first object can access all the second object's data and
methods
(including those that are private)'

Why?

I am not sure does that refers to:
1) The first object itself is pointing to the second object
OR
2) The first object has a member which is pointing to the second object ?

That sounds like a bad explanation for: "Private access is limited by
location of code, not the instance it's operating on."

In other words, any method in a type can use private members of another
instance of the type. For instance:

using System;

public class Test
{
int x;

Test (int x)
{
this.x = x;
}

static void Main(string[] args)
{
Test a = new Test(5);
Test b = new Test(0);
b.Foo(a);
}

void Foo (Test t)
{
Console.WriteLine (t.x);
}
}

Here, Foo called on b is still able to access the private members of t.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Mark Broadbent <no****@nospam.com> wrote:

This is really bothering me.
Obviously Ive seen this before, but having read further books about OO
concepts, isn't this really breaking the encapsulation of the object? I
would have thought that for strict adherance to OO, access should be limited
by object/instance -or am I misguided?

I don't think it really breaks encapsulation. All kinds of things
become basically impossible unless you can do this, IMO. For instance,
implementing Equals in an efficient manner if you don't have access to
private members of both sides.

Admittedly I've only really used Java and C# when it comes to OO
languages (dabbled in C++, but not done a lot) so maybe I'm missing the
problem here - but if I am, it's one that's never bitten me...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Richard Blewett [DevelopMentor]]

You would also have a problem with creating static factory methods that create instances of otherwise non-creatable classes, e.g.

class Foo
{
private Foo()
{
}
public static Foo CreateFoo()
{
return new Foo();
}
}

(obviously the above example doesn't show a particularly useful class and factory but its the pattern I'm attempting to show - the static member using a private instance constructor)

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

I don't think it really breaks encapsulation. All kinds of things
become basically impossible unless you can do this, IMO. For instance,
implementing Equals in an efficient manner if you don't have access to
private members of both sides.

[Doug Forster]

Its the same rule in both C++ and Delphi.

Cheers

Doug Forster

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m...

Mark Broadbent <no****@nospam.com> wrote:

This is really bothering me.
Obviously Ive seen this before, but having read further books about OO
concepts, isn't this really breaking the encapsulation of the object? I
would have thought that for strict adherance to OO, access should be
limited
by object/instance -or am I misguided?

I don't think it really breaks encapsulation. All kinds of things
become basically impossible unless you can do this, IMO. For instance,
implementing Equals in an efficient manner if you don't have access to
private members of both sides.

Admittedly I've only really used Java and C# when it comes to OO
languages (dabbled in C++, but not done a lot) so maybe I'm missing the
problem here - but if I am, it's one that's never bitten me...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Alan]

In Delphi, if classes are put in a same unit(in Delphi term) or file,
private members/methods of a class are accessible by other classes in the
same unit. It seems breaks the OO concepts when I came to learn OO.

"Doug Forster" <doug_ZAPTHIS_AT_ZAPTHIS_TONIQ_DOT_CO_DOT_NZ> wrote in
message news:uH**************@TK2MSFTNGP10.phx.gbl...

Its the same rule in both C++ and Delphi.

Cheers

Doug Forster

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m...

Mark Broadbent <no****@nospam.com> wrote:

This is really bothering me.
Obviously Ive seen this before, but having read further books about OO
concepts, isn't this really breaking the encapsulation of the object? I
would have thought that for strict adherance to OO, access should be
limited
by object/instance -or am I misguided?

I don't think it really breaks encapsulation. All kinds of things
become basically impossible unless you can do this, IMO. For instance,
implementing Equals in an efficient manner if you don't have access to
private members of both sides.

Admittedly I've only really used Java and C# when it comes to OO
languages (dabbled in C++, but not done a lot) so maybe I'm missing the
problem here - but if I am, it's one that's never bitten me...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Willem van Rumpt]

Yes, Delphi has some serious flaws in it's OO concepts. It seems to have
about 3.5 access modifiers ;)

published = public + available for some "reflection style" operations
public = access for all
protected = descendant and unitscope access
private = unitscope access

so to get access to protected members of a class, just declare and use a
"dummy" descendant in the unit where you need access to the protected
members. So effictively "protected" means "public if you want to".
They even included this in Delphi 8 as a feature because the hack is so
widely used, it would break almost all existing code.

Willem van Rumpt

Alan wrote:

In Delphi, if classes are put in a same unit(in Delphi term) or file,
private members/methods of a class are accessible by other classes in the
same unit. It seems breaks the OO concepts when I came to learn OO.

"Doug Forster" <doug_ZAPTHIS_AT_ZAPTHIS_TONIQ_DOT_CO_DOT_NZ> wrote in
message news:uH**************@TK2MSFTNGP10.phx.gbl...

Its the same rule in both C++ and Delphi.

Cheers

Doug Forster

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft. com...

Mark Broadbent <no****@nospam.com> wrote:

This is really bothering me.
Obviously Ive seen this before, but having read further books about OO
concepts, isn't this really breaking the encapsulation of the object? I
would have thought that for strict adherance to OO, access should be
limited
by object/instance -or am I misguided?

I don't think it really breaks encapsulation. All kinds of things
become basically impossible unless you can do this, IMO. For instance,
implementing Equals in an efficient manner if you don't have access to
private members of both sides.

Admittedly I've only really used Java and C# when it comes to OO
languages (dabbled in C++, but not done a lot) so maybe I'm missing the
problem here - but if I am, it's one that's never bitten me...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too