Quando si applica la segregazione dell'interfaccia, si dovrebbero separare le interfacce per i setter regolari e le operazioni matematiche?

Question

Quando si applica la segregazione dell'interfaccia, si dovrebbero separare le interfacce per i setter regolari e le operazioni matematiche?

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

6

Quando si applica la separazione delle interfacce, si dovrebbero avere interfacce separate per setter e interfacce semplici che eseguono un'operazione prima dell'impostazione? Ad esempio, supponi di avere una classe:

class FooClass:
     public GettableFoo,
     public SettableFoo
{
    virtual int getRelevantData();  
    // member of GettableFoo (which is used by roughly 20 clients)

    virtual void setToOtherFooTemplate(GettableFoo *other);
    // member of SettableFoo (which is used by roughly 20 clients, some of which also need GettableFoo interface)

    void setToSum(GettableFoo *a,GettableFoo *b);
    // requires SettableFoo functions to implement, used by 8 clients, some of which also need SettableFoo interface

    void combineSomeOtherWay(GettableFoo *a,GettableFoo *b);
    // requires SettableFoo functions to implement, used by 4 clients (possibly more in the future), some of which also need SettableFoo interface and/or which require the setToSum function

private:
  // complex data
}

Il principio di segregazione dell'interfaccia afferma che nessun client dovrebbe essere costretto a dipendere da metodi che non usa. Significa che setToSum () e combineSomeOtherWay () dovrebbero avere le proprie interfacce? La risposta sembra che dovrebbe essere sì, ma non credo di aver mai incontrato un codice con interfacce segregate così tanto.

Se la risposta a quanto sopra è sì, non significherebbe se combineSomeOtherWay () fosse solo setToProduct () (moltiplica) e io abbia usato l'overloading dell'operatore per entrambi per implementare questo in C ++, che tecnicamente il sovraccarico dell'operatore interromperebbe il principio di segregazione dell'interfaccia, date le esigenze del cliente sopra indicate? E se così fosse, la maggior parte dei casi in cui viene utilizzato il sovraccarico dell'operatore sta rompendo l'ISP, e in caso contrario, come è diverso dal non segregare nessuna delle interfacce nella classe sopra?

object-oriented design-patterns solid

posta knock 21.06.2015 - 19:24

fonte

2 risposte

Leggi altre domande sui tag object-oriented design-patterns solid

Introdurre oggetti di trasferimento dati o esporre il modello di dati complessi in REST Come organizzare le query predefinite con Entity Framework?

score 2 · Answer 1

Ti suggerisco di presentarti all'ISP dal punto di vista del codice client.

In quanti posti viene utilizzata la tua classe? C'è qualche classe cliente che ha bisogno solo di un metodo, ma non dell'altro? Se tutto il codice cliente ha bisogno di entrambi, sembra che non ci sia un caso per due interfacce.

Se hai due diversi posti in cui viene utilizzata la tua classe, ognuno dei quali richiede un metodo ma non l'altro, il principio di segregazione dell'interfaccia dice che dovresti avere un'interfaccia per ogni caso d'uso. La tua classe implementerebbe quindi esplicitamente due interfacce.

Tieni presente che nella spesso citata storia di "Xerox" dell'invenzione dell'ISP, è stato un primo passo nella decomposizione di un oggetto di Dio. Avere due interfacce per la tua classe va bene, ma vale la pena chiedersi se la classe può essere spezzata sensibilmente a metà. Come altri hanno già detto, esiste uno stretto legame tra ISP e SRP (principio di responsabilità singola) qui.

score 2 · Answer 2

Trovo utile pensare a un'interfaccia come un ruolo che un oggetto può riprodurre. Quindi, se un client dipende da un singolo ruolo per fare il suo lavoro, dipenderà solo da un'interfaccia.

Se un gruppo di metodi appartiene allo stesso ruolo, allora non viola l'ISP per inserirli in un'unica interfaccia. Ad esempio, un insieme di overload mutuamente esclusivi per fare la stessa cosa in un modo leggermente diverso probabilmente appartiene a un singolo ruolo.

Separare le interfacce è una buona cosa perché dà ai clienti la possibilità e li incoraggia a essere progettati in modo più modulare e ad accoppiarsi a un contratto più stretto. E in realtà non causa significativi over-engineering o altri overhead, a differenza di altre tecniche / pattern di OOP.

È sempre possibile unire facilmente più interfacce in una sola se ha senso. Molto più difficile è dividere un'interfaccia dopo aver già un gruppo di clienti che ora hanno troppa responsabilità e accoppiamento perché gli è stato concesso di dipendere da un'interfaccia enorme. Questo è il motivo per cui non è sempre una buona idea affidarsi ai clienti per dirti come suddividere un'interfaccia.

Riepilogo:

modello ruoli che hanno senso per la tua applicazione
in caso di dubbio, segrega di più