Implementazione dell'interfaccia Principio di segregazione

3

Questa interfaccia IConvertible soddisfa il principio di segregazione dell'interfaccia (ad esempio "I" in SOLID )?

Ecco la definizione:

public interface IConvertible
{
    TypeCode GetTypeCode(); 
    bool ToBoolean(IFormatProvider provider);
    byte ToByte(IFormatProvider provider);
    char ToChar(IFormatProvider provider);
    DateTime ToDateTime(IFormatProvider provider);
    decimal ToDecimal(IFormatProvider provider);
    short ToInt16(IFormatProvider provider);
    int ToInt32(IFormatProvider provider);
    long ToInt64(IFormatProvider provider);
    sbyte ToSByte(IFormatProvider provider);
    float ToSingle(IFormatProvider provider);
    string ToString(IFormatProvider provider);
    object ToType(Type conversionType, IFormatProvider provider);
    ushort ToUInt16(IFormatProvider provider);
    uint ToUInt32(IFormatProvider provider);
    ulong ToUInt64(IFormatProvider provider);
}

Quindi, se mi piacerebbe avere una classe che implementerà questa interfaccia IConvertible , devo implementare tutti questi metodi, giusto? O se non li implemento tutti, allora devo almeno fare un metodo vuoto o lanciare un'eccezione, giusto?

Secondo me, il modo migliore è rendere più interfacciabile con meno metodi, ad esempio:

public interface IConvertibleInt
{
        short ToInt16(IFormatProvider provider);
        int ToInt32(IFormatProvider provider);
        long ToInt64(IFormatProvider provider);
}

O anche:

public interface IConvertibleInt16
{
        short ToInt16(IFormatProvider provider);
}

public interface IConvertibleInt32
{            
        int ToInt32(IFormatProvider provider);
}

public interface IConvertibleInt64
{
        long ToInt64(IFormatProvider provider);
}

Il mio ragionamento è corretto?

    
posta Jacob 23.03.2014 - 12:25
fonte

3 risposte

8

Mi piace interpretare il principio di segregazione dell'interfaccia come

Interface should be closer related to the code that uses it than code that implement it. So the methods on the interface are defined by which methods client code needs than which methods class implements.

Questo implica che per ogni interfaccia, c'è sempre un codice che usa questa interfaccia. Questo non è il caso di IConvertible . L'interfaccia in sé non ha molto senso. Inoltre non ho mai visto la proprietà o la funzione che è stata digitata IConvertible , che potenzia le mie affermazioni. Mi chiedo persino come sarebbe il codice che funziona solo con IConvertible e cosa farebbe.

    
risposta data 23.03.2014 - 14:46
fonte
1

Una difficoltà nell'applicazione del principio di segregazione dell'interfaccia in .NET è che ogni posizione di memoria specificata deve avere un singolo tipo specificato. Se ci fossero state interfacce separate per IConvertibleToInt32 , IConvertibleToInt64 , allora un tipo che supportava solo alcune conversioni avrebbe dovuto solo implementare quelle supportate; il codice che richiedeva esattamente un'interfaccia di conversione poteva accettare un parametro di quel tipo. Sfortunatamente, suddividere le cose in quel modo renderebbe difficile scrivere codice che richiede più di un'interfaccia di conversione. Ad esempio, se un metodo necessario per utilizzare IConvertibleToInt32 , ma che doveva passare un oggetto a un metodo che aveva bisogno di IConvertibleToInt64 , non ci sarebbe alcun modo per specificare che aveva bisogno di un oggetto che supportava entrambe le interfacce a meno che non esistesse un interfaccia che ha ereditato da entrambi e tutti i tipi di interesse che implementano entrambe le interfacce implementano anche quella composita .

Se .NET fatto avesse un modo di definire un tipo speciale di interfaccia "composita" in modo tale che qualsiasi classe che implementasse tutti i componenti sarebbe automaticamente considerata come un'implementazione del composito, allora avrebbe senso suddividere le interfacce molto più finemente. La mancanza di tale capacità, tuttavia, rende necessario definire interfacce molto più grossolane di quelle che sarebbero ideali.

    
risposta data 25.03.2014 - 20:07
fonte
0

IConvertible non viola né è conforme al principio di segregazione dell'interfaccia. Il principio è seguito o meno da classi che dipendono dall'interfaccia, non dall'interfaccia.

Una classe potrebbe dipendere dall'interfaccia e usare ogni metodo, non violando il principio. Un altro potrebbe dipendere dall'interfaccia e utilizzare un metodo, violando il principio. Questo significa che IConvertible viola entrambi e non viola il principio? No. Significa che una classe dipende da ciò che fa e l'altra no.

Sì, IConvertible è un'interfaccia strana, ma isolatamente non illustra l'ISP.

Vale anche la pena di considerare il motivo alla base del principio, ovvero che se più classi dipendono da diversi metodi di un'interfaccia, un "client" potrebbe esercitare una pressione all'indietro per cambiare l'interfaccia, il che significa modificare un'interfaccia e possibilmente implementazioni che potrebbero influire sul codice non correlato. È una forma di accoppiamento.

È molto improbabile che IConvertible cambi per soddisfare le esigenze di ogni singolo cliente, quindi il rischio che è la ragione del principio viene mitigato.

    
risposta data 04.01.2019 - 15:18
fonte

Leggi altre domande sui tag