Meter en una lista sólo las clases "punta" (descendientes sin hijas) de una jerarquía

[[Al González]]

Hola a todos.

Escribiendo un método, encontré que este necesita buscar en cierta colección de clases todas aquellas que desciendan, directa o indirectamente, de una clase en particular, y copiar éstas a una lista, pero solamente las que no tengan clases hijas.

Tomemos como ejemplo la siguiente jerarquía:

Código Delphi [-]
TA = Class
...
TB = Class (TA)
...
TC = Class (TA)
...
TD = Class (TC)
...
TE = Class (TC)

Me interesa poner en una lista sólo las clases TB, TD y TE. Esto porque, de todas las que derivan de TA, son las únicas que no tienen clases hijas. No hay más clases que deriven de TB, TD y TE, por tanto podemos decir que son clases "punta" o finales (end classes).

La implementación no tiene dificultades, pero es evidente que el proceso de búsqueda y selección podría quedar de mejor forma aislándolo en una clase o método creado especialmente para ello. Que disertemos sobre el diseño es lo que me interesa. De momento considero estas vías:

1. Definir una clase lista genérica, derivada de la TList genérica:

Código Delphi [-]
TEndClassList <TClassRef> = Class (TList <TClassRef>)
...

La cual tenga un método función Boolean llamado TryAdd:

Código Delphi [-]
If MiListaDeFinales.TryAdd (Clase) Then

El cual haría lo siguiente:
1.1 Verificar si la lista contiene una clase ancestro del parámetro Clase, en cuyo caso lo quitaría de la lista antes de agregar Clase (porque Clase está más abajo que su ancestro).
1.2 Verificar si la lista contiene una clase descendiente del parámetro Clase, y sólo en caso de no haberla agregar Clase.

2. Definir en una clase lista de clases general ya existente un nuevo método que haga la operación descrita en la opción 1.

Código Delphi [-]
MiListaDeClases.TryAddEnd (ClaseBase, Clase);  // O TipoReferenciaDeClase en lugar de ClaseBase

3. Un nuevo método en la colección original (la que contiene el universo de clases) encargado de "exponer" las clases finales que cumplan con el criterio antes explicado. Es decir, que en lugar de colocar la característica en el lado del receptor (la lista que alojará las clases finales), ésta quede en el lado del "emisor".

4. Dado que la funcionalidad de buscar clases finales podría requerirse para copiar de cualquier tipo de colección origen que contenga clases hacia cualquier tipo de lista destino que contenga clases, dicha funcionalidad podría implementarse mejor en una función o clase intermediaria (proxy). Haciendo enumeración en el origen para guardar las clases seleccionadas en el destino.

Bueno, espero haber sido claro. Someto a su consideración el planteamiento completo a fin de diseñar una buena solución para esta necesidad.

Un cordial saludo.

Al González.

[[Al González]]

Hola amigos, no siempre escribo con tinta blanca.

Decidí por la opción 1, una clase lista especializada (lo de "genérica" era porque admite parámetro de tipo), de nombre tentativo TghLeafClassList. Analizando los demás caminos, descubro que todos ellos podrían apoyarse en ésta. Es decir, que esta clase especializada tendría un funcionamiento básico para apoyar soluciones más elaboradas

También recordé que uno de los términos usados para referirnos a esta categoría de clases es clase hoja (leaf class), por la semejanza que hay entre una jerarquía de clases y las ramas de un árbol. De éstas últimas pueden nacer otras ramas y de las últimas ramas nacer hojas. Sin embargo, queda la duda de si es incorrecto llamarles así a las clases que no tienen hijas, pero de las cuales sí hay libertad para derivar subclases: no me convence del todo la sentencia en Wikipedia de "no debería". ¿Ustedes qué opinan?

Un cordial saludo.

[mamcx]

La razón de que "no debería" es debido al problema que se da en los códigos OO. Es un Code Smell.


"Plano es mejor que anidado". Es una (posible) falla de diseño el tener una jerarquia muy profunda. Es reconocido ahora que es mejor componer que heredar en la OO (y en general). Asi que la existencia de clases hoja puede indicar que es momento de "cerrar" la profundidad y dejar de que crear tanta subclase.

