Блог

Рассмотрим следующий шаблон кода:

 // Each foo keeps a reference to its manager
class Foo
{
    private FooManager m_manager;
}

// Manager keeps a list of all foos
class FooManager
{
    private List<Foo> m_foos;
}
  

Проблема: нет способа создать новый Foo и обновить как список m_foos в FooManager, так и ссылку m_manager в новом экземпляре Foo, не раскрывая некоторые личные данные публично (и рискуя, что кто-то отменит синхронизацию списка с реальными Foo).

Например. можно было бы реализовать конструктор Foo(менеджер FooManager) в Foo. Он мог бы установить ссылку m_manager, но у него нет способа получить доступ к списку m_foos. Или вы могли бы реализовать метод createFoo() в диспетчере. Он может получить доступ к списку m_foos, но у него нет способа установить m_manager в Foo.

В C , очевидно, можно было бы объявить FooManager другом Foo, чтобы выразить намерение проекта, но в C # это невозможно. Я также знаю, что я мог бы сделать Foo внутренним классом FooManager для получения доступа, но это тоже не решение (что, если Foo может принадлежать более чем одному классу manager?)

Кстати. Я знаю о «внутреннем» доступе в .NET, но для этого требуется, чтобы Foo и FooManager работали самостоятельно в отдельной сборке, что неприемлемо.

Есть ли обходные пути для этого, не делая частные материалы общедоступными?

Если я все правильно понимаю:

 public abstract class FooBus
{
    protected static FooBus m_bus;
}

public sealed class Foo : FooBus
{
    private FooManager m_manager;

    public Foo(FooManager fm)
    {
        if (fm == null)
        {
            throw new ArgumentNullException("Use FooManager.CreateFoo()");
        }

        if (m_bus != fm)
        {
            throw new ArgumentException("Use FooManager.CreateFoo()");
        }

        m_manager = fm;
    }
}

public class FooManager : FooBus
{
    private List<Foo> m_foos = new List<Foo>();

    public Foo CreateFoo()
    {
        m_bus = this;
        Foo f = new Foo(this);
        m_foos.Add(f);
        m_bus = null;

        return f;
    }
}
  

Одним из вариантов было бы использовать частный вложенный класс для Foo, который реализует общедоступный интерфейс:

 public interface IFoo
{
    // Foo's interface
}

public sealed class FooManager
{
    private readonly List<Foo> _foos = new List<Foo>();

    public IFoo CreateFoo()
    {
        var foo = new Foo(this);
        _foos.Add(foo);
        return foo;
    }

    private class Foo : IFoo
    {
        private readonly FooManager _manager;

        public Foo(FooManager manager)
        {
            _manager = manager;
        }
    }
}
  

Поскольку класс Foo является частным вложенным классом, его нельзя создать вне FooManager, и поэтому CreateFoo() метод FooManager гарантирует, что все остается синхронизированным.

Что вы можете сделать, так это создать свои классы внутри пространства имен другого типа, давайте назовем это «module» (не обманывайтесь ключевым словом class, это не реальный класс):

 public static partial class FooModule {

  // not visible outside this "module"
  private interface IFooSink {
    void Add(Foo foo);
  }

  public class Foo {
    private FooManager m_manager;
    public Foo(FooManager manager) {
      ((IFooSink)manager).Add(this);
      m_manager = manager;
    }
  }

  public class FooManager : IFooSink {
    private List<Foo> m_foos = new List<Foo>();
    void IFooSink.Add(Foo foo) {
      m_foos.Add(foo);
    }
  }

}
  

Поскольку «модуль» является частичным классом, вы все равно можете создавать другие элементы внутри него в других файлах в том же модуле компиляции.

Как насчет наличия базового класса:

 class FooBase
{
     protected static readonly Dictionary<Foo,FooManager> _managerMapping = new Dictionary<Foo,FooManager>();
}
  

Тогда Foo и FooManager имеют FooBase в качестве базового класса и могут обновлять свое отображение, не предоставляя его извне. Тогда вы можете быть уверены, что никто не изменит эту коллекцию извне.

Тогда в Foo у вас есть свойство, Manager которое вернет связанного с ним менеджера и подобное, свойство Foos в Manager , которое выдаст все Foo.

В этом примере единственные, кто может нарушить синхронизацию отношений, — это Foo и сам менеджер. createFoo() вызывается менеджером для создания «управляемого foo». Кто-то другой может создать Foo, но он не может передать его в управление менеджеру без «согласия» менеджера.

 public class Foo
{
    private FooManager m_manager;

    public void SetManager(FooManager manager)
    {
        if (manager.ManagesFoo(this))
        {
            m_manager = manager;
        }
        else
        {
            throw new ArgumentException("Use Manager.CreateFoo() to create a managed Foo");
        }
    }
}

public class FooManager
{
    private List<Foo> m_foos = new List<Foo>();

    public Foo CreateFoo()
    {
        Foo foo = new Foo();
        m_foos.Add(foo);
        foo.SetManager(this);

        return foo;
    }

    public bool ManagesFoo(Foo foo)
    {
        return m_foos.Contains(foo);
    }
}
  

Я рассматриваю возможность использования отражения.

Не существует хорошего решения для неудачного дизайна (отсутствие друзей в среде CLR).

Как насчет чего-то подобного:

 public class FriendClass
{
     public void DoSomethingInMain()
     {
         MainClass.FriendOnly(this);
     }
}

public class MainClass
{
    public static void FriendOnly(object Caller)
    {
        if (!(Caller is FriendClass) /* Throw exception or return */;

        // Code
    }
}
  

Конечно, это не мешает пользователю делать что-то подобное:

 public class NonFriendClass
{
    public void DoSomething()
    {
         MainClass.FriendOnly(new FriendClass());
    }
}
  

Я полагаю, что может быть способ обойти это, но любые идеи, которые у меня есть, начинают становиться довольно избыточными.