Talvez isso se deva ao princípio de separação comando-consulta ?
O CQS tende a ser popular na interseção de estilos de programação OO e funcionais, pois cria uma distinção óbvia entre métodos de objeto que têm ou não efeitos colaterais (ou seja, que alteram o objeto). Aplicar o CQS a atribuições de variáveis está levando mais longe do que o normal, mas a mesma ideia se aplica.
Uma pequena ilustração de por CQS é útil: Considere uma linguagem F / OO híbrido hipotética com uma List
classe que tem métodos Sort
, Append
, First
, e Length
. No estilo OO imperativo, pode-se querer escrever uma função como esta:
func foo(x):
var list = new List(4, -2, 3, 1)
list.Append(x)
list.Sort()
# list now holds a sorted, five-element list
var smallest = list.First()
return smallest + list.Length()
Considerando que em um estilo mais funcional, seria mais provável escrever algo assim:
func bar(x):
var list = new List(4, -2, 3, 1)
var smallest = list.Append(x).Sort().First()
# list still holds an unsorted, four-element list
return smallest + list.Length()
Eles parecem estar tentando fazer a mesma coisa, mas obviamente um dos dois está incorreto e, sem saber mais sobre o comportamento dos métodos, não podemos dizer qual deles.
Usando o CQS, entretanto, insistiríamos que se Append
e Sort
alterar a lista, eles devem retornar o tipo de unidade, evitando assim a criação de bugs usando a segunda forma quando não deveríamos. A presença de efeitos colaterais, portanto, também se torna implícita na assinatura do método.