Qual è il ragionamento alla base del principio di segregazione delle interfacce?

Question

Il principio di segregazione delle interfacce (ISP) afferma che molte interfacce specifiche del client sono migliori di un'interfaccia generica.Perché questo è importante?

Answer 1

L'ISP afferma che:

I clienti non dovrebbero essere costretti a dipendere dai metodi che non utilizzano.

L'ISP si riferisce a caratteristiche importanti: coesione E accoppiamento.
Idealmente i tuoi componenti devono essere altamente personalizzati.Migliora la robustezza e la manutenibilità del codice.

L'applicazione dell'ISP ti offre i seguenti bonus:

• Alto coesione - migliore comprensibilità e robustezza
• Basso accoppiamento - migliore manutenibilità, elevata resistenza ai cambiamenti

Se vuoi saperne di più sui principi di progettazione del software, ottieni una copia di Sviluppo software agile, principi, modelli e pratiche libro.

Answer 2

La segregazione dell’interfaccia è l’“io” sul principio SOLIDO, prima di scavare troppo in profondità con la prima, spieghiamo cosa significa quest’ultima.

SOLID può essere considerato un insieme di migliori pratiche e raccomandazioni formulate da esperti (nel senso che sono state dimostrate in precedenza) al fine di fornire una base affidabile nel modo in cui progettiamo le applicazioni.Queste pratiche mirano a semplificare la manutenzione, l'estensione, l'adattamento e la scalabilità delle nostre applicazioni.

Perché dovrebbe interessarmi la programmazione SOLID?

Prima di tutto, devi capire che non rimarrai per sempre dove sei.Se utilizziamo standard e architetture ben conosciute, possiamo essere sicuri che il nostro codice sarà facile da manutenere da parte di altri sviluppatori che verranno dopo di noi, e sono sicuro che non vorrai occuparti del compito di correggere un codice che non funziona Non ho applicato alcuna metodologia conosciuta poiché sarebbe molto difficile capirla.

Il principio di segregazione delle interfacce.

Sapendo che sappiamo quali sono i principi SOLID, possiamo entrare più in dettaglio sul principio di segregazione dell'interfaccia, ma cosa dice esattamente la segregazione dell'interfaccia?

"I clienti non dovrebbero essere costretti a implementare metodi non necessari che non utilizzeranno"

Ciò significa che a volte tendiamo a creare interfacce con molti metodi, il che può essere positivo in una certa misura, tuttavia se ne può facilmente abusare e possiamo finire con classi che implementano metodi vuoti o inutili che ovviamente aggiungono codice e oneri aggiuntivi alle nostre app.Immagina di dichiarare molti metodi in un'unica interfaccia, se ti piacciono gli aiuti visivi, una classe che sta implementando un'interfaccia ma che ha davvero bisogno di un paio di metodi sarebbe simile a questa:

D'altra parte, se applichi correttamente la segregazione dell'interfaccia e dividi la tua interfaccia in sottoinsiemi più piccoli puoi essere sicuro di implementare solo quelli necessari:

Vedere!È decisamente migliore!L'applicazione di questo principio consentirà di avere un accoppiamento basso che favorisce una migliore manutenibilità e un'elevata resistenza ai cambiamenti.Quindi puoi davvero sfruttare l'utilizzo delle interfacce e implementare i metodi quando dovresti davvero.Ora esaminiamo un esempio meno astratto, supponiamo che tu abbia dichiarato un'interfaccia chiamata Reportable

public interface Reportable {

        void printPDF();
        void printWord();
        void printExcel();
        void printPPT();
        void printHTML();


}

E hai un client che esporta solo alcuni dati in formato Excel, puoi implementare l'interfaccia, ma dovresti implementare solo il metodo Excel?La risposta è no, dovrai codificare l'implementazione per tutti i metodi anche se non li utilizzerai, questo può causare molto codice spazzatura, rendendo quindi difficile la manutenzione del codice.

