Due definizioni contraddittorie del principio di segregazione dell'interfaccia: qual è quella corretta?

Quando si leggono articoli su ISP, sembrano esserci due definizioni contraddittorie di ISP:

Secondo la prima definizione (vedi 1 , 2 , 3 ), l'ISP afferma che le classi che implementano l'interfaccia non dovrebbero essere costrette a implementare funzionalità di cui non hanno bisogno. Quindi, interfaccia fatIFat

interface IFat
{
     void A();
     void B();
     void C();
     void D();
}

class MyClass: IFat
{ ... }

dovrebbe essere suddiviso in interfacce più piccole ISmall_1eISmall_2

interface ISmall_1
{
     void A();
     void B();
}

interface ISmall_2
{
     void C();
     void D();
}

class MyClass:ISmall_2
{ ... }

poiché in questo modo my MyClassè in grado di implementare solo i metodi di cui ha bisogno ( D()e C()), senza essere costretto a fornire anche implementazioni fittizie per A(), B()e C():

Ma secondo la seconda definizione (vedi 1 , 2 , risposta di Nazar Merza ), l'ISP afferma che MyClientchiamare i metodi su MyServicenon dovrebbe essere consapevole dei metodi su MyServicecui non ha bisogno. In altre parole, se MyClientsolo ha bisogno della funzionalità di C()e D(), quindi invece di

class MyService 
{
    public void A();
    public void B();
    public void C();
    public void D();
}

/*client code*/      
MyService service = ...;
service.C(); 
service.D();

dovremmo separare i MyService'smetodi in interfacce specifiche del cliente :

public interface ISmall_1
{
     void A();
     void B();
}

public interface ISmall_2
{
     void C();
     void D();
}

class MyService:ISmall_1, ISmall_2 
{ ... }

/*client code*/
ISmall_2 service = ...;
service.C(); 
service.D();

Pertanto, con la prima definizione, l'obiettivo dell'ISP è " semplificare la vita delle classi che implementano l'interfaccia IFat ", mentre con quest'ultima l'obiettivo dell'ISP è " semplificare la vita dei clienti che chiamano i metodi di MyService ".

Quale delle due diverse definizioni di ISP è effettivamente corretta?

@MARJAN VENEMA

1.

Quindi, quando hai intenzione di dividere IFat in un'interfaccia più piccola, quali metodi finiscono in cui ISmallinterface dovrebbe essere deciso in base alla coesione dei membri.

Mentre ha senso mettere metodi coerenti all'interno della stessa interfaccia, ho pensato che con il modello ISP le esigenze del cliente abbiano la precedenza sulla "coesione" di un'interfaccia. In altre parole, ho pensato che con l'ISP dovremmo raggruppare all'interno della stessa interfaccia quei metodi richiesti da determinati clienti, anche se ciò significa lasciare fuori da quella interfaccia quei metodi che dovrebbero, per motivi di coesione, essere inseriti all'interno di quella stessa interfaccia?

Così, se c'erano un sacco di clienti che saranno sempre e solo bisogno di chiamare CutGreens, ma non anche GrillMeat, poi per aderire al modello ISP dobbiamo solo mettere CutGreensdentro ICook, ma non anche GrillMeat, anche se i due metodi sono altamente coesivo ?!

2.

Penso che la tua confusione derivi da un presupposto nascosto nella prima definizione: che le classi attuatrici stanno già seguendo il principio della responsabilità unica.

"Implementando classi che non seguono SRP" ti riferisci a quelle classi che implementano IFato alle classi che implementano ISmall_1/ ISmall_2? Presumo che ti riferisci alle classi che implementano IFat? In tal caso, perché pensi che non seguano già SRP?

Grazie

Sono corretti entrambi

Il modo in cui l'ho letto, lo scopo dell'ISP (Interface Segregation Principle) è di mantenere le interfacce piccole e focalizzate: tutti i membri dell'interfaccia dovrebbero avere una coesione molto elevata. Entrambe le definizioni hanno lo scopo di evitare interfacce "jack-of-all-trades-master-of-none".

La segregazione dell'interfaccia e SRP (Single Responsibility Principle) hanno lo stesso obiettivo: garantire componenti software piccoli e altamente coerenti. Si completano a vicenda. La segregazione delle interfacce assicura che le interfacce siano piccole, mirate e altamente coesive. Seguire il principio della responsabilità unica garantisce che le classi siano piccole, mirate e altamente coerenti.

La prima definizione menzionata si concentra sugli implementatori, la seconda sui client. Che, contrariamente a @ user61852, prendo per essere gli utenti / chiamanti dell'interfaccia, non gli implementatori.

