ReadOnlyCollection vs Liskov — как правильно моделировать неизменяемые представления изменяемой коллекции

Вы всегда можете иметь интерфейс графа (только для чтения) и расширить его с помощью интерфейса модифицируемого графа для чтения/записи:

public interface IDirectedAcyclicGraph
{
    int GetNodeCount();
    bool GetConnected(int from, int to);
}

public interface IModifiableDAG : IDirectedAcyclicGraph
{
    void SetNodeCount(int nodeCount);
    void SetConnected(int from, int to, bool connected);
}

(Я не могу понять, как разделить эти методы на get/set половины свойства.)

// Rubbish implementation
public class ConcreteModifiableDAG : IModifiableDAG
{
    private int nodeCount;
    private Dictionary<int, Dictionary<int, bool>> connections;

    public void SetNodeCount(int nodeCount) {
        this.nodeCount = nodeCount;
    }

    public void SetConnected(int from, int to, bool connected) {
        connections[from][to] = connected;
    }

    public int GetNodeCount() {
        return nodeCount;
    }

    public bool GetConnected(int from, int to) {
        return connections[from][to];
    }
}

// Create graph
IModifiableDAG mdag = new ConcreteModifiableDAG();
mdag.SetNodeCount(5);
mdag.SetConnected(1, 5, true);

// Pass fixed graph
IDirectedAcyclicGraph dag = (IDirectedAcyclicGraph)mdag;
dag.SetNodeCount(5);          // Doesn't exist
dag.SetConnected(1, 5, true); // Doesn't exist

Это то, что я хотел бы, чтобы Microsoft сделала со своими классами коллекций только для чтения - создала один интерфейс для поведения get-count, get-by-index и т. д. и расширила его интерфейсом для добавления, изменения значений и т. д.

Я не думаю, что ваше текущее решение с застройщиком слишком сложное.

Он решает две проблемы:

1. Нарушение LSP
   У вас есть редактируемый интерфейс, реализация которого никогда не вызовет NotSupportedExceptions для AddNode / AddEdge, и у вас есть нередактируемый интерфейс, в котором вообще нет этих методов.

2. Временная связь
   Если бы вы использовали один интерфейс вместо двух , этот один интерфейс должен каким-то образом поддерживать «фазу инициализации» и «фазу неизменяемости», скорее всего, с помощью некоторых методов, отмечающих начало и, возможно, конец этих фаз.

Коллекции только для чтения в .Net не противоречат LSP.

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

Многие классы представляют объекты предметной области, которые могут находиться в одном из нескольких состояний, и не каждая операция допустима во всех состояниях: потоки могут быть открыты только один раз, окна не могут быть показаны после их удаления и т. д.

Генерация исключений в этих случаях допустима, если есть способ проверить текущее состояние и избежать исключений.

Коллекции .Net были разработаны для поддержки состояний: только чтение и чтение/запись. Именно поэтому присутствует метод IsReadWrite. Это позволяет вызывающим объектам проверять состояние коллекции и избегать исключений.

LSP требует, чтобы подтипы соблюдали контракт супертипа, но контракт — это больше, чем просто список методов; это список входных данных и ожидаемого поведения, основанного на состоянии объекта:

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

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

Вы можете использовать явные реализации интерфейса, чтобы отделить ваши методы модификации от операций, необходимых в версии только для чтения. Также в вашей реализации только для чтения есть метод, который принимает метод в качестве аргумента. Это позволяет изолировать построение DAC от навигации и запросов. см. приведенный ниже код и его комментарии:

// your read only operations and the
// method that allows for building
public interface IDac<T>
{
    IDac<T> Build(Action<IModifiableDac<T>> f);
    // other navigation methods
}

// modifiable operations, its still an IDac<T>
public interface IModifiableDac<T> : IDac<T>
{
    void AddEdge(T item);
    IModifiableDac<T> CreateChildNode();
}

