sobre herencia multiple

11/04/2005 - 19:58 por olopeich | Informe spam
Epa!

Tengo un problema q no se como enfocar; es mas bien teorico, ahi va:

Tengo una aplicacion con clientes, cada cliente es un objeto con sus
propiedades metodos y tal.

En un momento dado tengo q representar esos clientes con un treeview. Lo
que hago es derivar una clase de TreeNode llamada mTreeNode donde añado
las propiedades que me interesan de la clase clientes; de este modo
cuando hago click en un nodo del arbol tengo acceso a todos los datos de
ese cliente, q visualizo o manipulo con ayuda de otros controles. Hasta
aqui vamos bien... o mejor dicho medio bien porque al no tener herencia
multiple (es la unica manera q se me ocurre de resolver el problema) no
puedo hacer un

class mTreenode
inherits Treenode, Clientes

.
.
.

End class

porque evidentemente mTreeNode tiene q heredar de Treenode, sino el
treeview peta. De esta guisa tengo q duplicar todo el codigo de clientes
en la clase mTreeView q me interese en vez de simplemente heredar.

Si mas adelante tengo otra representacion distinta de Cliente (yo q se,
con listbox por ejemplo) tengo q volver a hacer lo mismo: crear otra
clase que herede del tipo de dato que ese control pida y duplicar todo
el codigo de Cliente en esa clase.

Y digo yo: hay alguna manera mas elegante de resolver esto en vb .net???
me da la impresion de estar obviando algo muy basico pero no atino...

Saludos y mil gracias a todos.
 

Leer las respuestas

#1 Tristan
11/04/2005 - 21:33 | Informe spam
Bueno, en general la herencia múltiple no suele ser muy recomendable. Además
de los problemas que genera, en tu caso no vería mucho sentido en que un
objeto sea a la vez Cliente y TreeNode. Demasiado diferentes. Yo más bien
diria que tienes un objeto cliente que SE REPRESENTA mediante un TreeNode.
Es decir, tu objeto contiene, referencia, un objeto treenode.

Es decir, tu cliente puede crear en su constructor, o cuando sea necesario,
un objeto TreeNode, y puede visualizarlo dentro de un TreeView asociado.

Pero incluso este caso, estaría en contra de un diseño correcto en tres
capas, puesto que estarías uniendo capa de negocio y de interface en un
mismo objeto. Todo depende de que quieras seguir esas reglas de diseño. Pero
aplicando herencia múltiple aún sería mayor la infracción.

Por otro lado, no olvides que aunque .net no admite herencia múltiple de
implementación, si admite herencia múltiple de interface. Tu objeto puede
heredar de TreeNode e implementar la interface que necesite de Cliente.

Para mi, la mejor solución es o bien la que te dije al principio, o incluso
un diseño en que se separe negocio e interface. Una clase para
representación visual del cliente (heredada de TreeNode) y otra con las
reglas del cliente, que herede de la clase que necesites, tal vez Persona.

Juan Carlos Badiola
MVP - C#

Preguntas similares