Bloqueadores de Mudança, Dispensáveis & Acopladores - Maus Cheiros de Código - Parte III

Olá sejam bem-vindos ao canal engenharia de software com ênfase uml eu sou o professor Janes getes e eu já atuo na área de modelagem de software há vários anos eu tenho quatro livros publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos sobre modelagem de software utilizando linguagem uml na aula de hoje eu vou concluir o tema sobre maus cheiros de código maus cheiros de código são características do software que identificam más práticas de programação programação pobre programação mais estruturada eh codificação mal feita que pode levar a dificuldades de manutenção ou ao

surgimento de erros futuros então na aula de hoje nós vamos falar sobre bloqueadores de mudanças dispensáveis e acopladores que são as três as três características as três categorias restantes do os ma cheiros de código então vamos iniciar a nossa aula bom como eu falei essa vai ser a terceira e última aula sobre ma cheiros de código e eu vou abordar as categorias bloqueadores de mudanças dispensáveis e acopladores esse é um tema dentro do da área maior de verificação e validação de software que são esse tipo de problema esse tipo de má prática é o uma

das características que são buscadas por técnicas de inspeção de código se busca identificar para posterior ã remoção Então vamos começar falando sobre os bloqueadores de mudança ou em seu termo em inglês os Change prevent na verdade a tradução literal seria impedidores de mudança mas bloqueadores de mudança é é um termo mais H correto Na minha opinião então essa categoria de ma cheiros ela identifica situações em Que mudanças no código se tornam muito difíceis ou arriscadas porque a estrutura escolhida ou a organização adotada na codificação foi mal mal escolhida mal estruturada mal desenvolvida mal feita e

assim quando se quer fazer qualquer alteração ou mudança Qualquer mudança num num trecho de código provavelmente vai implicar que outros trechos precisam ser alterados também isso torna muito mais complexa e cara a manutenção e evolução do código é importante lembrar que manutenção e evolução de código é uma realidade a o software Muito provavelmente sofrerá manutenções sofrerá evoluções por mais bem feito que ele tenha sido por melhor que a engenharia de requisito tenha sido feita por melhor projetado que o software tenha sido por mais bem codificado que ele tenha sido por mais bem testado que o

software tenha sido ele muito provavelmente sofrerá manutenções e evoluções por quê Porque o os softwares eles eh são voltados para ã ambientes dinâmicos que sofrem constantes mudanças e Como as empresas precisam eh se apoiar em software no momento que elas querem ser competitivas e conseguir continuar atuantes no mercado elas precisam que o software acompanhe essas esse dinamismo essa essas mudanças então o software irá sofrer manutenção o software provavelmente terá muitas versões então ele irá sofrer evoluções se um software não sofre manutenção não sofre evoluções é provável que ele esteja sendo muito pouco utilizado então a

manutenção é uma realidade muitas vezes ela corresponde a uma parcela substancial do valor total de desenvolvimento de um software então estruturar o código de tal forma que ele seja fácil de manter é uma alternativa uma estratégia muito recomendada no momento em que se prevê que ele sofrerá mudanças bom então esse tipo de ma cheiros pode caracterizar um um problema grave no momento que se queira evoluir ou modificar o software ã Então para que eu consiga manter ou evoluir no software é necessário que o software ele seja flexível o código no caso ou seja flexível e

capaz de ser adaptado facilmente então o os mau cheiros da categoria de bloqueadores de mudança eles são o oposto disso eles são o extremo oposto desse ideal eles prejudicam muito a manutenção e evolução do software Ah e na verdade no momento que um software ele é difícil de manter isso é uma das principais características que fazem com que o software ele se torne obsoleto no momento que um software ele é difícil de manter a possibilidade que ele venha a ser descartado é muito alta bom então a falar sobre características dos bloqueadores de mudanças ã nas

situações em que esse tipo de macheiro ocorre o código ele costuma ser tão rígido que quaisquer pequen pequenas alterações exige modificações em vários trechos do software isso acontece por exemplo quando uma classe tem muitas responsabilidades quando ela viola o princípio da responsabilidade única ou quando a forte acoplamento entre os componentes existe muita dependência entre os componentes ah exemplos comuns classes com muitas responsabilidades uma classe ela pode ter que por exemplo uma classe pode ter que gerenciar tanto a lógica de negócios quanto a lógica de apresentação então H isso normalmente é uma característica de um bloqueador

de mudança ã porque se eu tiver que fazer alguma alteração em um trecho de código isso provavelmente vai exigir que eu faça alterações em outros trechos Além disso isso também caracteriza uma arquitetura mal estruturada por exemplo não foi aplicada uma arquitetura mvc por exemplo ou outra arquitetura equivalente que pudesse isolar a lógica de negócios da lógica de apresentação então isso também caracteriza uma programação pobre ã um outro exemplo de bloqueadores de mudança que também se se insere em outras categorias de ma cheiros é o código duplicado códigos duplicados são uma péssima escolha uma péssima abordagem