Ricorda di mantenerlo semplice e di non ripeterti e scoprirai che stai già utilizzando questo principio senza saperlo.

Answer 3

Semplifica l'interfaccia che ciascun client utilizzerà e rimuove le dipendenze che potrebbero altrimenti sviluppare su parti dell'interfaccia di cui non hanno bisogno.

Answer 4

Uno dei motivi è che avere molte interfacce con una quantità minima di metodi per ciascuna rende più semplice implementare ciascuna interfaccia e implementarla correttamente.Un'interfaccia di grandi dimensioni può essere indisciplinata.Inoltre, l'utilizzo di un'interfaccia mirata in uno scenario rende il codice più manutenibile perché puoi vedere quale aspetto dell'oggetto viene utilizzato (ad esempio, un'interfaccia IComparable ti consente di sapere che l'oggetto viene utilizzato solo per i confronti nello scenario specificato).

Answer 5

Questo principio ha principalmente due scopi

• Per rendere il codice più leggibile e gestibile.

• Promuove la responsabilità unitaria delle classi (alta coesione).Ovviamente perché una classe dovrebbe avere un metodo che non ha alcun impatto comportamentale?Perché non semplicemente rimuoverlo.Questo è ciò che riguarda l'ISP

Ci sono poche domande che un progettista deve porre con preoccupazione all'ISP

• Cosa si ottiene con l'ISP
• Come analizzare un codice già esistente per eventuali violazioni dell'ISP

Per portare avanti questa discussione, devo anche aggiungere che questo principio non è un "principio" nel senso più stretto, perché in determinate circostanze, applicare l'ISP al progetto, invece di promuovere la leggibilità, potrebbe rendere la struttura dell'oggetto illeggibile e ingombra di codice non necessario.Puoi osservarlo nel pacchetto java.awt.event

Altro sul mio blog: http://design-principle-pattern.blogspot.in/2013/12/interface-segregation-principle.html

Answer 6

ISP è importante.

Idea di base dell'ISP:Il cliente non dovrebbe essere costretto a dipendere da metodi che non utilizza.

Questo principio sembra essere più logico.Idealmente il cliente non dovrebbe implementare i metodi che non vengono utilizzati dal cliente.

Fare riferimento alla domanda SE di seguito per un esempio di codice:

Principio di segregazione dell'interfaccia: programma su un'interfaccia

Vantaggi:

1. Flessibilità :In assenza di ISP, hai un'interfaccia FAT generica e molte classi che la implementano.Supponiamo di avere 1 interfaccia e 50 classi.Se c'è un cambiamento nell'interfaccia, tutte le 50 classi devono cambiare la loro implementazione.

   Con l'ISP, dividerai l'interfaccia FAT generica in piccole interfacce granulari e fini.Se viene apportata una modifica all'interfaccia granulare piccola, verranno interessate solo le classi che implementano tale interfaccia.

2. Manutenibilità e facilità d'uso:Poiché le modifiche sono limitate all'interfaccia granulare invece che all'interfaccia FACT generica, la manutenzione del codice è più semplice.Il codice non correlato non fa più parte delle classi di implementazione.

Answer 7

Per evitare sforzi di regressione, quando cambia solo uno specifico del cliente o uno specifico del comportamento.Se hai combinato tutti i tuoi metodi di comportamento in un'unica GRANDE interfaccia, pensa solo a come finirai per testare tutti i pezzi di codice a cui tutto ciò a cui hai fatto riferimento è quell'interfaccia, anche quando si sono verificati solo piccoli cambiamenti.

Per una spiegazione più dettagliata, fare riferimento a Articolo sul principio di segregazione delle interfacce

Answer 8

L'articolo di Robert Martin sull'argomento fornisce una spiegazione che viene menzionata meno spesso:

La forza all'indietro applicata dai client sulle interfacce.

