• 12
• 12
• 9
• 10
• 13

# [.net] Allowing one class to access the private members of another

This topic is 4808 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Is there a way (in C#) to allow one class to access the private members of another? I am aware of the internal keyword, but this doesn't suit this particular purpose (I am looking for something more akin to C++'s 'friend' access modifier) I have tried nesting one class within the other which I thought would allow the outer class to access the private members of the nested class, but this doesn't seem to be the case (I was sure this worked before..) Any suggestions?

##### Share on other sites
If you nest classes, the inner class will be able to access the private (and all) members of the outer class, and the outer class will be able to access only the public members of the inner class.

##### Share on other sites
What about a simple get/set method?
private int nBlah;public int Blah{	get { return nBlah; }	set { nBlah = value; }}

Although I must admit that I don't recall the exact use of the friend modifier...haven't done C++ in quite a while now so I don't know if this will solve your problem.

##### Share on other sites
Yeah, the problem is that the private members should only be visible to one certain class. If I were to use a get/set property then it would basically be accessable to all of the program.

The friend modifier in C++ let you specify which classes were able to view the private members of a certain class. This is missing in C#, and the closest alternative is the internal modifier that makes the private members visible to all classes in that assembly which isn't really much use in this case..

##### Share on other sites
Oh yeah, I remember that thing now. Sorry then...can't think of a solution for you.

##### Share on other sites
Any perticular reason internal doesn't suit?

One thing I sometimes do, is have something along the lines of:

class A
...

class B
{
private int x;

internal int getX(A a)
{
if (a!=null)
return x;
throw...
}

}

But when I'm using it, A is usuall an internal class that doesn't have a public constructor, so you can't hack around it, and the returned value depends on A.. But it could still work in this case. Just a bit extreme when simply making it internal should be fine.

##### Share on other sites
Quote:
 Original post by RipTornAny perticular reason internal doesn't suit?

Well, hopefully I'm understanding its usage correctly. MSDN states that 'Internal members are accessible only within files in the same assembly' which I assume means that I'd have to compile any classes that use internal members in this way into a DLL and then use that when developing the main application. This could potentially lead to an application that relies on a number of DLLs which could just as easily be integrated into the main program EXE. That just seems a messy solution, and a little unnecessary when all I want to do is hide a few class members.

##### Share on other sites
If you have to let classes privately access each other members, then it's likely their responsibilities have been blurred a little bit. A class strictly speaking is the only thing that's supposed to directly alter it's own data.

If you make these members a property then that would give you access, you would then have to trust yourself not to abuse it.

Alternatively you could do something like

Foo GetFoo(Object requestor)

... and do a type check on requestor - return something if that object type is allowed access, otherwise throw an exception.

Though that does seem a little bit hacky to me.

##### Share on other sites
Quote:
 Well, hopefully I'm understanding its usage correctly. MSDN states that 'Internal members are accessible only within files in the same assembly' which I assume means that I'd have to compile any classes that use internal members in this way into a DLL and then use that when developing the main application. This could potentially lead to an application that relies on a number of DLLs which could just as easily be integrated into the main program EXE. That just seems a messy solution, and a little unnecessary when all I want to do is hide a few class members.

I don't remember precisely whether you have to compile as a DLL to use the internal keyword, but it actually doesn't matter... If you compile to a DLL, then any other DLL or EXE might use the code in the DLL, and thus you would want to use the internal keyword to prevent access to sensitive data by these other DLLs and EXEs. Howver, if you're compiling to an EXE, no other DLL or EXE can use ANY of the code in your EXE, and therefore the internal keyword would be simply redundant.