How to emulate "friend" in C#?
<p>I need to implement a little bit of C++ style 'friend' functionality in C# and am looking for ideas.</p>

<p>Consider two classes that are very closely related: Node and NodePart. Nodes contain NodeParts which are added via public AddPart() calls from other systems with parts that those systems construct. Node needs to "reach into" NodePart to do some very specific notifications that NodePart will distribute via separate virtual protected methods to any derived classes after some processing. (For anyone familiar with component-based game object programming, this is the same kind of thing.)</p>

<p>I'd like to be able to have NodePart give Node a way to get at these few notification methods without letting any other types in the system do it. It's not necessary for Node to access any other NodePart internals, just forward along some private notifications.</p>

<p>Now, putting these classes in an assembly and using 'internal' would obviously do the trick, but I'm looking for a better pattern than that. (I'm not really interested in spawning new assemblies for every set of classes I'd like to do this with in the future.)</p>

<p>Aside from reflection + invoke, which is yucky and brittle, what other patterns can you think of to solve this problem here? My spidey senses tell me that interfaces are part of the solution, but I can't think of how.</p>

<p><em>(Note: I'm ok with security through obscurity. This system doesn't have to be 100% proof against misuse - just enough to discourage people from doing what they should not. We're not building defibrillators here.)</em></p>

<p><strong>Update:</strong> lots of the below answers require multiple assemblies. As I mention above, I'd really like avoid this. I do not want to put one system per assembly. We have enough of the things as is, and I can't go down the IL linking route due to our use of XAML. But thanks for the answers anyway. :)</p>

<p><strong>Update 2:</strong> I messed around in Linqpad and came up with a few options based on the answers below. Which do you like worst/least and why?</p>

<h1>Option 1: Obsolete</h1>

<pre><code>#pragma warning disable 612 // doc this
public sealed class Node : NodePart.SystemAccess {
#pragma warning restore 612
    NodePart _part;

    public NodePart Part {
        get { return _part; }
        set { _part = value; NotifyAdded(_part); }
    }
}

public class NodePart {
    void NotifyAdded() { Console.WriteLine("Part added"); }

    [Obsolete] public class SystemAccess // doc this
    {
        protected void NotifyAdded(NodePart part) { part.NotifyAdded(); }
    }
}
</code></pre>

<p>Not bad. A little weird but the weirdness is very confined. I'm leaning towards this one because it's so much more compact than the next option.</p>

<h1>Option 2: Access + Hack</h1>

<pre><code>public sealed class Node {
    static readonly NodePart.ISystemAccess _systemAccess;

    static Node() {
        _systemAccess = (NodePart.ISystemAccess)typeof(NodePart)
            .GetNestedTypes(BindingFlags.NonPublic)
            .Single(t =&gt; t.Name == "SystemAccess")
            .GetConstructor(Type.EmptyTypes)
            .Invoke(null);
    }

    NodePart _part;

    public NodePart Part {
        get { return _part; }
        set { _part = value; _systemAccess.NotifyAdded(_part); }
    }
}

public class NodePart {
    void NotifyAdded() { Console.WriteLine("Part added"); }

    internal interface ISystemAccess {
        void NotifyAdded(NodePart part);
    }

    class SystemAccess : ISystemAccess {
        void ISystemAccess.NotifyAdded(NodePart part) {
            part.NotifyAdded();
        }
    }
}
</code></pre>

<p>Hacka hacka hacka. My original version didn't have the reflect+invoke and would have relied on SystemAccess being non-obvious. That might be ok too but I kind of like the bit of extra security I get here, even though it's probably not necessary.</p>
