Can you call private members from a different class?

Standing by OO principles we would have to say "Private memebers are only visible to to the class in which it is defined"

This is the MSDN Defintion for the C# private keyword
"The private keyword is a member access modifier. Private access is the least permissive access level. Private members are accessible only within the body of the class or the struct in which they are declared.

Nested types in the same body can also access those private members.

It is a compile-time error to reference a private member outside the class or the struct in which it is declared."

The whole idea of Private access modifier being only a language construct and not an runtime principle is quite interesting.It brings up one of the core concepts of accessmodifiers only down to the degree of language compilation and enforcing them during runtime still takes a back seat.

The whole fundamental of .NET is the CLR and if we can me an excution of a private method at runtime, would this defeat the the purpose of making something private? To lay it out, this is what I am trying to ask.

 

using System;

using System.Reflection;

using System.Collections.Generic;

using System.Text;

public class A

{

    private static void YouCantCallMe()

    {

        Console.WriteLine("I got called.");

    }

}

class Program

{

    static void Main(string[] args)

    {

        Type t = typeof(A);

        t.InvokeMember("YouCantCallMe", BindingFlags.InvokeMethod |

                                BindingFlags.Static | BindingFlags.NonPublic, null, null, null);

    }

}

 

The runtime with the help of reflection helps you get around one of the principles of OO which prohibits visibility of private memebers outside the current body. Personally i find it pretty cool that i can do stuff like this with reflection.
Any thoughts on this ?

Comments

• Anonymous
  July 06, 2006
  I think this is useful when doing test-driven development. Though normally one would only test the public interface, sometimes it is helpful to check the private methods as well.
  
  Jonathan
• Anonymous
  July 06, 2006
  My fear is that private implementations can change and break the reflection code at runtime. Sure, public interfaces change all the time, too. But at least the person who is changing the public interface is aware they are making a breaking change and can document the change (and look at compile time errors to see what they are breaking). :)
• Anonymous
  July 06, 2006
  If you're going through reflection to access a member, you're doing something the type wasn't designed for.  If it changes and breaks your code, you have to accept it.
  
  Granted, some things are only feasible through reflection, and so you need to code against such breakages.  Binding to a specific version of an assembly is one way.
  
• Anonymous
  July 07, 2006
  The comment has been removed
• Anonymous
  August 03, 2006
  Although the CLR is mainly OO, it was design to support OO and other types of languages that may be or may not be totally OO like F# (functional language) and IronPython (dynamic language).
  Reflection is especially useful in implementing late binding; which is used extensively by dynamic languages.
  Anyway you can turn Reflection off with the appropriate CAS (Code Access Security) permissions.
  
• Anonymous
  August 06, 2006
  Yes Alfred, I quite agree with you and ofcourse we have CAS :)