Класс с членами, которые изменяются во время создания, но неизменны после

У меня есть алгоритм, который создает коллекцию объектов. Эти объекты являются изменяемыми во время создания, так как они начинаются с очень небольшого количества, но затем они заполняются данными в разных местах в алгоритме.

После завершения алгоритма объекты никогда не должны быть изменены - однако они используются другими частями программного обеспечения.

В этих сценариях считается ли хорошей практикой иметь две версии класса, как описано ниже?

• Изменяемый создается алгоритмом, затем
• По завершении алгоритма данные копируются в неизменяемые объекты, которые возвращаются.

Вы можете, возможно, использовать шаблон строителя . Он использует отдельный объект «строитель» с целью сбора необходимых данных, а когда все данные собираются, он создает реальный объект. Созданный объект может быть неизменным.

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

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

Возьмите этот пример:

public interface IPerson 
{
    public String FirstName 
    {
        get;
    }

    public String LastName 
    {
        get;
    }
} 

public class PersonImpl : IPerson 
{
    private String firstName, lastName;

    public String FirstName 
    {
        get { return firstName; }
        set { firstName = value; }
    }

    public String LastName 
    {
        get { return lastName; }
        set { lastName = value; }
    }
}

class Factory 
{
    public IPerson MakePerson() 
    {
        PersonImpl person = new PersonImpl();
        person.FirstName = 'Joe';
        person.LastName = 'Schmoe';
        return person;
    }
}

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

Таким образом, даже кастинг не поможет вам. Оба могут происходить из одного и того же интерфейса только для чтения, но приведение возвращенного объекта даст только класс Facade, который является неизменным, поскольку он не меняет базовое состояние переносимого изменяемого класса.

Стоит отметить, что это не соответствует типичной тенденции, в которой неизменный объект создается раз и навсегда через его конструктор. Понятно, что вам, возможно, придется иметь дело со многими параметрами, но вы должны спросить себя, нужно ли все эти параметры определять заранее или некоторые из них могут быть введены позже. В этом случае следует использовать простой конструктор с только необходимыми параметрами. Другими словами, не используйте этот шаблон, если он скрывает другую проблему в вашей программе.

Вы можете использовать шаблон Builder, как говорит @JacquesB, или в качестве альтернативы подумать, почему на самом деле эти ваши объекты должны быть изменяемыми во время создания?

Другими словами, почему процесс их создания должен распространяться во времени, а не передавать все необходимые значения в конструктор и создавать экземпляры за один раз?

Потому что Строитель может быть хорошим решением для неправильной проблемы.

Если проблема в том, что в итоге вы получите конструктор длиной 10 параметров и хотите уменьшить его, построив объект понемногу, это может указывать на то, что дизайн испорчен, и эти 10 значений должны быть " "упакован в мешок" / сгруппирован в несколько объектов ... или основной объект разделен на несколько более мелких ...

В этом случае - придерживайтесь неизменности, просто улучшайте дизайн.