¿Cuál es la forma más intuitiva de pedir objetos en pares?

Question

Así que tengo que diseñar una clase que funcione en una colección de objetos emparejados. Hay una correspondencia de uno a uno entre los objetos. Espero que el cliente de la clase haya establecido esta asignación antes de usar mi clase.

Mi pregunta es ¿cuál es la mejor manera de permitir que el usuario de mi clase me dé esa información?

¿Es para pedir una colección de pares como esta?

MyClass(IEnumerable<KeyValuePair<Object, Object>> objects) 

O separadas colecciones de esta manera?

MyClass(IEnumberable<Object> x, IEnumerable<Object> y) 

¿O hay otra opción?

Me gusta la primera porque la relación es explícita, no me gusta por el trabajo adicional que realiza en el cliente.

Me gusta el segundo porque los tipos son más primitivos y requieren menos trabajo, no me gusta porque el mapeo no es explícito. Debo asumir que el orden es correcto.

Opiniones por favor?

Answer 1

En .NET 4 debería utilizar Tuple<T1,T2>. Más información sobre la clase Tuple en MSDN.

Answer 2

El primero es mi método preferido, ya que una secuencia puede ser más larga que la otra con la segunda, no mantiene la asignación necesaria 1: 1.

Answer 3

En mi opinión, la segunda opción le da a usted y al cliente más trabajo por hacer. La primera opción es más segura y más difícil equivocarse. Escogería la primera opción o algo así siempre.

Answer 4

Creo que tienes que ir con la opción 1. Deben existir relaciones explícitas o simplemente estás buscando problemas.

Answer 5

Si tiene acceso, use Tuple<T, R>. Si no lo hace, solo escriba una clase genérica de Tuple o Pair. Evitaría usar KeyValuePair, solo porque es detallado y tiene una asociación con Dictionary.

Answer 6

Preferiría KeyValuePair de los dos que menciona, ya que es más expresivo y mantiene la relación entre los objetos.

Pero prefiero crear una clase que tenga una referencia a su par. Esto es más legible en mi opinión, y nunca está de más crear una clase o estructura extra para expresar tus acciones reales.

(pseudo-código)

class MyPair 
{ 
    public TypeA One; 
    public TypeB Two; 
} 

MyClass(IEnumerable<MyPair> objects) 

hay mención de Tuple<,> en algunas respuestas, lo cual es lo más legible KeyValuePair, pero más flexible, ya que puede contener más de dos parámetros.

[Editar - más en profundidad sobre tuplas/clases después de una buena noche de sueño]

To Tuple or Not To Tuple

Answer 7

Usaría la segunda versión (porque es más simple) + comentarios + controles estáticos/dinámicos. Si puede usar contratos de código, intente asegurarse de que las colecciones sean de la misma longitud, no nulas. De lo contrario, haga lo mismo con Debug.Assert y if ... throw ArgumentException. Alternativamente, puede crear su propio objeto que contenga el par, pero luego se vuelve más difícil si desea usar genéricos para los miembros del par. Además, cuando crea un objeto que está destinado a almacenarse en un contenedor, debe implementar correctamente GetHashCode, Equals, etc. El primer libro "Effective C#" tiene un elemento sobre este.

Como regla general, prefiero no sobre-diseñar las firmas de métodos.

Answer 8

Normalmente proporciono ambos, con el constructor KeyValuePair delegando en el constructor 2-arg. Lo mejor de ambos mundos.

Answer 9

Preferiría la primera. Como dices, la correlación es explícita, y es menos propensa a errores que la segunda donde debes probar que ambas colecciones son de la misma longitud. Por supuesto, puede ser apropiado ofrecer/both/ways, dependiendo de la clase real que esté construyendo.

Una cosa, si usa .NET 4.0, recomendaría usar Tuple<T1, T2> en lugar de KeyValuePair.

Answer 10

Me gusta el primer método por dos razones.

1. si están almacenando sus relaciones en un diccionario <> objeto ya, que sólo puede mano del diccionario como es - sin código adicional requerido.

2. Si están utilizando su propio almacenamiento distinto entonces dar KeyValuePairs en un IEnumerable es muy fácil con la sentencia yield

Algo como esto:

IEnumerable<KeyValuePair<Object,Object>> GetMappedPairs() 
{ 
    foreach(var pair in _myCustomData) 
    { 
     yield return new KeyValuePair{Key = pair.ID, Value = pair.Data}; 
    } 
} 

opción número 2 no es Los desarrolladores que usan su método lo entienden fácilmente, por lo que requeriría documentación y comentarios para explicar cómo usarlo.

Por cierto, es probable que se sirve mejor al declarar su método como genérico en lugar de codificar duro KeyValuePair

MyClass<TKey,TValue>(IEnumerable<KeyValuePair<TKey,TValue>> pairs); 

Answer 11

Puede valer la pena considerar por qué se expone un enumerable en absoluto. Podría usar un método Add (Object a, Object b) que oculte completamente su forma interna de tratar con los pares. El cliente podría configurar sus propios medios para agregarle relaciones como conjuntos o individualmente.

Por supuesto, si todavía necesita un método para tomar un enumerable, entonces la primera opción es probablemente la mejor: una relación explícita. Pero considera usar o hacer un tipo Tuple o Pair para usar en lugar de KeyValuePair, suponiendo que la relación entre ellos no es de naturaleza Key to Value.

Answer 12

¿Y si hiciste algo como este?

// The client can choose to put together an IEnumerable<...> by hand...  
public MyClass(IEnumerable<KeyValuePair<object, object>> pairs) 
{ 
    // actual code that does something with the data pairs 
} 

// OR the client can pass whatever the heck he/she wants, as long as 
// some method for selecting the Xs and Ys from the enumerable data is provided. 
// (Sorry about the code mangling, by the way -- just avoiding overflow.) 
public static MyClass Create<T> 
(IEnumerable<T> source, Func<T, object> xSelector, Func<T, object> ySelector) 
{ 
    var pairs = source 
     .Select(
      val => new KeyValuePair<object, object>(
       xSelector(val), 
       ySelector(val) 
      ) 
     ); 

    return new MyClass(pairs); 
} 

Esto permitiría a los clientes escribir código como este:

// totally hypothetical example 
var stockReturns = StockReturns.Create(prices, p => p.Close, p => p.PrevClose);