Сборка с msbuild и динамично ссылками проекта набора

Лично я не знаю каких-либо сторонних или предыдущих решений этой проблемы, поэтому приношу свои извинения, если я покрываю старые позиции. Но если бы я собирался реализовать какой-то стандарт неизменности для проекта, над которым я работал, я бы начал с чего-то вроде этого:

public interface ISnaphot<T>
{
    T TakeSnapshot();
}

public class Immutable<T> where T : ISnaphot<T>
{
    private readonly T _item;
    public T Copy { get { return _item.TakeSnapshot(); } }

    public Immutable(T item)
    {
        _item = item.TakeSnapshot();
    }
}

Этот интерфейс был бы реализован примерно так:

public class Customer : ISnaphot<Customer>
{
    public string Name { get; set; }
    private List<string> _creditCardNumbers = new List<string>();
    public List<string> CreditCardNumbers { get { return _creditCardNumbers; } set { _creditCardNumbers = value; } }

    public Customer TakeSnapshot()
    {
        return new Customer() { Name = this.Name, CreditCardNumbers = new List<string>(this.CreditCardNumbers) };
    }
}

И клиентский код будет выглядеть примерно так:

    public void Example()
    {
        var myCustomer = new Customer() { Name = "Erik";}
        var myImmutableCustomer = new Immutable<Customer>(myCustomer);
        myCustomer.Name = null;
        myCustomer.CreditCardNumbers = null;

        //These guys do not throw exceptions
        Console.WriteLine(myImmutableCustomer.Copy.Name.Length);
        Console.WriteLine("Credit card count: " + myImmutableCustomer.Copy.CreditCardNumbers.Count);
    }

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

1112 Как я уже сказал, это начало - как я бы, наверное, начал - конечно, не оптимальное решение или законченная, отточенная идея. Отсюда я посмотрю, как изменилось мое использование, и соответственно изменил этот подход. Но, по крайней мере, здесь я бы знал, что я мог бы определить, как сделать что-то неизменное, и написать модульные тесты, чтобы убедиться, что это так.

Я понимаю, что это не так уж далеко от простой реализации объектной копии, но она стандартизирует копию с точки зрения неизменности. В кодовой базе вы можете увидеть некоторых разработчиков из ICloneable, некоторых конструкторов копирования и некоторые явные методы копирования, возможно, даже в одном классе. Определив что-то вроде этого, вы узнаете, что намерение определенно связано с неизменяемостью - я хочу сделать снимок, а не дублирующий объект, потому что мне нужно больше и этого объекта. Класс Immtuable<T> также централизует связь между неизменяемостью и копиями; если позже вы захотите как-то оптимизировать, например, кэшировать снимок до «грязного», вам не нужно делать это во всех разработчиках логики копирования.