In che modo il principio DRY (applicato a livello di classe) è correlato all'SRP?

What I mean is that while SRP states that each class should have only a single responsibility ( ie. class should only have one reason to change ), is it the application of DRY at class level that prevents two classes from having the same responsibility ( thus it is DRY that prevents the repetition/duplication of same responsibility in two different classes )?

No. Non puoi ancora ripetere te stesso, ma viola una singola responsabilità. Allo stesso modo, puoi ripetere te stesso, ma le classi hanno una sola (duplicata, ma sottilmente diversa) responsabilità.

Mentre le due linee guida possono e tenderanno a sovrapporsi, sono concetti ortogonali.

SRP significa che la tua classe dovrebbe avere una sola responsabilità, quindi puoi facilmente nominare la tua classe, e puoi dire solo leggendo il nome, che cosa fa.

DRY significa che non dovresti ripeterti, quindi mantenendo il tuo codice non devi sovrascrivere lo stesso codice due o più volte.

Hanno sicuramente una connessione, perché entrambi riguardano il mantenimento del codice. DRY è uno strumento a basso livello di astrazione per farlo, perché non ha idea di cosa faccia il codice. SRP è uno strumento di alto livello di astrazione per farlo, perché riguarda le responsabilità e non il codice stesso. Quindi dovresti usare entrambi i concetti insieme sviluppando la tua applicazione. Sulla base di ogni caso che ho incontrato fino ad ora, raccomando la regola SRP su DRY. Quindi, in caso di conflitto tra i due principi, puoi decidere quale usare.

Ad esempio, dove A e B sono responsabilità:

Se hai un codice DRY che non soddisfa SRP:

class AB
    doSomethingArelated()
    doSomethingBrelated()

puoi dividerlo nel seguente modo, quindi si incontrerà anche con DRY e SRP:

class A
    doSomethingArelated()

class B
    doSomethingBrelated()

Se hai un codice DRY, ma A e B usano le stesse proprietà:

class AB
    x
    y
    doSomethingArelatedToX()
    doSomethingBrelatedToXAndY()

quindi se vuoi incontrare DRY e SRP contemporaneamente, dovresti usare il polimorfismo. Dovresti usare la composizione sull'ereditarietà perché è più facile da mantenere.

class AB
    a
    b
    doSomethingArelatedToX()
        a.doSomethingArelatedToX()
    doSomethingBrelatedToXAndY()
        b.doSomethingBrelatedToXAndY()

class A
    c
    doSomethingArelatedToX()
        c.doSomethingGeneralToX()

class B
    c
    y
    doSomethingBrelatedToXAndY()
        c.doSomethingGeneralToX()
        doSomethingToY()
    doSomethingToY()

class C
    x
    doSomethingGeneralToX()

In casi davvero speciali, SRP può ignorare DRY:

class AB
    a
    b
    doSomethingArelatedToX()
    doSomethingBrelatedToXAndY()

class A
    x
    doSomethingArelatedToX()

class B
    x
    y
    doSomethingBrelatedToXAndY()

Questo accade con DDD quando si hanno proprietà relative a più contesti limitati . La cosa più comune è l'ID aggregato qui, ma per esempio da un negozio online le dimensioni o il peso del prodotto possono essere importanti anche nei contesti di consegna e di inventario.

Alcuni modelli di progettazione potrebbero consentire di avere una classe più semplice condividendo la routine comune.

Se, per esempio, devi eseguire un calcolo di sconto sulle vendite e nel rapporto sulle vendite, invece di avere lo stesso codice in entrambe le classi, potresti avere una terza classe più specifica che esegue questo calcolo.

In questo modo, la tua classe che calcola la vendita, potrebbe fare affidamento sulla terza classe per ottenere il prezzo finale, così come la classe del rapporto sulle vendite.

Vedi il Pattern di strategia e Pattern composito come esempi di base