então então no momento que eu tenho instruções conjuntos de instruções que se repetem que foram implementadas em vários lugares do meu código isso prejudica muito a manutenção consistente do meu código por quê Porque sempre que eu tiver que fazer uma alteração nesse trecho específico eu vou ter que procurar por todas as ocorrências desse trecho e alterar uma por uma e se eu esquecer de alterar uma delas Ah o meu código fica inconsistente Então isso é uma dificuldade uma é um é um prejudicial para manutenção além do que deixa o meu código maior e mais difícil

de entender ah então vou começar a falar sobre alguns exemplos de bloqueadores de mudança alguns tipos de eh ma cheiros que são inseridos são H colocados dentro da categoria de bloqueadores de mudança um deles é o ma cheiro de mudança divergente ou divergent Change eh ele ocorre em situações em que eh uma única classe quando for precisar ser alterada ela pode ser alterada Por muitas razões diferentes então muitas vezes Ah quando for for necessário fazer manutenção nessa classe é é preciso fazer diversas mudanças naquela mesma classe Ah isso provavelmente destaca identifica indica que a classe

em questão ela está Ela ela está cobrindo ela está suportando muitas responsabilidades diferentes o que viola o princípio da responsabilidade única bom então razões para o problema então isso ocorre muitas vezes devido à programação copiada ou a estrutura de programação própr incluindo a Possivelmente uma arquitetura mal Projetada mal codificada ou mesmo a uma arquitetura de software inadequada para o problema ah às vezes isso pode ter sido uma escolha de arquitetura pode ter sido escolhido uma arquitetura difícil de manter para satisfazer um requisito não funcional de desempenho em detrimento do requisito não funcional de manutenibilidade pode

ser uma possibilidade e como se trata esse mau cheiro bom podemos tratar por meio de refatoração então classes com múltiplas de responsabilidades elas devem ser divididas em várias classes cada uma delas com responsabilidades únicas então eu vou estar obedecendo ao princípio da responsabilidade única o single responsability eh principal h eu também tenho que buscar por código duplicado e eliminar essas duplicações Ou pelo menos reduzir elas ao máximo possível eu devo tentar por exemplo concentrar a lógica comum em uma superclasse eh assim eu vou reduzir o risco de possíveis inconsistências durante as manutenções Ah uma outra

forma de tratar esse problema é por meio da aplicação de padrões projeto Como por exemplo o strategy o decorator ou o observer que eles ajudam a desacoplar comportamentos isso permite ah alterar partes do software sem que será necessário afetar ou alterar outras partes então isso evita efeitos colaterais de manutenção também ou seja que ah ao dar uma manutenção outra parte do software que estáa funcionando passa a apresentar erros e existe o terceiro tratamento que é mais radical tá que deve ser evitado mas em último caso às vezes é necessário que é a escolha de arquiteturas

mais flexíveis a manutenções ou evoluções Então seria substituir a arquitetura do código só que isso é muito caro e bastante trabalhoso bastante difícil porque muito do código vai ter que ser reescrito Ah então Então essa é uma alternativa que só pode ser escolhida em último caso ah na verdade a escolha da arquitetura ela precisa ser feita de maneira muito séria Muito criteriosa Antes da codificação ser ã ser iniciada isso é isso deve ser feito durante a fase de projeto arquitetural antes de se codificar qualquer coisa porque a mudança na arquitetura pode causar grandes prejuízos no

projeto porque eu preciso reestruturar muito do meu código bom vamos continuar Ah e qual é a recompensa por eh corrigir esse ma cheiro a a organização do código melhora a duplicação de código ela é eliminada a manutenção e evolução se tornam mais fácil mais fáceis e há o menor risco de manutenções causar efeitos colaterais ou seja como eu falei anteriormente quando eu faço uma manutenção num módulo num componente numa classe outros módulos componentes ou classes deixam de funcionar e e isso é possível esse e evitar esse tipo de efeito colateral é possível após a correção

desse mau cheiro porque passa a haver menos dependências entre os componentes do softw Ah vou falar um pouquinho sobre um outro ma cheiro de código que é o chamado cirurg da espingarda ou Shotgun surgery Ah ela ocorre em situações que quando é necessário fazer uma pequena mudança em um requisito isso vai acarretar muitas mudanças em vários outros locais do código Então sempre que eu precisar fazer alguma manutenção eu vou precisar fazer pequenas mudanças em várias classes diferentes ou em vários trechos do código diferentes e novamente esse tipo de macheiro ele torna a a manutenção complexa

