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

[[Al González]]

Gracias, Mario.

Está claro todo lo que dices, si bien tengo algunas reservas. Pero qué bueno que vamos aclarando lo de la famosa prohibición: tienes razón, debemos tomarla más bien como una mera recomendación o idea de quienes escribieron eso. Esto me gusta porque se va asentando la diferencia entre clase hoja y clase sellada.

Mis clases y funciones (intento que esto forme parte de GH Freebrary), usan nombres cortos pero formales, empleando términos bien definidos o acuñados. Si bien tengo una larga lista de abreviaciones y no me gustan demasiado los artículos, las preposiciones y las negaciones en los identificadores, he de decir que trato de cuidar el orden, género, tiempo, número y persona de las palabras, acorde a la lengua de Mark Twain. El "ListLeafClasses" que sugieres sería más bien LeafClassList, contracción de leaf class list, que en castellano sería lista de clases hoja.

Volviendo a la justificación de crear la nueva clase. Primero diría que me resulta sumamente interesante crear una clase lista de clases "genérica" —con parámetro de tipo— derivada de la nativa TList genérica, la cual admita sólo clases de una rama en particular (los genéricos en Delphi lo simplifican mucho). Creo que sería útil en muchos casos, además de contar con algunos métodos auxiliares para el tratamiento específico de items clase.

Ahora, en esa misma clase lista podría incluir la funcionalidad de que sólo admita clases hojas. Pero estarás de acuerdo en que, si así fuera, tal característica tendría que ser opcional, y la clase estar preparada para trabajar (e incluso ajustar el contenido actual) según esa opción esté activa o no. Lo anterior pega directo en el punto que señalas de no hacer complejo lo que puede ser simple. Así que en lugar de agregar complejidad a una clase lista, agregándole esta funcionalidad extra opcional, mejor le derivo una subclase donde la funcionalidad quede circunscrita, llana, simple y con menos requerimientos de control. Cierto, no parece que vaya a haber muchos casos de uso, pero al menos yo ya tengo uno, y, como se trata de una biblioteca pública, puede que a alguien más le sirva luego también.

OK, queda la opción de ponerlo como una función suelta. Eso tendría la ventaja de poder operar con varios tipos de listas, pero creo que tendría yo que agregar código y validaciones adicionales para considerar particularidades de esas otras listas (más complejidad). Consideraciones que no tendría que tener con una lista cuyo comportamiento y datos estén perfectamente encapsulados (además hoy en día es trivial copiar el contenido de una lista a otra). Un argumento más a favor es que el método virtual Notify queda perfecto para hacer las revisiones necesarias, cada vez que se agregue una nueva clase a la lista.

Por los anteriores razonamientos es que le encuentro sentido a la lista especializada. Parece poca y rara cosa, pero queda bien en forma de clase de propósito específico.

Salvo que algo más me convenza de lo contrario...