Se due classi dipendono direttamente da due diversi metodi di una terza classe, aumenta la probabilità che le modifiche apportate a una delle prime due classi influenzino l'altra.

Supponiamo di avere tre classi: Red, Green, E Blue.

Red E Green entrambi dipendono Blue, ma ciascuno dipende da un metodo diverso.Ciò significa che Red dipende da un metodo di Blue ma non utilizza l'altro metodo.Allo stesso modo, Green dipende da Blue, ma utilizza solo un metodo, non l'altro.

C'è la violazione del principio Red E Green perché ognuno dipende da una classe - Blue - Ma no utilizzare almeno uno dei suoi metodi.

Che problema crea questo potenzialmente?

• Ho bisogno di cambiare Red, e cambio anche Blue per soddisfare le esigenze di Red.
• Non ho cambiato il metodo specifico all'interno Blue Quello Green dipende, ma comunque Green dipende da Blue e sono cambiato Blue, che potrebbe comunque avere un impatto Green.
• Pertanto, le mie modifiche a Red hanno il potenziale per avere un impatto Blue perché mi hanno portato a cambiare una classe da cui dipendono entrambi.

Questa è la "forza all'indietro". A volte cambiamo una classe a causa delle esigenze dei suoi clienti.Se quella classe ha clienti diversi che la utilizzano per cose diverse, rischiamo di influenzarli.

Come affermato, la semplice definizione del principio di segregazione dell'interfaccia è:

nessun cliente dovrebbe essere costretto a dipendere da metodi che non utilizza.

Tra questo e il punto precedente dell'articolo di Robert Martin, è evidente che molte spiegazioni dell'ISP parlano in realtà di altri principi.

• Classi o interfacce con molti metodi sono indesiderabili, ma non specificamente a causa dell'ISP.Potrebbero violare la responsabilità unica.Ma la violazione dell'ISP non è nella grande interfaccia o nella grande classe: è nelle classi that dipende da sulla grande interfaccia se non utilizzano tutti i suoi metodi.Se usano tutti i metodi sembra comunque complicato, ma ciò non ha nulla a che fare con l'ISP.
• Le classi che implementano un'interfaccia ma generano eccezioni per determinati metodi sono negative, ma non è nemmeno l'ISP.L'ISP riguarda le classi che dipendere sulle interfacce, non sulle classi strumento interfacce.

Se cerchiamo su Google "segregazione dell'interfaccia", la maggior parte dei risultati principali che includono esempi di codice dimostrano classi che non implementare completamente interfacce, che non è lo scopo dell'ISP.Alcuni addirittura ribadiscono il principio:

Il principio di segregazione delle interfacce afferma che i client non dovrebbero essere costretti a implementare interfacce che non utilizzano

...ma è così non il principio.Il documento definitivo menziona tali preoccupazioni come un effetto collaterale della violazione dell'ISP, ma indica che si tratta di violazioni della sostituzione di Liskov.

Inoltre, ogni volta che una nuova interfaccia viene aggiunta alla classe base, tale interfaccia deve essere implementata (o consentita di inadempienza) in classi derivate.In effetti, una pratica associata è quella di aggiungere queste interfacce alla classe base come funzioni virtuali pari a zero anziché come funzioni virtuali pure;specificamente in modo che le classi derivate non siano gravate dalla necessità di implementarle.Come abbiamo appreso nel secondo articolo di questa rubrica, tale pratica viola il principio di sostituzione di Liskov (LSP), portando a problemi di manutenzione e riusabilità.

Inoltre, dire che un cliente non dovrebbe implementare metodi che non utilizza non ha nemmeno senso.IL clienti di un'interfaccia non ne implementano i metodi.

Non intendo citare pomposamente il documento come se fosse una sacra scrittura o qualcosa del genere.Ma se useremo il nome del principio descritto nell'articolo (il nome dell'articolo stesso), allora dovremmo considerare anche la definizione e la spiegazione effettiva contenuta in quell'articolo.