// implementation explicitly implements IModifableDac<T> so
// accidental calling of modification methods won't happen
// (an explicit cast to IModifiable<T> is required)
public class Dac<T> : IDac<T>, IModifiableDac<T>
{
    public IDac<T> Build(Action<IModifiableDac<T>> f)
    {
        f(this);
        return this;
    }

    void IModifiableDac<T>.AddEdge(T item)
    {
        throw new NotImplementedException();
    }

    public IModifiableDac<T> CreateChildNode() {
        // crate, add, child and return it
        throw new NotImplementedException();
    }

    public void DoStuff() { }
}

public class DacConsumer
{
    public void Foo()
    {
        var dac = new Dac<int>();
        // build your graph
        var newDac = dac.Build(m => {
            m.AddEdge(1);
            var node = m.CreateChildNode();
            node.AddEdge(2);
            //etc.
        });

        // now do what ever you want, IDac<T> does not have modification methods
        newDac.DoStuff();
    }
}

Из этого кода пользователь может вызвать только Build(Action<IModifiable<T>> m), чтобы получить доступ к модифицируемой версии. и вызов метода возвращает неизменяемый. Невозможно получить к нему доступ как IModifiable<T> без преднамеренного явного приведения, которое не определено в контракте для вашего объекта.

Как мне это нравится (но, возможно, это только мне), чтобы иметь методы чтения в интерфейсе и методы редактирования в самом классе. Для вашей DAG очень маловероятно, что у вас будет несколько реализаций структуры данных, поэтому наличие интерфейса для редактирования графа является излишним и, как правило, не очень красивым.

Я считаю, что класс, представляющий структуру данных, и интерфейс, являющийся структурой чтения, довольно чист.

например:

public interface IDAG<out T>
{
    public int NodeCount { get; }
    public bool AreConnected(int from, int to);
    public T GetItem(int node);
}

public class DAG<T> : IDAG<T>
{
    public void SetCount(...) {...}
    public void SetEdge(...) {...}
    public int NodeCount { get {...} }
    public bool AreConnected(...) {...}
    public T GetItem(...) {...}
}

Затем, когда вам требуется редактирование структуры, вы передаете класс, если вам просто нужна структура только для чтения, передаете интерфейс. Это подделка «только для чтения», потому что вы всегда можете использовать класс, но в любом случае «только для чтения» никогда не бывает...

Это позволяет вам иметь более сложную структуру чтения. Как и в Linq, вы можете расширить структуру чтения с помощью методов расширения, определенных в интерфейсе. Например:

public static class IDAGExtensions
{
    public static List<T> FindPathBetween(this IDAG<T> dag, int from, int to)
    {
        // Use backtracking to determine if a path exists between `from` and `to`
    }

    public static IDAG<U> Cast<U>(this IDAG<T> dag)
    {
        // Create a wrapper for the DAG class that casts all T outputs as U
    }
}

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

Еще одна вещь, которую позволяет эта структура, — установить общий тип как out T. Это позволяет вам иметь контравариантность типов аргументов.

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

Для вашей DAG у вас, скорее всего, есть какая-то структура данных в файле или пользовательском интерфейсе, и вы можете передать все узлы и ребра как IEnumerables в конструктор вашего неизменяемого класса DAG. Затем вы можете использовать методы Linq для преобразования исходных данных в узлы и ребра.

Затем конструктор (или фабричный метод) может создавать частные структуры класса таким образом, чтобы он был эффективен для вашего алгоритма, и выполнять предварительную проверку данных, например ациклическую.

Это решение отличается от шаблона построителя тем, что итеративное построение структуры данных невозможно, но часто это и не требуется.

Лично мне не нравятся решения с отдельными интерфейсами для доступа для чтения и чтения/записи, реализованные одним и тем же классом, потому что функциональность записи на самом деле не скрыта... приведение экземпляра к интерфейсу чтения/записи раскрывает изменяющиеся методы. Лучшим решением в таком сценарии является наличие метода AsReadOnly, который создает действительно неизменяемую структуру данных, копируя данные.