Riconciliazione dell'interfaccia Principio di segregazione con la necessità di identificare univocamente un oggetto

Question

Riconciliazione dell'interfaccia Principio di segregazione con la necessità di identificare univocamente un oggetto

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

-1

Ho un'interfaccia ICondition che definisce solo un singolo metodo, IsConditionMet

Funziona bene poiché è l'unica informazione che l'entità genitore ha bisogno dalle sue condizioni.

Tuttavia, c'è una situazione in cui un utente deve rimuovere una condizione specifica dal suo genitore che sto cercando di trovare un modo elegante per implementarlo.

Entrambe le classi che implementano questa interfaccia capita di utilizzare un identificatore GUID al momento, ma non c'è alcun motivo intrinseco per cui questo dovrebbe essere il caso e potrebbe essere soggetto a modifiche; le due classi non hanno realmente nulla in comune oltre a essere predicati.

Una possibile soluzione potrebbe essere quella di sovrascrivere il metodo Equals nelle classi e restituire true quando viene passato l'ID. Tuttavia, per me, questo sembra non essere perfettamente in linea con l'intento del metodo e viola il principio del minimo stupore.

Un'altra soluzione potrebbe essere creare un'interfaccia IIdentifiable con un metodo, IdentifiesAs quindi ereditare ICondition da esso. Tuttavia, sembra che vada contro lo SPI dell'ISP poiché qualsiasi implementatore di ICondition deve ora implementare anche IIdentifiable .

Qualcuno ha qualche indicazione per attenersi all'ISP pur essendo in grado di identificare univocamente un oggetto? Sto pensando troppo a questo?

c# architecture solid

posta TheCatWhisperer 14.05.2018 - 17:13

fonte

2 risposte

Leggi altre domande sui tag c# architecture solid

Devo duplicare il modello e il database dei dati master tra i servizi in microservice Prestazioni tollerate durante la generazione di un documento da SQL

score 3 · Answer 1

Supponendo di averti compreso, hai una situazione in cui: 1. Attualmente hai un paio di tipi che implementano IsConditionMet e IdentifiesAs . 2. In una situazione in cui, in futuro, potresti aver bisogno di tipi che implementano solo IsConditionMet .

Supponendo che sia corretto, quindi segui il principio YAGNI (non ne avrai bisogno): quando devi gestire i tipi che implementano solo IsConditionMet , gestisci quella situazione in quel momento.

Tuttavia, è possibile pianificare ciò senza creare codice non necessario ora: nomi validi.

Crea un tipo IIdentifiableCondition ora:

interface IIdentifiableCondition
{
    bool IsConditionMet(...);
    Guid IdentifiesAs { get; }
}

In futuro, quando avrai solo bisogno di IsConditionMet , aggiungi un'interfaccia genitore, quindi:

interface ICondition
{
    bool IsConditionMet(...);
}


interface IIdentifiableCondition : ICondition
{
    Guid IdentifiesAs { get; }
}

score 1 · Answer 2

Dai commenti al tuo post originale, è ovvio che il tuo ICondition deve essere qualificato dall'identificatore in una forma o nell'altra.

interface ICondition<ID> {
  ID GetId();
  bool IsConditionMet();
}

Ciò astrae la natura dell'ID e chiude il contratto che ICondition deve soddisfare: che entrambi indicano che la condizione è soddisfatta e che è in grado di identificarsi per una possibile rimozione.