Architettura ingannevole in C # che implica un'operazione simmetrica e una classe di visualizzazione

Sembra che il tuo metodo Foo non debba esistere nelle sottoclassi I .

Come hai detto, con il tuo approccio suggerito l'aggiunta di una nuova sottoclasse I viola il principio Open / Closed.

Invece, prova a spostare Foo in una nuova classe responsabile dell'operazione simmetrica

abstract class SymmetricalFoo<T,U>
    where T : I 
    where U : I
{
    public R Foo(T t, u u)
    {
        this.Bar(t, u);
    }
    public R Foo(U u, T u)
    {
        this.Bar(t, u);
    }
    protected abstract R Bar(T t, U u);
}

Implementa un% co_de concreto per ogni% di sottoclasse di SymmetricalFoo .

In questo modo quando aggiungi una nuova sottoclasse I non avrai bisogno di modificare le classi esistenti. Devi solo creare nuovi I s.

Come per la tua classe SymmetricalFoo . Questo va contro il mio odio generale per il modello ... ma penso che tu abbia bisogno di una Fabbrica astratta .

Passa due istanze di V sottoclassi alla fabbrica a ottieni il I appropriato come risultato.

Lascerò l'implementazione di quella factory (perché non mi piace scriverli!), ma probabilmente coinvolgerà la classe generica SymmetricalFoo a implementare un'interfaccia non generica SymmetricalFoo<T,U> .

Ciò che hai incontrato si chiama doppio invio e ciò che hai implementato è una forma di Pattern visore . Il problema che hai riscontrato è una delle limitazioni del pattern Visitor. Di solito devi scegliere tra ereditarietà e visitatore. Quando ne hai uno, rende l'altro più difficile. Il sistema di invio di tipo e metodo di C # non è abbastanza potente da supportare entrambi allo stesso tempo.

L'unica soluzione possibile è di rinunciare al controllo del compilatore se ogni coppia di possibilità è implementata e basta mantenere il dizionario dove i due tipi sono fondamentali e l'operazione è il valore. (è lo stesso di come lo state facendo nella vostra risposta, ma la vostra soluzione "nasconde" questo fatto). La fiducia, che tutte le permutazioni sono implementate, può essere riguadagnata se si scrive un test automatico, che verifica se tutte le permutazioni hanno un calcolo valido.

E direi che non è necessario unire i generici. Dovresti comunque convertire entrambi i valori in object tipo prima di passarli nella routine di doppia spedizione.

In realtà questo può essere risolto in modo relativamente semplice con il trucco di C # dell'utilizzo di dynamic per eseguire il doppio invio . Hai semplicemente bisogno di un metodo sulla classe base I come:

public R Foo(I i)
{
    return (i as dynamic).Foo(this as dynamic);
}

Il visualizzatore può chiamare questo, perché sa che ha un'istanza di I . Il trucco qui è che quando lanci in modalità dinamica, scegli sempre il sovraccarico appropriato per il tipo runtime dell'oggetto (vedi il link sopra se non è chiaro cosa significa).

Nota che questo risolve anche il tuo problema nell'aggiungere nuove classi. Supponiamo che tu abbia A , B , C , D e tu aggiungi E . E ha un override Foo esplicito per tutti i precedenti, ma nessuno di questi ha un override esplicito per E .

Ora fai:

I e == new E();
I a = new A();
a.Foo(e);

Questo chiamerà E.Foo(A a) . In alternativa, se lo fai:

e.Foo(a);

Questo chiamerà prima A.Foo(I i) (poiché non c'è A.Foo(E e) ). Quindi chiamerà E.Foo(A a) , che è lo stesso di sopra.

Come al solito con dynamic , i lati negativi sono:

• Perdita di sicurezza del tipo
• Prestazioni

Dato che lo stai utilizzando in tale un ambito specifico, direi che il primo punto è praticamente irrilevante qui. Non ti obbliga a usare dynamic da nessun'altra parte.

Quanto è importante la performance è da te trovare per il tuo codice specifico. Se questi metodi non vengono chiamati in un ciclo chiuso, è improbabile che importi, e se non sei sicuro, dovresti profilare.

Nota anche che se chiami questo per due classi in cui nessuno dei due può convertirsi all'altro, dovrai recitare all'infinito e traboccare lo stack!

Come dovresti implementarlo?

Dovresti adottare alcune convenzioni, come la classe fatta per ultime, ottenere l'implementazione del comportamento e l'altra semplicemente inoltra la chiamata. Idealmente, puoi implementarli come metodi statici in modo che un metodo e il suo mirror si trovino uno accanto all'altro nel codice.

Sì, questo significa che devi modificare il set quando sono espansi. Fastidioso, ma semplice da fare e improbabile che accada molto.

C # non può davvero forzare la simmetria in questo modo facilmente. La cosa migliore è semplicemente fare il codice e poi punire i programmatori che infrangono le regole.

Mi sono appena reso conto che C # ha% tipi di% co_de!

interface I
{
    int Precedence { get; }
}

class A : I
{
    public int Precedence { get { return 0; } }
    public R Foo(A a) { return ...; }
}

class B : I
{
    public int Precedence { get { return 1; } }
    public R Foo(A a) { return ...; }
    public R Foo(B b) { return ...; }
}

class C : I
{
    public int Precedence { get { return 2; } }
    public R Foo(A a) { return ...; }
    public R Foo(B b) { return ...; }
    public R Foo(C c) { return ...; }
}

class D : I
{
    public int Precedence { get { return 3; } }
    public R Foo(A a) { return ...; }
    public R Foo(B b) { return ...; }
    public R Foo(C c) { return ...; }
    public R Foo(D d) { return ...; }
}

using Microsoft.CSharp.RuntimeBinder;
class V
{
    public R Foo(I i1, I i2)
    {
        try 
        {
            if (i1.Precedence >= i2.Precedence)
                return DynamicFoo(i1, i2);
            return DynamicFoo(i2, i1);
        }
        catch (RuntimeBinderException)
        {
            return null;
        }
    }

    private R DynamicFoo(dynamic a, dynamic b)
    {
        return a.Foo(b);
    }
}

Qui usiamo la convenzione per cui qualsiasi classe con una precedenza di dynamic deve implementare n per tutte le classi con precedenza minore o uguale a Foo .

I problemi con questa soluzione sono che se vuoi implementare una nuova classe n devi sapere qual è il precedente valore di precedenza più alto (in questo caso 3), e l'utente deve capire la convenzione di precedenza nel primo posto. Potresti anche sostenere che il rilevamento di un'eccezione è un metodo inefficiente di rilevamento quando non esiste E , ma sembra un'ottimizzazione prematura.

Un esempio di implementazione di Foo :

class E : I
{
    public int Precedence { get { return 4; } }
    public R Foo(A a) { return ...; }
    public R Foo(B b) { return ...; }
    public R Foo(C c) { return ...; }
    public R Foo(D d) { return ...; }
    public R Foo(E e) { return ...; }
}