Muitas vezes ao usufruirmos do uso de um simples método nos deparamos com indesejados efeitos colaterais. Métodos devem ser uma coisa ou outra. E apenas isso. Sem esconder outras variações inesperadas.
Uma prática para escrevermos métodos coesos, que falem ao invés de questionarem, é separar em dois tipos os nossos métodos. Os métodos commands, que modificam o estado de um objeto. E os métodos queries, que devem apenas retornar alguma informações sobre um objeto. Devemos sempre evitar fazer as duas coisas ao mesmo. Oferecer ambas funcionalidades em um único método causa confusão.
Por exemplo, vamos supor que temos uma necessidade de adicionarmos uma comissão a um vendedor, em uma nova funcionalidade do sistema. Olhamos para o nosso software e vemos que existe um método com a seguinte assinatura, na classe Vendedor.
Do ponto de vista de um desenvolvedor, usuário desse método, ficamos confusos com o retorno de um booleano. Na verdade aquele retorno nos diz que foi possível adicionar comissão ao vendedor, pois o vendedor possui direto a ele. Poderíamos pensar em simplesmente renomear esse método para:
Mas continuaríamos tendo um método que faz ambas as coisas. E do ponto de vista de reutilização de código, temos um desperdício. O correto seria dividir esse método em dois outros métodos, um command e uma query, onde o resultado do seu uso nos traria um bloco de código de fácil leitura:
Um caso de efeito colateral ao não utilizar a prática de Command And Query Separation pode ser dado pelo seguinte exemplo:
Nesse caso temos um efeito colateral – totalmente indesejado – ao verificarmos uma permissão de acesso, e termos o acesso liberado imediatamente.
É bastante simples o entendimento e a aplicação do Command and Query Separation. Seu propósito fundamental é evitar efeitos indesejáveis na utilização de métodos, aumentando a confiabilidade do sistema. É também uma grande ajuda no desenvolvimento de código expressivo.
Popularity: 28% [?]
