encapsulation and friendship in C#

Question

I have a particular case in my current project.

I have:

public class A
{
   // etc.
}

public class B
{
   // etc.

   private void HandleSomeEvent(object parameter)
   {
      // Etc.
   }

   protected void HandleSomeOtherEvent(object parameter)
   {
      // Etc.
   }
}

I want:

1. A to be able to call the private method B.HandleSomeEvent, but no other class (but B) to be able to do that
2. A to be able to call the protected method B.HandleSomeOtherEvent, but no other class (but B and B's derived classes) to be able to do that

Is that possible in C# ?

1. If possible, how to do that?
2. If not possible, what are the alternatives which can protect B as much as possible from tampering from, say, a class C in the same assembly?

Answer 1

It is possible by emitting an interface of A then separating it from a concrete implementation. Once you did it you can write something like this

interface IA { }

class A : IA
{
    public static IA New() { return new A(); }
    private A() { }

    private void UseB() 
    {  
        var b = new B();
        b.HandleSomeEvent(this, null);
    }
}

class B
{ 
    public void HandleSomeEvent(A onlyAccess, object parameter) { }
}

In spite of the fact that HandleSomeEvent() is public only A can access it, since no one else can possibly get a concrete instance of A class. It has a private constructor, while the factory New() method returns an interface.

See my article Friends and internal interface members at no cost with coding to interfaces for details.

Answer 2

Is that possible in C# ?

No, unless you use reflection: private and protected members are not accessible from other classes.

If not possible, what are the alternatives which can protect B as much as possible from tampering from, say, a class C in the same assembly?

You could make B a nested class inside A and make it private. Then you can safely increase the visibility of the two methods of B as only A will be able to call them (unless reflection is used).

Answer 3

It is possible, but I'd usually just go with internal and assume that other classes in the assembly are well behaved.

You could for example pass delegates to these methods to class A which stores them in protected static fields/properties.

Answer 4

"2. If not possible, what are the alternatives which can protect B as much as possible from tampering from, say, a class C in the same assembly?"

Would checking the type info of the caller and throwing an exception work?

      [MethodImpl(MethodImplOptions.NoInlining)]  
      private void HandleSomeEvent(object parameter)  
      {  
            StackTrace stackTrace = new StackTrace();
            StackFrame stackFrame = stackTrace.GetFrame(1);
            MethodBase methodBase = stackFrame.GetMethod();

            if(methodBase.DeclaringType == typeof(ClassA)) // Okay.
            else if (methodBase.DeclaringType == typeof(ClassB)) // Okay.
            else throw new ApplicationException("Not Okay");
      }

Answer 5

1. No, it isn't (unless you use reflection, but that's just bad design)
2. Inheritance. But even then you won't be able to call the private method. You should think about your design and improve it.

As your class A should be able to call protected methods on B, I figure it has some sort of relationship with it. Ask yourself if there is a "is-a" relationship, as in "A is a B". In this case, you can make A inherit from B:

public class A : B
{
}

Now, you are able to call protected methods on B. But please, don't just inherit, always ask yourself if the inheritance makes sense.

Answer 6

You can mark both methods as internal:

internal void HandleSomeEvent(object parameter)
{
   // Etc.
}

protected internal void HandleSomeOtherEvent(object parameter)
{
   // Etc.
}

This makes the two methods visible to all classes in the same assembly (and also the second method visible to all classes derived from B).

There is no way to make a method visible to a specific other class. After all, you're the one who's controlling all classes in your assembly, so it's up to you to make sure that no other class than A calls the methods.

If you really need help from a tool with this, you could write an FxCop rule or create some kind of post-built action that checks for method calls from other classes than A.