Por que o encadeamento de setters não é convencional?

Ter o encadeamento implementado nos beans é muito útil: não é necessário sobrecarregar construtores, mega construtores, fábricas e oferece maior legibilidade. Não consigo pensar em nenhuma desvantagem, a menos que você queira que seu objeto seja imutável ; nesse caso, não haveria nenhum levantador de qualquer maneira. Então, existe uma razão para que essa não seja uma convenção OOP?

public class DTO {

    private String foo;
    private String bar;

    public String getFoo() {
         return foo;
    }

    public String getBar() {
        return bar;
    }

    public DTO setFoo(String foo) {
        this.foo = foo;
        return this;
    }

    public DTO setBar(String bar) {
        this.bar = bar;
        return this;
    }

}

//...//

DTO dto = new DTO().setFoo("foo").setBar("bar");

Então, existe uma razão pela qual essa convenção não é uma OOP?

Meu melhor palpite: porque viola o CQS

Você tem um comando (alterando o estado do objeto) e uma consulta (retornando uma cópia do estado - nesse caso, o próprio objeto) misturados no mesmo método. Isso não é necessariamente um problema, mas viola algumas das diretrizes básicas.

Por exemplo, em C ++, std :: stack :: pop () é um comando que retorna nulo, e std :: stack :: top () é uma consulta que retorna uma referência ao elemento top na pilha. Classicamente, você gostaria de combinar os dois, mas não pode fazer isso e ter uma exceção segura. (Não é um problema em Java, porque o operador de atribuição em Java não lança).

Se o DTO fosse um tipo de valor, você poderia obter um final semelhante com

public DTO setFoo(String foo) {
    return new DTO(foo, this.bar);
}

public DTO setBar(String bar) {
    return new DTO(this.foo, bar);
}

Além disso, os valores de retorno do encadeamento são uma dor colossal quando você está lidando com herança. Consulte o "Padrão de modelo curiosamente recorrente"

Finalmente, há o problema de que o construtor padrão deve deixá-lo com um objeto que esteja em um estado válido. Se você precisar executar vários comandos para restaurar o objeto para um estado válido, algo deu muito errado.

1. Salvar algumas teclas não é convincente. Pode ser bom, mas as convenções de OOP se preocupam mais com conceitos e estruturas, não com pressionamentos de teclas.

2. O valor de retorno não tem sentido.

3. Mais do que não ter sentido, o valor de retorno é enganador, pois os usuários podem esperar que o valor de retorno tenha significado. Eles podem esperar que seja um "levantador imutável"

   public FooHolder {
       public FooHolder withFoo(int foo) {
           /* return a modified COPY of this FooHolder instance */
       }
   }

   Na realidade, o seu setter muda o objeto.

4. Não funciona bem com herança.

   public FooHolder {
       public FooHolder setFoo(int foo) {
           ...
       }
   }

   public BarHolder extends FooHolder {
       public FooHolder setBar(int bar) {
           ...
       }
   } 

   eu consigo escrever

   new BarHolder().setBar(2).setFoo(1)

   mas não

   new BarHolder().setFoo(1).setBar(2)

Para mim, os números 1 a 3 são os mais importantes. Código bem escrito não é sobre texto agradavelmente organizado. Um código bem escrito trata dos conceitos, relacionamentos e estrutura fundamentais. O texto é apenas um reflexo externo do verdadeiro significado do código.

Eu não acho que essa seja uma convenção OOP, está mais relacionada ao design da linguagem e suas convenções.

Parece que você gosta de usar Java. Java possui uma especificação JavaBeans que especifica o tipo de retorno do configurador a ser anulado, ou seja, está em conflito com o encadeamento de configuradores. Esta especificação é amplamente aceita e implementada em uma variedade de ferramentas.

Claro que você pode perguntar, por que não está encadeando parte da especificação. Não sei a resposta, talvez esse padrão não fosse conhecido / popular na época.

Como outras pessoas disseram, isso geralmente é chamado de interface fluente .

