c# - patterns - lista de antipatrones
¿Cuándo usas el reflejo? Patrones/antipatrones (17)
Entiendo la API de reflexión (en c #) pero no estoy seguro de en qué situación lo usaría. ¿Cuáles son algunos patrones: antipatrones para usar la reflexión?
+1 en el uso de patrones de fábrica: muy poderoso allí.
Aparte del patrón de fábrica, cada vez que lo he usado, probablemente no debería haber ...
Lo he usado para cargar dinámicamente las clases que implementan ciertas interfaces (las mías eran elementos de menú de ensamblajes) al inicio y realmente lamento ese uso. Desearía haber cargado desde un archivo de configuración (y más tarde agregué un formulario que mostraba las interfaces disponibles para cargar). Es genial, pero terriblemente lento ...
Un antipatrón es utilizar las propiedades de acceso que los diseñadores de clase marcaron como privados sin saber por qué los marcaron como privados. He hecho esto con el control DataGridView WinForms para desarmar una variable booleana para poder mover una columna "complementaria" cuando se movía su complemento. Una vez más, es genial, pero ese código fallará horriblemente si un nuevo lanzamiento cambia esa propiedad privada (muy bien podría desaparecer en 3.0 o 3.5 ...).
Considero que la reflexión (combinada con la carga de la clase en tiempo de ejecución) es indispensable para implementar complementos:
- buscar frascos / conjuntos en una ubicación conocida
- enumerar jarras / conjuntos para las clases que soportan la interfaz compatible con su complemento
- crear instancias del complemento en tiempo de ejecución
Cuando desee mejorar el rendimiento de los objetos con límite de tiempo. Puede emitir el código necesario para llamar directamente a los tipos encuadernados y luego llamar a través de su método emitido. Aunque no puede realizar llamadas tan rápido como con el enlace anticipado, tendrá un mejor rendimiento que el enlace tardío.
El único lugar donde he usado las cosas de Reflection en C # estaba en patrones de fábrica, donde estoy creando objetos (en mi caso, escuchas de red) basados en la información del archivo de configuración. El archivo de configuración proporcionó la ubicación de los ensamblajes, el nombre de los tipos dentro de ellos y cualquier argumento adicional necesario. La fábrica recogió esto y creó a los oyentes según eso.
El lugar principal en el que uso la reflexión: sacar un tipo de una base de datos.
Tengo una clase que necesita saber a qué biblioteca llamar. Tenga en cuenta que a medida que se agregan nuevas herramientas a la lista, la clase necesita reconocer las nuevas herramientas sin una recompilación, por lo que una declaración de cambio está descartada.
En cambio, almaceno la cadena de reflexión en el DB que le dice a la clase que "cree uno de estos ..." Como yo (el programador) siempre me aseguro de que la clase se deriva de una sola clase base, la idea funciona. Es limpio y eficiente.
Pero estoy de acuerdo en que si utiliza el reflejo para más de estos escenarios de "código generado automáticamente", entonces podría estarse abriendo camino a un mundo de dolor cuando se trata de mantener el código en el futuro.
(ingrese la voz del sabio, viejo sabio)
La reflexión viene con un poder increíble ... usa el poder con sabiduría.
En un producto en el que estoy trabajando lo usamos mucho, pero Reflection es una bestia compleja y lenta. No busque lugares para usar solo porque suena divertido o interesante. Lo usará cuando se encuentre con un problema que no se puede resolver de otra manera (cargar ensamblajes dinámicamente para plug ins o frameworks, inspección de ensamblaje, fábricas donde no se conocen los tipos en la compilación, etc.). Sin duda vale la pena mirar los tutoriales de reflexión para ver cómo funciona, pero no caiga en la trampa de "tener un martillo y todo lo que parece un clavo". Tiene casos de uso muy especializados.
Fui por 2 años de desarrollo sin entender el propósito de la reflexión. Tiene usos muy específicos, pero es extremadamente poderoso cuando es la herramienta adecuada para el trabajo.
Creo que lo que intento decir es usarlo solo cuando estés seguro de que es la única forma de lograr lo que quieres.
He usado la reflexión en varios lugares. Las principales categorías principales incluyen:
- GUI generadas automáticamente (es decir, un editor de propiedades). Puede recorrer las propiedades de un objeto y usar un registro de fábricas de elementos de interfaz de usuario para crear un formulario. Uso atributos en propiedades para guiar la creación de UI.
- Serialización He escrito frameworks de serialización, la reflexión de uso para serializar y deserializar objetos.
- Servicios web . Similar a la serialización, utilicé la reflexión para crear y consumir mensajes SOAP y también para generar WSDL.
- Idiomas específicos del dominio . Los lenguajes de scripting interpretados generalmente se unirán a los objetos y métodos mediante el uso de la reflexión.
- Herramientas de depuración Dichas herramientas pueden usar la reflexión para examinar el estado de un objeto. Útil para crear mensajes de registro en condiciones de falla.
En cuanto a los patrones, no estoy seguro de cuáles son los patrones. Un hilo común entre todos los usos es la referencia por nombre y enlace tardío: desea enlazar a un miembro en tiempo de ejecución. Este suele ser el caso cuando cargas dinámicamente ensamblajes y no conoces los tipos de objetos que necesitas crear / manipular.
Usar la reflexión es poderoso, pero no te hará más popular en las fiestas. Úselo únicamente cuando el acoplamiento sea intencionalmente débil. Tan débil que esperas que se rompa en tiempo de ejecución. Un gran ejemplo es el enlace de datos en WPF.
No estoy seguro acerca de los antipatrones, pero seguramente se relacionaría con hacer cosas en tiempo de ejecución que deberían hacerse en tiempo de compilación ...
La opción de reflexión le permite resolver problemas que, de lo contrario, le obligarían a duplicar el código. Si te encuentras copiando y pegando código, y no puedes ver cómo un patrón de OO puede ayudar, tal vez si puedes llamarlos, entonces el "equipo de r" puede ayudarte.
Solo bromeo. No pude entender el punto de reflexión por siglos. Si puede escribir código para realizar un trabajo, ¿por qué necesita usar el reflejo?
Supongamos que tiene muchos objetos de GUI como Forms u objetos ''table''. Se une a un objeto comercial como un Cliente:
public class Customer
{
public string FirstName;
public string LastName;
}
Sus usuarios no desean ver los encabezados de columna ''Nombre'' o ''Apellido''. Quieren ''Nombre Cristiano'' y Apellido. No desea codificar las cadenas literales en todos sus objetos GUI en caso de que cambien de opinión a ''First Name'' y ''Father''s last name'' (lo sé, ejemplo de mierda).
Si defines tu clase usando atributos:
public class Customer
{
[Description("Christian Name")]
public string FirstName;
[Description("Surname")]
public string LastName;
}
Puede usar la reflexión para sacar los nombres de las columnas. Si necesita cambiar la forma en que todos los objetos de su GUI describen el objeto del cliente, ahora lo hace en un solo lugar.
No estoy al tanto de ningún antipatrón. Mi consejo es saltar y probarlo. Comenzará a ver todo tipo de formas en que la reflexión le brinda una solución elegante. El rendimiento a menudo se cita como una razón para no usar la relización. Hay una sobrecarga de rendimiento con relfection, pero la descontaría a menos que puedas probar que la sobrecarga está dañando un algoritmo que necesitas.
Lo uso en un caso similar al mencionado por Harper Shelby, en el que un archivo de configuración especifica en tiempo de ejecución qué objeto crear. En mi caso particular, no hay nada más elaborado que una fábrica: solo un conjunto de clases que implementan una interfaz común y una función simple que lee el archivo de configuración y crea el objeto adecuado, devolviendo la interfaz.
Lo uso en un serializador binario ( protobuf-net ). Uso la reflexión solo para construir el modelo: cuando se usa (es decir, durante la [de] serialización), utiliza delegados, etc., para obtener el máximo rendimiento.
También lo usé (junto con ComponentModel y Reflection.Emit) en HyperDescriptor , para crear acceso de propiedad acelerado (~ 100x la velocidad de reflexión regular).
Y por necesidad, necesita usar la reflexión si está construyendo su propia Expression .
Lo uso más a menudo cuando necesito romper la encapsulación de otra persona (generalmente el marco). Es decir, necesito cambiar algún campo privado, o llamar a un método privado, o crear una instancia de alguna clase interna en una biblioteca que no tengo poder para cambiar. Un buen ejemplo es el código en mi respuesta a esta pregunta . En este caso, el comportamiento del método de framework ServiceBase.Run era inaceptable, así que usé el reflejo para hacer lo mismo que hace de una manera más aceptable.
Sin embargo, la reflexión tiene muchos otros usos, como el tipado de patos , el trabajo con attributes y el encuadernado tardío .
No hay una regla dura y rápida. Básicamente, no usas la reflexión sin una buena razón. Usa la reflexión cuando no puedas hacer lo que quieras sin ella, o cuando tu código sea mucho más largo o más difícil de entender sin reflexión.
No sé si es un patrón, pero utilizo la reflexión para generar SQL a partir de las definiciones de clases de DAO.
No voy a dejar caer ningún patrón, pero sugeriría que es una buena idea evitar el reflejo hasta que realmente lo necesite. Es especialmente útil para situaciones de interoperabilidad y extensibilidad donde no se puede controlar de antemano el tipo de objeto.
Personalmente no lo uso mucho. Tiendo a usarlo cuando no tengo una forma diferente de codificar algo.
Aquí hay un ejemplo simple:
public static void LogException(Exception exc, string source)
{
try
{
// Logic for logging exceptions
}
catch(Exception ex)
{
//If logging fails for some reason
//then we still log it using reflection
LogException(ex, "Error while logging an exception");
}
}
Utilizo la cantidad de reflejo en mis pruebas unitarias, especialmente cuando las cosas que estoy revisando son anónimas. También lo he usado como una forma de clonar / copiar fácilmente objetos modelo. En lugar de escribir el código para hacer esto para cada objeto modelo, puedo crear fácilmente un objeto de un tipo particular usando reflexión, interrogar las propiedades públicas del objeto entrante e invocar a los definidores sobre las propiedades correspondientes de los objetos clonados. También lo uso con clases generadas por diseñadores que implementan las mismas firmas de métodos, pero no tienen una interfaz asociada. En esos casos, puedo interrogar al objeto para ver si tiene el método requerido e invocarlo si lo hace. Las entidades LINQ2SQL son así, así que en mi contexto falso de datos, el método OnSubmit utilizo la reflexión para obtener el método OnValidate y lo invoco para la prueba unitaria.