La OO es un arbol. Mientras mas grande y profundo, mas complejo y fragil. Mientras mas aplanado, mejor.

Pero eso es una idea para quien genera clases y quiere evitar una "explosion de clases". Cada nueva clase genera un crecimiento en la complejidad y eso hay que evitarlo.

Pero si estas haciendo introspección, el que esten "mal" o "bien" las clases es irrelevante. Tu tarea es analizar lo que hay, no criticarlo

P.D: Porque quieres hacer algo tan raro?

P.D.2: Te puede interesar mucho leer esta presentacion:

http://www.slideshare.net/ScottWlasc...s-buildstufflt

Tambien aqui se muestra que los patrones de diseño en OO son basicamente deficiencias de los lenguajes (en su implementacion de la OO):

http://www.norvig.com/design-pattern...n-patterns.pdf

[[Al González]]

Hola Mario, muchas gracias por tomarte el tiempo para responder e iniciar la retroalimentación.

No había visto esa lista de recomendaciones de Jeff Atwood, pero le encuentro mucho valor. En general, y desde mi opinión, creo que son consideraciones que debemos tener presentes quienes nos dedicamos a diseñar y escribir código, y en mayor medida los programadores bibliotecarios.

La duda con la definición de Wikipedia es por lo laxo de que no debería. El artículo en inglés es actualmente escueto y el de la versión en español es prácticamente una calca del primero. Varios artículos sobre UML asientan lo anterior, eso le da un poco más de peso. Suponiendo que demos por asentada la restricción, ¿cómo podríamos llamar a las clases que no tienen subclases (descendientes) pero que sí pueden en determinado momento llegar a tenerlas? Es decir, cuando no existe tal prohibición, ¿end class?

Como habrás visto, una de las cosas que cuido mucho son los nombres que le doy a los elementos de programa, y básicamente debo decidir si será o no adecuado llamarle a mi clase LeafClassList considerando que las clases contenidas no necesariamente estarán selladas para derivación. ¿Será mejor EndClassList? Esa es mi principal duda ahora.

De cualquier forma, esto se mantiene abierto a todo tipo de sugerencias constructivas.

Saludos.

[mamcx]

Bueno, el punto es combatir la suposición que la solución a un problema es "hacer mas clases". Es mejor hacer menos que mas! = hacer lo justo.

Empezado por Al González

debo decidir si será o no adecuado llamarle a mi clase LeafClassList considerando que las clases contenidas no necesariamente estarán selladas para derivación. ¿Será mejor EndClassList? Esa es mi principal duda ahora.

Sigo sin entender para que haces eso, pero te digo que ha pesar de saber un monton de Technobabble yo no sabria que rayos es un LeafClass al solo verlo.

Asi que diria que seria mejor que la funcion/clase se llame : XXXSinSubclases

[[Al González]]

Gracias, compañero. Estoy de acuerdo en que hay que hacer lo justo, y a veces lo justo es crear una clase. El asunto es que el término leaf class es algo que ya se usa bastante, el problema es el acotamiento mencionado en las definiciones encontradas.

Por otro lado, imagina que vas a crear esta clase. ¿Qué nombre le darías en inglés?

Explicar el origen de esta necesidad ameritaría abrir otro hilo, y quizá lo termine haciendo. Pero creo que un planteamiento en los foros es válido mientras esté mínimamente contextualizado (y creo que este lo está). Acá tengo la necesidad de conocer las clases "finales"/"hoja" de cierta jerarquía (que se encuentra en otra lista sin un orden definido), y preveo que esta necesidad puede darse con otro caso después, donde el origen no sea necesariamente otra lista (sin caer en la generalidad especulativa ). El proceso es fácil y ya lo tengo implementado, pero me inclino a pensar que agregar de forma selectiva a una lista de clases se termina convirtiendo en un objeto lista de clases selectiva, donde dicha selectividad esté definida en la propia clase del objeto.