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

У мене є алгоритм, який створює колекцію об'єктів. Ці об'єкти підлягають зміні під час створення, оскільки вони починаються дуже мало, але потім вони заповнюються даними в різних місцях алгоритму.

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

Чи вважається в цих сценаріях хорошою практикою наявність двох версій класу, як описано нижче?

• Тоді змінюється створюється алгоритмом
• Після завершення роботи алгоритму дані копіюються в незмінні об'єкти, які повертаються.

Можливо, ви можете використовувати шаблон для побудови . Він використовує окремий об’єкт "builder" з метою збору необхідних даних, і коли всі дані збираються, він створює власне об'єкт. Створений об’єкт може бути незмінним.

Простим способом досягти цього було б мати інтерфейс, який дозволяє читати властивості та викликати лише методи читання лише та клас, який реалізує цей інтерфейс, який також дозволяє писати цей клас.

Ваш метод, який його створює, має справу з першим, а потім повертає останній, забезпечуючи взаємодію лише з читанням. Це не потребує копіювання, і це дозволяє легко налаштувати поведінку, яку ви хочете отримати для абонента, на відміну від автора.

Візьмемо цей приклад:

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, або подумати, чому ж насправді ці об'єкти повинні бути зміненими під час створення?

Іншими словами, чому процес їх створення повинен поширюватися в часі, на відміну від передачі всіх необхідних значень конструктору та створення екземплярів за один раз?

Тому що Builder може бути хорошим рішенням для неправильної проблеми.

Якщо проблема полягає в тому, що ви закінчите з конструктором, який має приблизно 10 параметрів, і ви хочете пом'якшити його, будуючи об'єкт потроху, це може означати, що дизайн зіпсований, і ці 10 значень повинні бути " мішок "/ згрупований у кілька об'єктів ... або основний об'єкт розділений на кілька менших ...

У такому випадку - дотримуйтесь незмінності до кінця, просто вдосконалюйте дизайн.