Como devo lidar com configurações incompatíveis com o padrão Builder?

Isso é motivado por esta resposta a uma pergunta separada .

O padrão do construtor é usado para simplificar a inicialização complexa, especialmente com parâmetros de inicialização opcionais). Mas não sei como gerenciar adequadamente configurações mutuamente exclusivas.

Aqui está uma Imageaula. Imagepode ser inicializado de um arquivo ou de um tamanho, mas não ambos . O uso de construtores para impor essa exclusão mútua é óbvio quando a classe é bastante simples:

public class Image
{
    public Image(Size size, Thing stuff, int range)
    {
    // ... initialize empty with size
    }

    public Image(string filename, Thing stuff, int range)
    {
        // ... initialize from file
    }
}

Agora assuma que Imageé realmente configurável o suficiente para que o padrão do construtor seja útil, de repente isso pode ser possível:

Image image = new ImageBuilder()
                  .setStuff(stuff)
                  .setRange(range)
                  .setSize(size)           // <----------  NOT
                  .setFilename(filename)   // <----------  COMPATIBLE
                  .build();

Esses problemas devem ser detectados no tempo de execução e não no tempo de compilação, o que não é a pior coisa. O problema é que a detecção consistente e abrangente desses problemas dentro da ImageBuilderclasse pode se tornar complexa, especialmente em termos de manutenção.

Como devo lidar com configurações incompatíveis no padrão do construtor?

Você tem seu construtor. No entanto, neste ponto, você precisa de algumas interfaces.

Há uma interface FileBuilder que define um subconjunto de métodos (não setSize) e uma interface SizeBuilder que define outro subconjunto de métodos (não setFilename). Você pode desejar que uma interface GenericBuilder estenda o FileBuilder e o SizeBuilder - não é necessário, embora algumas pessoas possam preferir essa abordagem.

O método setSize()retorna um SizeBuilder. O método setFilename()retorna um FileBuilder.

O ImageBuilder tem toda a lógica para ambos setSize()e setFileName(). No entanto, o tipo de retorno para estes especificaria a interface de subconjunto apropriada.

class ImageBulder implements FileBuilder, SizeBuilder {
    ImageBuilder() {
        doInitThings;
    }

    ImageBuilder setStuff(Thing) {
        doStuff;
        return this;
    }

    ImageBuilder setRange(int range) {
        rangeStuff;
        return this;
    }

    SizeBuilder setSize(Size size) {
        stuff;
        return this;
    }

    FileBuilder setFilename(String filename) {
        otherStuff;
        return this;
    }

    Image build() {
        return new Image(...);
    }
}

Uma parte especial aqui é que, depois de ter um SizeBuilder, todos os retornos precisam ser SizeBuilders. A interface para ele se parece com:

interface SizeBuilder {
    SizeBuilder setRange(int range);
    SizeBuilder setSize(Size size);
    SizeBuilder setStuff(Thing stuff);
    Image build();
}

interface FileBuilder {
    FileBuilder setRange(int range);
    FileBuilder setFilename(String filename);
    FileBuilder setStuff(Thing stuff);
    Image build();
}

Portanto, depois de chamar um desses métodos, você não pode mais chamar o outro e criar um objeto com um estado inválido.