e também propensa a erros e a efeitos colaterais razões então uma única responsabilidade ela foi dividida entre um grande número de classes Qual é o tratamento eu devo pegar essa responsabilidade e mover esse comportamento transferindo métodos para uma classe única Possivelmente unindo mais de um método e se não houver uma classe adequada para isso então é necessário criar uma classe nova ah vejam bem o princípio da responsabilidade única não vai ser sacrificado aqui porque se trata de uma única responsabilidade dividida Entre várias classes o que não deveria ter acontecido Qual a recompensa melhora a organização

do código menor duplicação de código maior facilidade de manutenção vamos falar sobre um outro bloqueador de mudança é o bloqueador e hierarquias paralelas de herança ou paralel inheritance hierarchies então ã esse esse ma cheiro ele se caracteriza por eh cenários situações em que quando se faz uma alteração em uma classe é necessário h fazer alterações em uma hierarquia de classe paralela Ah isso resulta em código altamente acoplado e às vezes duplicado Quais são os sinais e sintomas para desse mau cheiro sempre que se cria uma subclasse para uma classe eu preciso criar outra subclasse correspondente

em outra hierarquia relacionada razões para problema ah quando a hierarquia de classes permanecia pequena não ela não causava esse problema não era grave não não não eram causados graves problemas era possível conviver com isso mas à medida que novas classes elas vão sendo adicionadas a interdependência ent e entre as hierarquias ã faz com que as alterações sejam cada vez mais difíceis de e complexas mais difíceis de gerenciar e cada vez mais complexas de realizar ã Qual é o tratamento quando existem duas hierarquias de herança paralelas e elas possuem ah funcionalidades ou atributos semelhantes então deve-se

integrar essas funcionalidades de tal forma que não seja necessário manter duas hierarquias separadas por exemplo pode se mover a lógica comum de dessas hierarquias para uma hierarquia ou classe centralizada então o Ah vai se eliminar a necessidade de duas hierarquias separadas Qual a recompensa se reduz a duplicação de código se melhora a organização do código e se produz um código mais coeso e fácil de manter e evoluir vamos falar sobre dispensáveis dispensáveis São trechos de código classes métodos algoritmos rotinas que e até mesmo comentários que na verdade eles são desnecessários não acrescentam mais nada nesse

momento são inúteis e se forem retirados isso irá tornar o código mais limpo mais fácil de compreender mais eficiente vamos falar um pouquinho sobre os dispensáveis então nós temos o macheiro de comentários excessivos comentários são importantes quando eles ajudam a o funcionamento de um método de uma classe embora há quem diga que se o método precisa ser explicado isso possa ser também o mau cheiro eu acho isso um pouco de exagero mas eu considero que comentários são são úteis Desde que não sejam feitos de um em excesso de uma quantidade excessiva então quando o método

uma classe ela contém muitos comentários explicativos ah em muitas situações esses comentários eles são desnecessários ou são exagerados ou até mesmo eles são contraproducentes uma vez que o programador ele tem que perder muito tempo tentando entender os comentários na verdade eles dão mais trabalho do que ajudariam então nessas situações esses comentários eles precisam ser eliminados Ou pelo menos resumidos Então se mantém apenas o que realmente agrega compreensão ao código somente os comentários úteis um outro dispensável que na verdade como vocês já viram nessa em outras aulas pode ser também pode se inserir também em outras

categorias de de mau cheiro é quando há código duplicado ou código muito semelhante então quando dois ou mais trechos de código eles estão duplicados ou eles são muito semelhantes então é recomendável que se una esses trechos repetidos ou muito semelhantes em uma única ocorrência e um método por exemplo e que se faça referência a esse método a essa ocorrência sempre que for necessário isso vai reduzir a duplicação e Vai facilitar a manutenção do código Ah um outro dispensável é a classe preguiçosa é uma classe que faz muito pouco ou quase nada que ela tem muitos

Pou muitas poucas responsabilidades qual é o problema desse Mairo Bom primeiramente quando se precisa compreender e alterar uma classe isso irá consumir tempo e recursos vai exigir um esforço do programador então cada classe ela precisa ter uma responsabilidade Clara e significativa de forma a justificar a sua existência se a classe em questão ela tem uma responsabilidade muito limitada ela é redundante existem outras classes que fazem algo semelhante ou ela poderia ser incorporada de maneira fácil a outra classe sem prejuízo a coesão Então essa classe ela precisa ser removida isso irá reduzir o custo de compreensão

do do código e Por conseguinte de sua manutenção e não irá comprometer o princípio da responsabilidade única ã nós temos também o dispensável chamado código morto que como o nome já diz se refere a variáveis atributos parâmetros Campos métodos classes que não estão mais sendo utilizados deixaram de ser justificados simplesmente não estão sendo mais usados ah e não tem mais função no sistema então eles devem ser eliminados devem ser removidos um outro dispens é a generalidade especulativa que ocorre quando o desenvolvedor resolve fazer trabalho extra que ele acredita que vai ser útil no futuro mas