Normalmente, os setters são variáveis ​​de passagem de chamadas em resposta ao código lógico em um aplicativo; sua classe de DTO é um exemplo disso. O código convencional quando os setters não retornam nada é o melhor para isso. Outras respostas explicaram o caminho.

No entanto, existem alguns casos em que a interface fluente pode ser uma boa solução, estes têm em comum.

• As constantes são principalmente passadas para os levantadores
• A lógica do programa não altera o que é passado para os setters.

Definindo a configuração, por exemplo, fluent-nhibernate

Id(x => x.Id);
Map(x => x.Name)
   .Length(16)
   .Not.Nullable();
HasMany(x => x.Staff)
   .Inverse()
   .Cascade.All();
HasManyToMany(x => x.Products)
   .Cascade.All()
   .Table("StoreProduct");

Configurando dados de teste em testes de unidade, usando TestDataBulderClasses especial (mães de objeto)

members = MemberBuilder.CreateList(4)
    .TheFirst(1).With(b => b.WithFirstName("Rob"))
    .TheNext(2).With(b => b.WithFirstName("Poya"))
    .TheNext(1).With(b => b.WithFirstName("Matt"))
    .BuildList(); // Note the "build" method sets everything else to
                  // senible default values so a test only need to define 
                  // what it care about, even if for example a member 
                  // MUST have MembershipId  set

No entanto, a criação de uma interface fluente boa é muito difícil , por isso só vale a pena quando você tem muita configuração "estática". Também a interface fluente não deve ser misturada às classes "normais"; portanto, o padrão do construtor é frequentemente usado.

Eu acho que muito do motivo de não ser uma convenção encadear um setter após o outro é porque, nesses casos, é mais comum ver um objeto de opções ou parâmetros em um construtor. O C # também possui uma sintaxe de inicializador.

Ao invés de:

DTO dto = new DTO().setFoo("foo").setBar("bar");

Alguém pode escrever:

(em JS)

var dto = new DTO({foo: "foo", bar: "bar"});

(em c #)

DTO dto = new DTO{Foo = "foo", Bar = "bar"};

(em Java)

DTO dto = new DTO("foo", "bar");

setFooe não setBarsão mais necessários para a inicialização e podem ser usados ​​para mutação posteriormente.

Embora a capacidade de encadeamento seja útil em algumas circunstâncias, é importante não tentar colocar tudo em uma única linha apenas para reduzir os caracteres de nova linha.

Por exemplo

dto.setFoo("foo").setBar("fizz").setFizz("bar").setBuzz("buzz");

torna mais difícil ler e entender o que está acontecendo. Reformatação para:

dto.setFoo("foo")
    .setBar("fizz")
    .setFizz("bar")
    .setBuzz("buzz");

É muito mais fácil de entender e torna o "erro" na primeira versão mais óbvio. Depois de refatorar o código para esse formato, não há vantagem real sobre:

dto.setFoo("foo");
dto.setBar("bar");
dto.setFizz("fizz");
dto.setBuzz("buzz");

Essa técnica é realmente usada no padrão Builder.

x = ObjectBuilder()
        .foo(5)
        .bar(6);

No entanto, em geral, é evitado porque é ambíguo. Não é óbvio se o valor de retorno é o objeto (para que você possa chamar outros setters) ou se o objeto de retorno é o valor que acabou de ser atribuído (também um padrão comum). Assim, o Princípio da menor surpresa sugere que você não deve tentar assumir que o usuário deseja ver uma solução ou outra, a menos que seja fundamental para o design do objeto.

Isso é mais um comentário do que uma resposta, mas não posso comentar, então ...

só queria mencionar que essa pergunta me surpreendeu porque não vejo isso de maneira incomum . Na verdade, no meu ambiente de trabalho (desenvolvedor web) é muito, muito comum.

Por exemplo, é assim que o comando doutrina: generate: entity do Symfony gera automaticamente tudo setters , por padrão .

O jQuery meio que encadeia a maioria de seus métodos de uma maneira muito semelhante.