Penso che la tua confusione derivi da un presupposto nascosto nella prima definizione: che le classi attuatrici stanno già seguendo il principio della responsabilità unica.

Per me la seconda definizione, con i clienti come chiamanti dell'interfaccia, è un modo migliore per raggiungere l'obiettivo previsto.

segregante

Nella tua domanda dichiari:

in questo modo MyClass è in grado di implementare solo i metodi di cui ha bisogno (D () e C ()), senza essere costretto a fornire anche implementazioni fittizie per A (), B () e C ():

Ma questo sta capovolgendo il mondo.

• Una classe che implementa un'interfaccia non detta ciò di cui ha bisogno nell'interfaccia che sta implementando.
• Le interfacce determinano quali metodi dovrebbe fornire una classe di implementazione.
• I chiamanti di un'interfaccia sono davvero quelli che dettano quale funzionalità hanno bisogno dell'interfaccia per fornire loro e quindi ciò che un implementatore dovrebbe fornire.

Quindi, quando hai intenzione di dividere IFatin un'interfaccia più piccola, quali metodi finiscono in quale ISmallinterfaccia dovrebbe essere decisa in base alla coesione dei membri.

Considera questa interfaccia:

interface IEverythingButTheKitchenSink
{
     void DoDishes();
     void CleanSink();
     void CutGreens();
     void GrillMeat();
}

Quali metodi inseriresti ICooke perché? Metteresti CleanSinkinsieme GrillMeatsolo perché ti capita di avere una classe che fa proprio questo e un paio di altre cose, ma niente di simile a nessuno degli altri metodi? O lo divideresti in altre due interfacce coerenti, come:

interface IClean
{
     void DoDishes();
     void CleanSink();
}

interface ICook
{
     void CutGreens();
     void GrillMeat();
}

Nota sulla dichiarazione dell'interfaccia

La definizione di un'interfaccia dovrebbe preferibilmente essere autonoma in un'unità separata, ma se deve assolutamente convivere con il chiamante o l'implementatore, dovrebbe davvero essere con il chiamante. In caso contrario, il chiamante ottiene una dipendenza immediata dall'implementatore che sta completamente annullando lo scopo delle interfacce. Vedi anche: Dichiarare l'interfaccia nello stesso file della classe base, è una buona pratica? sui programmatori e perché dovremmo collocare interfacce con le classi che le usano piuttosto che con quelle che le implementano? su StackOverflow.

Si confonde la parola "client" come utilizzata nella banda di quattro documenti con un "client" come nel consumatore di un servizio.

Un "client", come inteso da Gang of Four definizioni, è una classe che implementa un'interfaccia. Se la classe A implementa l'interfaccia B, allora dicono che A è un client di B. Altrimenti la frase "i client non dovrebbero essere costretti a implementare interfacce che non usano" non avrebbe senso dal momento che "i clienti" (come nei consumatori) don non implementare nulla. La frase ha senso solo quando vedi "client" come "implementatore".

Se "client" intendesse una classe che "consuma" (chiama) i metodi di un'altra classe che implementa la grande interfaccia, allora chiamando i due metodi che ti interessano e ignorando il resto, sarebbe sufficiente per tenerti disaccoppiato dal resto di i metodi che non usi.

Lo spirito del principio è evitare che il "client" (la classe che implementa l'interfaccia) debba implementare metodi fittizi per conformarsi all'intera interfaccia quando si preoccupa solo di una serie di metodi correlati.

Inoltre mira ad avere il minor numero possibile di accoppiamenti in modo tale che le modifiche apportate in un punto causino il minor impatto. Separando le interfacce si riduce l'accoppiamento.

Questi problemi si presentano quando l'interfaccia fa troppo e ha metodi che dovrebbero essere divisi in più interfacce anziché in una sola.

Entrambi gli esempi di codice sono OK . È solo che nella seconda si assume che "client" significhi "una classe che consuma / chiama i servizi / metodi offerti da un'altra classe".

Non trovo contraddizioni nei concetti spiegati nei tre collegamenti che hai dato.

Mantieni chiaro che "client" è implementatore , in SOLID talk.

L'ISP consiste nell'isolare il client dalla conoscenza più del servizio di quanto non ne abbia bisogno (proteggendolo dalle modifiche non correlate, ad esempio). La tua seconda definizione è corretta. Secondo la mia lettura, solo uno di questi tre articoli suggerisce il contrario ( il primo ) ed è semplicemente sbagliato. (Modifica: No, non sbagliato, solo fuorviante.)

La prima definizione è molto più strettamente legata a LSP.