que muitas vezes não não é na verdade ele viola o princípio Y agne que basicamente é abreviatura de you are not to need it eh você não irá precisar disso então um princípio ágil diz que só deve-se desenvolver o estritamente necessário no momento existe até uma recomendação que se deve evoluir a arte de não executar trabalho então com princípio ágil só se desenvolve o que é realmente necessário para o momento se for necessário no futuro se fazem mudanças se desenvolve algo mais não se desenvolve nada além do necessário no momento então generalidades especulativas eh devem

ser removidas para que o código permaneça simples enxuto fácil de entender Ah e nós temos as classes de dados que é um erro que ocorre muito frequentemente muita gente eh aplica classe de dados eh por exemplo na arquitetura mvc de forma errada Essas são as chamadas classes anêmicas basicamente é elas são classes que contém apenas atributos e os métodos para acessá-los ou seja basicamente ela vai se conter somente getters e sets e nada da lógica do software Então essas classes elas são apenas contêiners de dados que vão ser utilizados por outras classes e não possuem

qualquer outra funcionalidade e não podem não são não são capazes nem mesmo de operar eh de maneira independente sobre se os próprios dados sobre seus próprios atributos Então esse tipo de classe Ela é conhecida como classe anêmica Ahã porque é uma classe muito fraca ela carece de coesão ela indica muitas vezes que a lógica de negócio ela está dispersa entre outros trechos do software em outras classes e em muitos casos é muito recomendável que essa classe seja incorporada em classes que também contenham lógica a lógica relevante a lógica necessária para manipular esses dados manipular esses

atributos isso irá aumentar a coesão e vai promover o encapsulamento Ah agora nós vamos falar sobre a última categoria que é de acopladores ou coers Ah esse tipo de ma cheiro os ma cheiros dessa categoria ele se iam por haver um acoplamento excessivo entre as classes isso torna o software rígido e difícil de manter elas também eh indicam situações em que o o acoplamento ele foi substituído por delegações de forma excessiva isso cria dependências indiretas que aumentam a complexidade e dificultam a manutenção Ah então esse tipo de mau cheiro ele prejudica a modularidade e dificulta

a reutilização e a interdependência entre classes então vocês vão perceber que a maioria desses mairos Inclusive das outras aulas eles estão muito voltados para a questão de manutenção para vocês perceberem a importância que a manutenção tem para a engenharia de software para AOL para permitir ah a facilidade de evoluir o software porque isso como eu falei é uma realidade que Muito provavelmente ocorrerá comos softwares Ah que vocês desenvolverem então é importante estruturar o software de maneira que ele seja fácil de manter e evitar esse tipo de má prática de programação bom então vamos falar sobre

alguns tipos de acopladores então nós temos o mau cheiro inveja de recurso ou feature Envy Ah ele ocorre quando um método ele demonstra inveja dos recursos de outro isso ocorre quando ele acessa dados de outros objetos mais do que os dados da sua própria classe isso muitas vezes pode indicar que o método em questão Na verdade ele Deva pertencer a outra classe um outro acoplador é o de intimidade inapropriada ele ocorre quando uma classe ela acessa diretamente métodos ou Campos internos de outra classe O que é um erro grave isso infringe o princípio de encapsulamento

Ah então esse tipo de acoplamento excessivo ele torna o código menos modular e muito mais difícil de manter e nós temos também o acoplador chamado cadeias de mensagens que ele ocorre quando um objeto ele faz uma série de chamadas encade em uma sequência de outros objetos por exemplo a p getb p get c p getd nessa situação o objeto a ele vai chamar o método get B para acessar B que irá chamar o método get C para acessar C que por sua vez irá chamar o método get D para acessar d e assim sucessivamente então

isso cria um acoplamento excessivo por quê Porque a precisa conhecer a estrutura interna de B de c e de D isso irá dificultar a manutenção e a compreensão do código e nós temos ainda um outro Ah acoplador que é o homem no meio Man Middle ah middleman na verdade esse problema ele ocorre quando uma classe ela serve somente como intermediária ela tem pouca ou ou nada ou nenhuma responsabilidade praticamente todas as responsabilidades elas são delegadas para outra classe então no momento que essa classe intermediária ela realiza pouca ou nenhuma ã nenhum comportamento próprio Então ela

se torna ou se e se torna redundante então isso caracteriza que ela precisa ser ah excluída ela precisa ser removida Ah e é isso nós concluímos esta aula sobre maus cheiros de código essa última aula sobre maus cheiros de código eu espero que vocês tenham gostar dessa aula Espero que ela tenha sido útil se vocês gostaram dessa aula eu peço que vocês curtam o vídeo compartilhe com quem possa ter interesse e nós nos vemos nas próximas aulas obrigado pela atenção