Agora falaremos da flexibilidade. O princípio da flexibilidade diz respeito a como sua aplicação é capaz de se adequar às mudanças solicitadas na aplicação.
Mudanças acontecem a todo momento durante o processo de software. Sua aplicação deve estar preparada para isso. A ausência deste princípio gera, naturalmente, um receio por mudanças. É a ausência desse princípio que produz as tão famosas reclamações da equipe com relação ao cliente.
Basicamente, existem dois tipos de Change Requests: o que é ocasionado pela
deficiência no levantamento de requistos e o que é ocasionado por mudanças no negócio do cliente.
Como fazer com que essas alterações não transformem nossas vidas em um inferno?
Um desenvolvedor preocupado com as boas práticas produzirá códigos mais flexíveis. Usaremos, para exemplificarmos, o
primeiro exemplo de qualidade na prática.
Cenário: o cliente nos informa que, a partir de agora, para solicitação de compras de produto de um pedido, primeiramente, será preciso verificar se o mesmo está confirmado.
Solução com o código primitivo: Descobrir qual valor corresponde ao status confirmado. Verificar se o status do pedido é igual ao valor de confirmado.
Solução com o código refatorado: Perguntar se o status é confirmado, através do método estahConfirmado(short status).
É válido notar que, numa solução OO, o método
estahConfirmado(), é uma operação (comportamento) de um objeto de uma classe, Pedido por exemplo. Dessa forma, sempre que precisássemos confirmar se o status de um pedido está em conformidade com a operação que desejamos realizar, pergutamos para quem sabe, isto é, para o objeto.
Onde a flexibilidade do código refatorado? Bem, logo de cara, percebemos que não precisamos duplicar código para verificar o status. Dessa forma, estaremos reusando um código que já foi testado diversas vezes. O analista de negócios solicitou uma alteração e a fizemos somente realizando mais uma chamada a um método já existente.
Outro exemplo interessante, surgiu
nessa thread do
GUJ:
Cenário: O desenvolvedor precisa de uma pilha limitada.
A primeira solução que forneci é, na verdade, uma gambiarra. Na segunda, aproveitei a
flexibilidade do Java para fornecer uma solução mais elegante.
Outro exemplo clássico que prova a flexibilidade do código refatorado é a mudança da lógica de negócios para o status confirmado. Nenhum cliente do objeto da classe Pedido precisa saber que o chato do cliente mudou a lógica. Faremos a alteração na classe Pedido e nenhuma outra alteração será necessária. Essa flexibilidade é um dos motivos para o Shoes e Fowler serem contras a
separação de dados e comportamento em VO e BO, produzindo um
modelo anêmico.
Outras formas de conseguir flexibilidade é eliminando dependências desnecessárias e melhorando a legibilidade. Por consistirem em assuntos vastos, falaremos mais adiante.
A flexibilidade é subjetiva, difícil de perceber. Normalmente, só a percebemos quando precisamos. Portanto poderíamos escrever milhares de linhas e ainda não cobriríamos todo assunto. Espero que a idéia central tenha sido passada.
No próximo post, falarei da Lei de Deméter. Até lá.
