Can you call private members from a different class?

Can you call private members from a different class?

Rate This
  • Comments 6

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 ?

Leave a Comment
  • Please add 3 and 7 and type the answer here:
  • Post
  • 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
  • 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). :)
  • 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.
  • I agree with kfarmer.

    Further, in the world of software we know too well that there are some completely unanticipated circumstances where things don't work as they should be.
    In these circumstances breaking a OO rule sometimes can save the day.

    Invoking a member via reflection must be someway cumbersome at least to remember us that we are doing an unconventional -and hopefully temporary- thing.

    I have a vivid memory of a situation where a third party dll sometimes would crash&burn under high load. We needed immediate action because the site was hammered by visitors at that very moment. We tried to contact the component's programmer but he and the source code weren't available.
    So we used Reflector and found out that in a specific case the component 'forgot' to call one of its private methods and this leaded to the crash.
    When we successfully used reflection to intercept the problem and call ourselves that method we couldn't believe our eyes.
    What a party we threw!

    So, one must normally avoid to break OO rules, but having that possibility is vital.

  • 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.
  • Yes Alfred, I quite agree with you and ofcourse we have CAS :)
Page 1 of 1 (6 items)
Search