La "composizione per eredità" viola il "principio secco"?

Ad esempio, considera che ho una classe per altre classi da estendere:

public class LoginPage {
    public String userId;
    public String session;
    public boolean checkSessionValid() {
    }
}

e alcune sottoclassi:

public class HomePage extends LoginPage {

}

public class EditInfoPage extends LoginPage {

}

In effetti, la sottoclasse non ha alcun metodo per sovrascrivere, inoltre non accederei alla HomePage in modo generico, cioè: non farei qualcosa del tipo:

for (int i = 0; i < loginPages.length; i++) {
    loginPages[i].doSomething();
}

Voglio solo riutilizzare la pagina di accesso. Ma secondo https://stackoverflow.com/a/53354 , dovrei preferire la composizione qui perché non ho bisogno dell'interfaccia LoginPage, quindi non uso l'ereditarietà qui:

public class HomePage {
    public LoginPage loginPage;
}

public class EditInfoPage {
    public LoginPage loginPage;
}

ma il problema arriva qui, nella nuova versione, il codice:

public LoginPage loginPage;

duplicati quando viene aggiunta una nuova classe. E se LoginPage necessita di setter e getter, è necessario copiare più codici:

public LoginPage loginPage;

private LoginPage getLoginPage() {
    return this.loginPage;
}
private void setLoginPage(LoginPage loginPage) {
    this.loginPage = loginPage;
}

Quindi la mia domanda è: la "composizione sull'eredità" viola il "principio secco"?

Aspetta che ti preoccupi di ripetere

public LoginPage loginPage;

in due punti viola SECCO? Secondo quella logica

int x;

ora può sempre esistere in un solo oggetto nell'intera base di codice. Bleh.

DRY è una buona cosa da tenere a mente ma dai. inoltre

... extends LoginPage

viene duplicato nella tua alternativa, quindi anche essere anale su DRY non ha senso.

Le preoccupazioni in merito ai SECCHI SECCHI tendono a concentrarsi su comportamenti identici necessari in più punti definiti in più luoghi in modo tale che la necessità di cambiare questo comportamento finisca per richiedere un cambiamento in più punti. Prendi le decisioni in un unico posto e dovrai solo cambiarle in un unico posto. Ciò non significa che solo un oggetto possa mai contenere un riferimento a LoginPage.

DRY non dovrebbe essere seguito alla cieca. Se stai duplicando perché copiare e incollare è più facile che pensare a un buon metodo o nome di classe, allora probabilmente ti sbagli.

Ma se vuoi mettere lo stesso codice in un posto diverso perché quel posto diverso è soggetto a una diversa responsabilità ed è probabile che debba cambiare in modo indipendente, allora è probabilmente saggio allentare la tua applicazione di DRY e lasciare che questo identico comportamento abbia un'identità diversa . È lo stesso tipo di pensiero che va a proibire i numeri magici.

DRY non riguarda solo l'aspetto del codice. Si tratta di non diffondere i dettagli di un'idea con ripetizione insensata costringendo i manutentori a sistemare le cose usando la ripetizione insensata. È quando provi a dire a te stesso che la ripetizione insensata è solo la tua convenzione che le cose stanno andando in una brutta maniera.

Quello che penso tu stia davvero provando a lamentarti si chiama codice boilerplate. Sì, l'uso della composizione piuttosto che dell'ereditarietà richiede il codice boilerplate. Niente viene esposto gratuitamente, devi scrivere il codice che lo espone. Con quella caldaia deriva la flessibilità dello stato, la capacità di restringere l'interfaccia esposta, di dare alle cose nomi diversi che sono appropriati per il loro livello di astrazione, buona ol indiretta, e stai usando ciò di cui sei composto dall'esterno, non il all'interno, quindi stai affrontando la sua normale interfaccia.

Ma sì, è un sacco di extra digitando la tastiera. Finché posso prevenire il problema yo-yo di far rimbalzare su e giù uno stack di ereditarietà mentre leggo il codice, ne vale la pena.

Ora non è che mi rifiuto di usare l'eredità. Uno dei miei usi preferiti è dare eccezioni a nuovi nomi:

public class MyLoginPageWasNull extends NullPointerException{}

Un malinteso comune con il principio DRY è che è in qualche modo correlato al non ripetere righe di codice. Il principio DRY è "Ogni pezzo di conoscenza deve avere un'unica, inequivocabile, autorevole rappresentazione all'interno di un sistema" . Riguarda la conoscenza, non il codice.

LoginPagesa come disegnare la pagina per il login. Se EditInfoPagesapessi come farlo, sarebbe una violazione. Includere LoginPagetramite composizione non è in alcun modo una violazione del principio DRY.

Il principio DRY è forse il principio più abusato nell'ingegneria del software e dovrebbe sempre essere considerato non come un principio per non duplicare il codice, ma come un principio per non duplicare la conoscenza del dominio astratto. In realtà, in molti casi se si applica DRY correttamente, si duplicherà il codice e questa non è necessariamente una cosa negativa.

Risposta breve: sì, lo fa - in misura minore, accettabile.

A prima vista, l'ereditarietà a volte può salvarti alcune righe di codice, poiché ha l'effetto di dire "la mia classe di riutilizzo conterrà tutti i metodi e gli attributi pubblici in un modo 1: 1". Quindi, se esiste un elenco di 10 metodi in un componente, non è necessario ripeterli nel codice nella classe ereditata. Quando in uno scenario di composizione 9 di questi 10 metodi devono essere esposti pubblicamente attraverso un componente di riutilizzo, si deve scrivere 9 chiamate deleganti e lasciare uscire quella rimanente, non c'è modo di aggirare questo.

Perché è tollerabile? Guarda i metodi replicati in uno scenario di composizione: questi metodi delegano esclusivamente le chiamate all'interfaccia del componente, quindi non contengono alcuna logica reale.

Il cuore del principio DRY è quello di evitare di avere due posizioni nel codice in cui sono codificate le stesse regole logiche . Perché quando queste regole logiche cambiano, nel codice non DRY è facile adattare uno di quei luoghi e dimenticare l'altro, che introduce un errore.

Ma poiché delegare le chiamate non contiene logica, queste non sono normalmente soggette a tale cambiamento, quindi non causano un vero problema quando "preferiscono la composizione rispetto all'eredità". E anche se l'interfaccia del componente cambia, il che potrebbe indurre cambiamenti formali in tutte le classi usando il componente, in un linguaggio compilato il compilatore ci dirà quando ci siamo dimenticati di cambiare uno dei chiamanti.

Una nota al tuo esempio: non so come tu HomePagee il tuoEditInfoPage , ma se hanno la funzionalità di accesso e un HomePage(o un EditInfoPage) è un LoginPage , allora l'ereditarietà potrebbe essere lo strumento corretto qui. Un esempio meno discutibile, in cui la composizione sarà lo strumento migliore in un modo più ovvio, probabilmente renderebbe le cose più chiare.

Supponendo che HomePagenéEditInfoPage sono una LoginPage, e vuole riutilizzare questi ultimi, come hai scritto, che è abbastanza probabile che uno richiede solo alcune parti del LoginPage, non tutto. In tal caso, potrebbe essere un approccio migliore rispetto all'uso della composizione nel modo mostrato

• estrarre la parte riutilizzabile LoginPagein un componente a sé stante

• riutilizzare quel componente in HomePage e EditInfoPagenello stesso modo in cui viene utilizzato ora all'internoLoginPage

In questo modo, in genere diventerà molto più chiaro perché e quando la composizione sull'ereditarietà è l'approccio giusto.