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á.
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á.
Parte I - Introdução
Parte II - Correção
Parte III - Design por contrato
Parte V - A Lei de Demeter
Parte VI - Eficiência
Parte VII - Coesão
Parte VIII - Usabilidade
Parte IX - Relacionamento entre classes
Celso,
ResponderExcluirestava lendo o seu post quando ví a palavra refatoração usada como tradução de refactoring, e isso me deixa muito abalado toda vez que vejo. Tenho notado o uso indiscriminado dessa expressão inclusive em artigos técnicos publicados e gostaria de deixar aqui a minha observação.
Em primeiro lugar, a palavra refatoração veio da matemática e significa reduzir uma expressão a seus fatores primos. E refactoring, veio da proposta de Bill Opdyke, que forjou a expressão em sua tese sobre a refabricação de código fonte, depois de uma conversa sobre fábricas de software com seu orientador Ralph Johnson. (Referência: Etymology of Refactoring).
Não sei quem inventou de fazer essa tradução, mas me parece que na falta de informação ela acabou colando no mercado de TI em geral. Eu mesmo já fiz, ainda que sem intenção, algumas expressões que "colaram" no mercado. Mas essa aí me doi toda vez que leio, pois na minha opinião a refabricação de código não passa nem perto da lei de fatoração da matemática.
Bem oportuno o seu comentário.
ResponderExcluirEu acredito que o uso da palavra refatoração esteja intimamente relacionado com o uso de fatoração na matemática.
Minha opinião: Na matemática, você quebra um número grande em número menores: fatorar. No desenvolvimento, você quebra um método grande em métodos menores.
Essa é apenas uma das técnicas na refatoração, mas, acredito eu, por falta de termos melhores, virou uma convenção o uso deste.