Classe com membros mutáveis ​​durante a criação, mas imutáveis ​​posteriormente

Eu tenho um algoritmo que cria uma coleção de objetos. Esses objetos são mutáveis ​​durante a criação, pois começam com muito pouco, mas são preenchidos com dados em locais diferentes dentro do algoritmo.

Após a conclusão do algoritmo, os objetos nunca devem ser alterados - no entanto, são consumidos por outras partes do software.

Nesses cenários, é considerado uma boa prática ter duas versões da classe, conforme descrito abaixo?

• O mutável é criado pelo algoritmo, então
• Após a conclusão do algoritmo, os dados são copiados em objetos imutáveis ​​que são retornados.

Talvez você possa usar o padrão do construtor . Ele usa um objeto 'construtor' separado com o objetivo de coletar os dados necessários e, quando todos os dados são coletados, ele cria o objeto real. O objeto criado pode ser imutável.

Uma maneira simples de conseguir isso seria ter uma interface que permita ler propriedades e chamar apenas métodos somente leitura e uma classe que implemente essa interface, que também permite que você escreva essa classe.

Seu método que o cria, lida com o primeiro e, em seguida, retorna o último, fornecendo apenas uma interface somente leitura para interagir. Isso não requer cópia e permite que você ajuste facilmente os comportamentos que deseja que estejam disponíveis para o chamador, em vez do criador.

Veja este exemplo:

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;
    }
}

A única desvantagem dessa abordagem é que alguém poderia simplesmente convertê-la na classe de implementação. Se fosse uma questão de segurança, simplesmente usar essa abordagem é insuficiente. Uma solução alternativa para isso é que você pode criar uma classe de fachada para agrupar a classe mutável, que simplesmente apresenta uma interface com a qual o chamador trabalha e não pode ter acesso ao objeto interno.

Dessa forma, nem mesmo o elenco o ajudará. Ambos podem derivar da mesma interface somente leitura, mas converter o objeto retornado fornecerá apenas a classe Facade, que é imutável, pois não altera o estado subjacente da classe mutável empacotada.

Vale ressaltar que isso não segue a tendência típica na qual um objeto imutável é construído de uma vez por todas através de seu construtor. Compreensivelmente, você pode estar tendo que lidar com muitos parâmetros, mas deve se perguntar se todos esses parâmetros precisam ser definidos antecipadamente ou se alguns podem ser introduzidos posteriormente. Nesse caso, um construtor simples com apenas os parâmetros necessários deve ser usado. Em outras palavras, não use esse padrão se estiver encobrindo outro problema no seu programa.

Você pode usar o padrão Builder como o @JacquesB diz, ou alternativamente pensar por que é que esses objetos precisam ser mutáveis ​​durante a criação?

Em outras palavras, por que o processo de criá-los precisa se espalhar no tempo, em vez de passar todos os valores necessários para o construtor e criar instâncias de uma só vez?

Porque o Builder pode ser uma boa solução para o problema errado.

Se o problema é que você acaba com um construtor com 10 parâmetros e deseja mitigá-lo construindo o objeto pouco a pouco, isso pode indicar que o design está estragado e esses 10 valores devem ser " agrupado "/ agrupado em alguns objetos ... ou o objeto principal dividido em alguns objetos menores ...

Nesse caso, mantenha a imutabilidade até o fim, apenas melhore o design.