Alguien tiene alguna opinión sobre si o noIEquatable<T> oIComparable<T> generalmente debe requerir queT essealed (si es unclass)?

Esta pregunta se me ocurrió ya que estoy escribiendo un conjunto de clases básicas destinadas a ayudar en la implementación de clases inmutables. Parte de la funcionalidad que pretende proporcionar la clase base es la implementación automática de comparaciones de igualdad (utilizando los campos de la clase junto con atributos que se pueden aplicar a los campos para controlar las comparaciones de igualdad). Debería estar bastante bien cuando termine, estoy usando árboles de expresiones para crear dinámicamente una función de comparación compilada para cada uno.T, por lo que la función de comparación debe estar muy cerca del desempeño de una función de comparación de igualdad regular. (Estoy usando un diccionario inmutable tecleado enSystem.Type y vuelva a verificar el bloqueo para almacenar las funciones de comparación generadas de una manera que sea razonablemente eficaz)

Una cosa que ha surgido, sin embargo, es qué funciones usar para verificar la igualdad de los campos miembros. Mi intención inicial era comprobar si el tipo de campo de cada miembro (al que llamaréX) implementaIEquatable<X>. Sin embargo, después de pensarlo un poco, no creo que sea seguro usarlo a menos queX essealed. La razón es que siX no essealedNo puedo saber siX está delegando adecuadamente los controles de igualdad a un método virtual enX, permitiendo así que un subtipo anule la comparación de igualdad.

Esto luego plantea una pregunta más general: si un tipo no está sellado, ¿realmente debería implementar estas interfaces EN TODO? Pensaría que no, ya que argumentaría que el contrato de interfaces es para comparar entre dosX tipos, no dos tipos que pueden o no serX (aunque por supuesto deben serX o un subtipo).

¿Qué piensan ustedes? DeberíaIEquatable<T> yIComparable<T> ¿Se evitará para las clases sin sellar? (También me pregunto si hay una regla fxcop para esto)

Mi pensamiento actual es tener mi función de comparación generada solo para usoIEquatable<T> en los campos miembros cuyosT essealed, y en lugar de usar el virtualObject.Equals(Object obj) SiT no está sellado incluso siT implementosIEquatable<T>, ya que el campo potencialmente podría almacenar subtipos deT y dudo de la mayoría de las implementaciones deIEquatable<T> Están diseñados adecuadamente para la herencia.