O desacoplamento pode prejudicar a manutenção em certas situações?

5

O fato de a lógica de negócios ser mapeada para interfaces em vez de implementações na verdade impede a manutenção do aplicativo em determinadas situações?

Um exemplo ingênuo com a estrutura do Hibernate do Java seria, por exemplo (desde que eu não tenha toda a base de código na minha cabeça, a estrutura do projeto seja uma bagunça e as classes sejam nomeadas com nomes arbitrários) se eu desejar para ver o que está acontecendo em um determinado DAO, para ver se ele está realmente fazendo o que deve fazer, em vez de percorrer a árvore a partir do ponto em que o serviço de dados é invocado (onde a árvore terminará em uma interface com nenhum detalhe de implementação além da assinatura) Eu tenho que, por exemplo, ir e procurar por um arquivo XML de configuração para ver qual classe é mapeada para a referida interface como a implementação antes de poder acessar os detalhes reais da implementação.

Há alguma situação em que ter um acoplamento fraco possa realmente prejudicar a manutenção?

    
por Ceiling Gecko 09.06.2014 / 14:06
fonte

2 respostas

2

Trade offs são inerentes ao design de software. A diminuição do acoplamento quase sempre torna mais difícil encontrar a implementação concreta da qual seu código depende. Aceitamos esse custo porque torna mais fácil alterar essa implementação e testá-lo de forma isolada, o que minimiza os tempos em que precisamos encontrar a implementação concreta e minimiza os efeitos em cascata de quaisquer alterações que fizermos a ela. Não se engane. Só porque um custo vale a pena pagar não significa que não esteja lá.

    
por 09.06.2014 / 17:16
fonte
1

O desenvolvimento de código para uma interface é, tanto quanto eu sei recomendado, pois permite que você faça alterações sem precisar reescrever e / ou refatorar seu código.

Dito isto, acredito que ter um acoplamento fraco pode até certo ponto ferir a manutenção. O principal problema que vejo é que as pessoas podem perder o controle sobre o que estão fazendo nos métodos anteriores, o que pode causar dores de cabeça ao depurar problemas. Um exemplo excessivamente simplificado seria:

public class Login
{
     public void verifyLogin(...)
     {
         if(VerifyUtlis.isUserValid(...))
         {
             //redirect to home 
         }
         //redirect to somewhere else
     }
}

public class FTPHandler
{
     public void verifyLogin(...)
     {
         if(VerifyUtlis.isUserValid(...))
         {
             //redirect to home 
         }
         //redirect to somewhere else
     }
}

public class VerifyUtils
{
     public boolean isUserValid(...)
     {
         ...
     }
}

Ao depurar código em VerufyUtils um desenvolvedor (talvez alguém que acabou de entrar) pode achar difícil manter o controle de onde ele / ela obteve (admitidamente, o acima é simplificado, mas espero que você entenda como as coisas obter quando você tem 100 classes chamando uns aos outros).

Se o desenvolvedor pode ter dificuldade em rastrear qual método é usado onde, qualquer alteração que ele fizer pode potencialmente tornar o aplicativo instável. Então, se você está indo para uma abordagem de casal, certifique-se que o código que você tem e todas as alterações feitas são documentadas. Não há necessidade de ter milhares de palavras, mas geralmente explicar por que as coisas são como são (em vez de escrever comentários para explicar o que o código está fazendo) ajuda a manter sistemas fracamente acoplados no escopo.

    
por 09.06.2014 / 15:17
fonte