¿Cuáles son las ventajas y desventajas del Patrón de propiedades?

Question

Steve Yegge describe el Patrón de propiedades en un blog post de la suya.

Para alguien que usa un lenguaje estático como C# o Java, ¿cuáles son las ventajas y desventajas de este enfoque? ¿En qué tipo de proyectos desearía usar el Patrón de propiedades, y cuándo le gustaría evitarlo?

Answer 1

He estado profundizando un poco en este patrón últimamente y puedo decirles que encontrar información al respecto es bastante difícil. Yegge lo llama prototipo o propiedades, pero ambos están bastante sobreutilizados, y son bien conocidos como otros dos patrones diferentes. Algunas personas se refieren a sistemas como el que Yegge propone como "stringly [sic] tipeado", por lo que esa es otra vía de investigación.

Es una idea realmente clara, que tiene mucho mérito en algunas aplicaciones y muchas fallas en otras. Lo que obtienes es esencialmente un medio muy flexible de crear "tipos" en tiempo de ejecución, pero pierdes en muchos idiomas la comprobación de tipo fuerte para hacerlo. La forma más fácil de implementarlo sería como Dictionary<string,string>. Luego, debe usar los moldes para obtener los valores de las cuerdas como valores reales. La clave para mantener ese diseño manejable es nunca referenciar directamente una propiedad en el código si puede evitarlo. Cosas como theProtoObject["owner"] = "protoman" te matarán si cambia el nombre "canónico" de esa ranura. También puede dar lugar a problemas como JavaScript (que utiliza este patrón debajo como su modelo de objeto), donde si escribe mal el nombre de la clave, agregará un nuevo espacio.

Una mejora muy probable que probablemente harías en un sistema de producción es utilizar algún tipo de tipo especializado para valores, y algún tipo de "tecla pesada" para la clave, para que puedas obtener un poco de tipeo adicional y información de seguridad en su modelo.

He visto algunas aplicaciones que lo usan. Un ejemplo sorprendente me golpeó recientemente mientras buscaba código fuente abierto en mi industria: citas de seguros. OpenQuote es un proyecto muy flexible para cotizar seguros de cualquier tipo general. Está escrito en Java, pero si conoces C# debería leer bastante bien. En el corazón de ella, se encuentra el objeto Type, que contiene este fragmento de código:

/** A dynamic collection of attributes describing type */ 
private List<Attribute> attribute = new ArrayList<Attribute>(); 

Y lo que es un Attribute? Este:

* An attribute is defined as "One of numerous aspects, as of a subject". Generally, another 
* type will own a (composite) collection of Attributes which help describe it. 

Así que, básicamente Attribute es una especie de par clave-valor que contiene un identificador único de cadena (el nombre del campo) y un valor de cadena y una enumeración de tipos combinados con un poco de expresiones regulares para verificar y procesar los valores . De esta forma, puede almacenar valores de muchos tipos y convertirlos nuevamente en valores java, a la vez que proporciona un poco de seguridad.

A continuación, continúa la compilación de muchos tipos de modelos específicos de dominio sobre ese núcleo. Por lo tanto, un objeto de la póliza de seguro puede tratarse como si tuviera una lista flexible y extensible de beneficios, que puede agregarse, eliminarse o modificarse en tiempo de ejecución. Cada beneficio puede tener propiedades extendidas o reducidas en ellos también.

Este es un ejemplo del patrón en uso y un buen uso: las pólizas de seguro pueden ser muy flexibles, al antojo de los suscriptores hasta el momento de la venta, por lo que un modelo altamente flexible funciona bien para eso.

Las desventajas son más o menos lo que Yegge describe. El rendimiento puede ser malo, especialmente con una implementación ingenua. La verificación de tipo y la seguridad reciben un golpe, y sus objetos son más difíciles de razonar porque no se sabe con certeza qué propiedades tienen.

Answer 2

El patrón de propiedades es especialmente útil (o lo fue para mí) cuando desea crear prototipos de objetos o tiene una estructura de desarrollo que lo obliga a tener una implementación iterativa de su API/Interfaces.

Si empiezas con una idea de algunas propiedades de un objeto, entonces las haces. Más tarde encontrará (y ha anticipado este hallazgo ...) que su comprensión del tema no fue adecuada, usted hace un nuevo diseño/comportamiento basado en el prototipo del primer objeto. Etcétera. La página wiki sobre el tema tiene una muy buena descripción del tema en conjunción con los lenguajes estáticos, pero recomendaría que examinara JavaScript o Lua si está realmente serio con el desarrollo de prototipos. Las propiedades de los prototipos no se pueden modificar en los lenguajes tipados estáticos, y este hecho eventualmente los morderá en el camino.

Editar: Ah, y veo que se vincula a una excelente publicación sobre el tema. El uso/explicación de Yegges del sujeto, por supuesto, me deja en ridículo. Por favor, léalo un par de veces y las ventajas/implicaciones del uso del patrón de propiedades en un lenguaje como Java deben ser muy claras para usted.

Edit.2: enlace al artículo de Wikipedia: http://en.wikipedia.org/wiki/Prototype_pattern

Answer 3

Para alguien usando Java, mientras leía el artículo, yo diría que no se puede utilizar el patrón en Propiedades en cualquier proyectos, debido cita:

Java ofrece soporte esencialmente cero para el Patrón de propiedades.

Igual que para C# por las mismas razones. Me sentí un poco consolado cuando llegué a esa declaración, porque seguramente no estaba encontrando la manera de unirlos.

Así que no estoy seguro de entender su pregunta. Pero gracias por el enlace - votó la pregunta solo por eso. Ahora entiendo algunas cosas que medio intuí un poco mejor.