Il disaccoppiamento può danneggiare la manutenibilità in determinate situazioni?

Question

Il disaccoppiamento può danneggiare la manutenibilità in determinate situazioni?

#1 da (2 voti)
#2 da (1 voti)

5

Il fatto che la logica aziendale sia mappata su interfacce anziché implementazioni ostacola effettivamente il mantenimento dell'applicazione in determinate situazioni?

Un esempio ingenuo con il framework Hibernate di Java sarebbe, ad esempio (ammesso che non abbia l'intero codice base nella mia testa, la struttura del progetto è un casino e le classi sono nominate con nomi arbitrari) se desidero per vedere cosa sta succedendo in un certo DAO, per vedere se effettivamente sta facendo ciò che deve fare, quindi invece di attraversare la struttura verso l'alto dal punto in cui viene richiamato il servizio dati (dove l'albero terminerà in un'interfaccia con nessun dettaglio di implementazione a prescindere dalla firma) Devo, ad esempio, andare a cercare un file XML di configurazione per vedere quale classe è mappata a detta interfaccia come implementazione prima di poter accedere ai dettagli di implementazione reali.

Ci sono situazioni in cui l'accoppiamento libero può effettivamente danneggiare la manutenibilità?

programming-practices java maintainability

posta Ceiling Gecko 09.06.2014 - 14:06

fonte

2 risposte

Leggi altre domande sui tag programming-practices java maintainability

Quale repository NoSQL è più adatto per un'architettura di tipo Twitter? [chiuso] Qualche suggerimento per l'installazione / smontaggio dei test di automazione del browser?

score 2 · Answer 1

Gli scambi commerciali sono inerenti alla progettazione del software. Ridurre l'accoppiamento rende quasi sempre più difficile trovare l'implementazione concreta alla quale il tuo codice dipende. Accettiamo questo costo perché rende più semplice cambiare tale implementazione e testarla isolatamente, il che riduce al minimo i tempi necessari per trovare l'implementazione concreta e riduce al minimo gli effetti a catena di eventuali modifiche apportate. Non ingannare te stesso. Solo perché un costo vale la pena di pagare non significa che non ci sia.

score 1 · Answer 2

Lo sviluppo di codice per un'interfaccia è, per quanto ne so, poiché ti consente di apportare modifiche senza dover riscrivere e / o refactoring il tuo codice.

Detto questo, credo che avere un accoppiamento libero possa in un certo modo danneggiare la manutenibilità. Il problema principale che vedo è che le persone possono perdere traccia di ciò che stanno facendo nei metodi precedenti, che può causare mal di testa durante il debug dei problemi, un esempio troppo semplificato sarebbe:

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(...)
     {
         ...
     }
}

Quando esegui il debug del codice in VerufyUtils uno sviluppatore (magari qualcuno che è appena entrato) potrebbe trovare difficile tenere traccia di dove ha preso (ammesso che quanto sopra è semplificato, ma spero tu capisca come vanno le cose ottieni quando hai 100 classi che si chiamano a vicenda).

Se lo sviluppatore può avere difficoltà a rintracciare quale metodo viene utilizzato, eventuali modifiche apportate possono rendere l'applicazione instabile. Quindi, se hai intenzione di adottare un approccio approssimativo, assicurati che il codice che hai e le eventuali modifiche apportate siano documentate. Non c'è bisogno di avere migliaia di parole, ma di solito spiegando perché le cose sono come sono (al contrario di scrivere commenti per spiegare cosa sta facendo il codice) aiuta a mantenere i sistemi liberamente accoppiati in ambito.