Quando si usano i generici per entrambi i tipi di ingresso e di uscita, perché il tipo di uscita generalmente dura?

Question

Quando si usano i generici per entrambi i tipi di ingresso e di uscita, perché il tipo di uscita generalmente dura?

#1 da (6 voti)

4

Questa è una domanda soggettiva, suppongo, ma speravo in opinioni su entrambi i lati dell'argomento.

Quindi prendi questo ad esempio in C #:

public interface IFactory<Tin, Tout> : IFactory
{
    Tout Create(Tin param);
}

Ora come puoi vedere prendiamo un tipo di input e un tipo di output, tuttavia molti framework hanno spesso una serie di generici diversi in questi casi in cui spesso si finisce per avere TinOne , TinTwo ecc. far fronte a più casi d'uso. Quindi, anche nel sorgente C # generalmente fa <all input types, output type> tuttavia quando si va effettivamente a guardare le implementazioni di interfacce come questa, generalmente (di nuovo soggettivo) si vuole sapere qual è il tipo di ritorno, dato che spesso è il contratto a cui tieni circa per il resto del programma, quindi spesso rende più difficile trovare queste interfacce nel codice a causa del tipo di output che è l'ultimo nella lista non prima.

Quindi, perché è stato adottato questo approccio? come personalmente troverei che l'output sia in primo luogo più logico, ma sono sicuro che c'è una buona ragione per cui.

c# generics

posta Grofit 02.12.2016 - 10:33

fonte

1 risposta

Leggi altre domande sui tag c# generics

Pattern generico di repository + EF e unità di lavoro Vale la pena considerare lo schema di stato in questo caso

score 6 · Accepted Answer

Questo è il modo in cui i tipi di funzione sono normalmente scritti:

a → b

è una funzione che accetta a e restituisce b .

(a, b) → c

è una funzione che prende una tupla di (a, b) e restituisce un c .

a → b → c

è una funzione che accetta un a e restituisce una funzione che prende un b e restituisce un c (che è la versione al curry della seconda funzione sopra).

In tutti questi casi, gli input vengono prima, quindi l'output. E ha senso: i dati fluiscono da input a output, i tipi fluiscono da input a input a output e vengono letti da sinistra a destra.

Corrisponde anche alle dichiarazioni per i prototipi di subroutine in molte lingue. Per esempio. Scala:

// method:
def add(a: Int, b: Int): Int

// function:
(a: Int, b: Int) ⇒ { //body of the function, return type is inferred }

Go:

func add(a int, b int) int

Haskell:

add :: (Int, Int) → Int
-- or more idiomatically:
add :: Int → Int → Int

E così via.