È preferibile utilizzare per più valori di output o restituire un tipo di valore combinato?

Question

Per esempio, lungo le linee di:

public bool Intersect (Ray ray, out float distance, out Vector3 normal) 
{ 

} 

vs

public IntersectResult Intersect (Ray ray) 
{ 

} 

public class IntersectResult 
{ 
    public bool Intersects {get;set;} 
    public float Distance {get;set;} 
    public Vector3 Normal {get;set;} 
} 

Che è meglio sia per chiarezza, facilità d'uso, e soprattutto le prestazioni.

Answer 1

Vorrei utilizzare un tipo combinato.

Con un oggetto è possibile allegare il comportamento e restituire un oggetto arbitrariamente complesso. Potresti voler ridefinire il tuo metodo in futuro e modificare i valori di ritorno. Riempiendoli in un oggetto di ritorno e aggiungendo un comportamento a quell'oggetto, questo refactoring può diventare in gran parte trasparente.

È allettante usare tuple e simili. Tuttavia lo sforzo di refactoring diventa un mal di testa dopo un po '(sto parlando per esperienza qui, avendo appena fatto questo errore di nuovo)

Answer 2

È consigliabile restituire un tipo combinato. Per lo meno la firma del metodo è più pulita e il programmatore deve fare meno lavoro quando lo chiama. Ad esempio: non devi dichiarare e inizializzare le variabili, che ingombrano il codice chiamante.

Answer 3

È possibile utilizzare una tupla invece di creare la classe IntersectResult come alternativa.

Riferimento:

http://msdn.microsoft.com/en-us/library/system.tuple.aspx

Tuttavia, mi sarebbe sicuramente propendere verso la restituzione di un tipo complesso sopra fuori parametri.

Answer 4

Ciò dipende interamente da quanto coerente sia il concetto di IntersectResult.

Tecnicamente non c'è motivo di preferire uno rispetto all'altro.

Answer 5

Alcuni dicono che è una questione di preferenza, ma penso che restituire un oggetto complesso sia meglio non solo per chiarezza, ma anche per manutenzione.

Se è necessario aggiungere un altro bit di dati come output, è necessario modificare la firma del metodo oltre a aggiungere il codice per la risposta aggiuntiva; non così con un tipo di output complesso. Inoltre, è più difficile prendere in giro (per i test di unità) i parametri di output. Sembra anche rompere la filosofia "semplice": devi passare attraverso il problema di impostare i parametri di output quando hai bisogno di un solo pezzo di input. Il punto di forza di un linguaggio OOP è la creazione di tipi: seguire questa strada secondo me.

La differenza di prestazioni tra i due è trascurabile.

Answer 6

L'opzione 2 è probabilmente la soluzione migliore se cattura al meglio il tuo dominio. In questo caso il nuovo tipo verrà utilizzato in molti altri luoghi in quanto rappresenta un'entità logica.

Answer 7

Solo per la cronaca: E 'difficile trovare un buon esempio del trio magico (chiarezza, semplicità d'uso e prestazioni ).

Ovviamente il secondo esempio fornisce i primi due, mentre il primo fornisce prestazioni migliori. Se questo è trascurabile, non lo so. Forse fai un test di benchmark e scoprilo.

Quello che posso dire è che se si rende il tipo di risultato una struttura di piccole dimensioni, è comunque possibile salvare alcuni punti di prestazione, poiché l'allocazione nell'heap è più costosa rispetto allo stack. Ancora una volta, la copia dei dati da un tipo di valore può superare la penalità di allocazione dell'heap, ma forse non se la si mantiene abbastanza piccola. Inoltre, probabilmente vorrai rendere quel tipo immutabile.

Answer 8

avrei usato un tipo combinato e ti dirò perché: perché il calcolo di un valore dovrebbe restituire il valore, non mutare un gruppo di variabili. La modifica di un gruppo di variabili non viene ridimensionata una volta che ne è necessario più di uno modificato. Si supponga di voler un migliaio di queste cose:

IEnumerable<Ray> rays = GetAThousandRays(); 
var intersections = from ray in rays 
        where Intersect(ray, out distance, out normal) 
        orderby distance ... 

L'esecuzione della query è ora più volte mutando le stesse due variabili. Stai ordinando in base a un valore che viene modificato. Questo è un casino. Non fare domande che mutano le cose; è molto confuso.

Quello che vuoi è:

var intersections = from ray in rays 
        let intersection = Intersect(ray) 
        where intersection.Intersects 
        orderby intersection.Distance ... 

No mutazione; manipolare una sequenza di valori come valori non come variabili.

anche io sarei propenso a forse sbarazzarsi di quella bandiera booleano, e rendere il valore di una struct immutabile:

// returns null if there is no intersection 
Intersection? Intersect(Ray ray) { ... } 

struct Intersection 
{ 
    public double Distance { get; private set; } 
    public Vector3 Normal { get; private set; } 
    public Intersection(double distance, Vector3 normal) : this() 
    { 
     this.Normal = normal; 
     this.Distance = distance; 
    } 
}