In termini di principio di separazione delle interfacce (ISP), cosa si intende in base ai metodi non utilizzati?

Il client ha una dipendenza dall'interfaccia e l'interfaccia dichiara i metodi che devono essere implementati. Quindi se hai:

IDependency 
{
    RequiredByClient();
    NotRequiredByClient();
}

e

Client(IDependency dependency)

Quindi il compilatore garantisce che qualsiasi IDependency fornita al client DEVE implementare entrambi i metodi. Se scrivo una nuova implementazione della dipendenza solo per il mio cliente, sono costretto a fare qualcosa del tipo:

MyDependency : IDependency 
{
    RequiredByClient()
    {
        dostuff();
    }

    NotRequiredByClient()
    {
        throw NotImplementedException();
    }
}

Che causerà problemi se qualcuno tenta di usarlo in un altro scenario. ad esempio

Client2WhichNeedsTheOtherMethod(IDependency dependency); //i hope this works!!

In realtà voglio essere in grado di scrivere

MyDependency : IDependencyForClient
{
    RequiredByClient()
    {
        dostuff();
    }
}

Ma per essere in grado di farlo devo dividere l'interfaccia in due e definire il client come

IDependencyForClient
{
    RequiredByClient();
}

IDependencyForClient2
{
    NotRequiredByClient();
}

Client(IDependencyForClient dependency)

Hai un punto , in puro linguaggio OO come Java non hai metodi stand-alone, quindi quando parliamo di dipendenza parliamo di classi e interfacce, non di metodi. Quindi, per concetto, la frase "dipende dai metodi" è sbagliata.

Detto questo, proviamo a chiarire in che modo le interfacce non segregate, cioè le interfacce che sono troppo generiche e quindi hanno troppi mathod che non sono specifici del client, possono causare danni. Sono sicuro che lo sai ma potrebbe aiutare gli altri lettori.

Implementors:

Quando implementi un'interfaccia, sei costretta a implementare tutti i suoi metodi (*) anche se lasci solo stub che non fanno nulla o restituiscono null, non puoi semplicemente ignorarli.

Una volta implementato il metodo di un'interfaccia, si ha una dipendenza da quel metodo. Se questo metodo, ad esempio, arriva a lanciare una nuova eccezione nella dichiarazione dell'interfaccia, sarà costretto ad aggiungerlo alle tue classi di implementazione.

Classi cliente:

Questo è il caso in cui potresti teoricamente ignorare i metodi che non usi, e questo è esattamente ciò che il principio menziona (i clienti). Per capirlo, rivediamo un altro principio, il DIP che afferma che si dovrebbe dipendere dalle astrazioni, non dalle concrezioni. Quindi le interfacce rendono possibile il DIP. Bene, quando si dipende da un'interfaccia, si dipende dall'intero di esso, non solo dai metodi A o B. Ciò che significa il principio è che molti interfacce client-specifici sono meglio di una grande interfaccia generica. Forse la classe, in senso stretto, non dipende dai metodi non utilizzati, ma tu come programmatore devi conoscerli. Semplicemente immaginando di programmare una classe che usa oggetti che implementano l'intefaccia gigante X che contiene metodi che non usi ... l'IDE manterrà una lista molto lunga di metodi che non usi e anche quando leggi la documentazione dell'interfaccia dovrai passare attraverso la documentazione di tutti quei metodi.

(*) L'eccezione di questo sono classi astratte che non sono forzate ad implementare nulla ma poi qualsiasi classe che la estende dovrà implementare tutti i metodi.

Ecco un buon link che spiega la dipendenza:

link

Voglio riassumere il problema. Prima di tutto dovremmo capire i termini:

Cliente - Il derivato concreto dell'interfaccia (grossa) che potrebbe non essere segregata, cioè abbastanza piccola Servizio - Alcune funzioni che accettano un oggetto che implementa l'interfaccia (in un Cliente concreto) e fa qualcosa per quel cliente

Quindi alcuni servizi non utilizzano alcuni metodi dell'interfaccia che un cliente deve implementare e altri li usano tutti. Tuttavia, poiché tale client è costretto a implementare tutti i metodi anche se per alcune istanze client specifiche e per alcune istanze di servizio specifiche il metodo non è rilevante, diciamo che il client dipende dalle funzioni che esegue non usare .