¿Alternativas a una jerarquía de herencia profunda?

Question

Estoy intentando modelar productos con un conjunto de atributos integrales. Por lo general, una tienda en línea usaría una descripción de texto para enumerar los atributos de un producto específico. Sin embargo, esta solución no es óptima.

Por ejemplo, los siguientes enlaces muestran las inconsistencias de los atributos dentro de una descripción de texto para el mismo producto, pero con diferentes fabricantes:

• MSI GTX690
• Gigabyte GTX690
• ASUS GTX690

Por lo tanto, he optado por una jerarquía de herencia de la siguiente manera:

Product>Component>GraphicsCard>NvidiaGraphicsCard

La razón de esto es porque quiero un control preciso sobre los atributos de cada Product. Esto me permite incluir atributos específicos para decir un NvidiaGraphicsCard que no son aplicables a un ATiGraphicsCard.

Tenga en cuenta que, además de agregar más campos a las subclases, la herencia me permite hacer uso del polimorfismo en términos de tener un OrderItem mantener una referencia a Product. Esta es una razón por la que descarté la composición.

¿Existe algún problema para tener una jerarquía de herencia tan profunda y, de ser así, existen soluciones o patrones para solucionar este problema?

Answer 1

Las jerarquías de herencia profunda son problemáticas en el contexto de DDD y ORM por varias razones. Surge un problema cuando intenta definir la identidad de una entidad. Un Product debe ser comparable a otros productos en función de la identidad, independientemente de qué subclase se esté comparando. Esta funcionalidad se puede proporcionar en la clase Product, pero se debe tener cuidado para asegurar que también se puedan comparar las subclases y que haya algunos inconvenientes. Por ejemplo, NHibernate generará un proxy para las clases, de modo que el tipo de tiempo de ejecución real del objeto no sea NvidiaGraphicsCard, sino un proxy que herede de él. Mientras que una instancia transitoria de NvidiaGraphicsCard no será un proxy. Esto significa que no puede compararlos según el tipo.

Otra dificultad es configurar las correlaciones ORM para admitir la herencia. Si bien la mayoría de los ORM lo permite, la asignación resultante y los SQL generados a menudo son complejos. ¿Almacena todas las subclases en una sola tabla? ¿En varias tablas con claves externas a una tabla de producto común? En el primero terminas con una gran mesa. En este último caso, sus consultas sufrirán ya que todas las tablas de subclase deberán unirse. Hay demasiada falta de adecuación de impedancia entre el modelo relacional y el modelo de objetos. Evento si usa una base de datos documental, es mejor favorecer la composición que la herencia.

En su lugar, me gustaría tener una única clase Product, que puede estar compuesta por descriptores específicos del producto o un diccionario de atributos. Esto sería un OrderItem para hacer referencia a Product sin conocer el tipo específico de producto, no es necesario para el polimorfismo. Esto también haría más fácil permitir nuevos tipos de productos, no es necesario crear una nueva subclase.

Answer 2

Es un ejemplo de libro escolar de herencia, un buen ejemplo. No veo nada malo con dicho modelo, excepto que persistirlo en la base de datos relacional será difícil.

Por otro lado, a veces un grupo de propiedades solo es relevante para un subconjunto de elementos que no se pueden expresar a través de una herencia única. P.ej. PowerConsumption que describe la cantidad de energía que el producto necesita no es relevante para ratones y memorias USB. También el peso no es realmente importante para algunos componentes. Esto significa que puede investigar idiomas que tengan rasgos, como Scala, para que sus modelos sean lo más SECOS posible.

Tenga en cuenta que no existe una penalización de rendimiento de herencia profunda: una cadena de herencia más larga no significa llamadas de método virtual más lentas (bueno, no usará muchas llamadas virtuales ya que son solo contenedores de datos).

Answer 3

Le aconsejaría que observe el patrón Decorator. De esta manera tendrá la finura que necesite y menos de mil millones de clases.