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

[mamcx]

Empezado por Al González

Agrego: En este par de artículos no se advierte sobre la supuesta prohibición de que una clase hoja "no debe" o "no puede" tener subclases.

No es una prohibición, es solo una recomendación. Nota ademas que en https://en.wikipedia.org/wiki/Leaf_c...er_programming) se marca el articulo como "Sin referencias ni fuentes" y como un "Stub = Incompleto". De solo mirarlo es claro que no es una fuente muy autoritaria sobre el tema.

La recomendación no tiene contexto, pero se deduce de la idea de que es preferible "composición sobre herencia", "plano sobre anidado" y simple y llano sentido común ("es mejor menos que mas!"), junto a "explicito sobre implicito". Si una clase no tiene subclases, porque no dejar eso claro? Aunque algunos lo usan como una tecnica de optimizaron, yo diria que es mas un asunto de hacer claro la intención: Porfa no hereden de esto, este es el final de esta rama del árbol.

Un sistema mejor estructurado (y si el lenguaje ayuda) se desliga de la idea de la OO "tradicional" y combina programacion por componentes , modulos, uso de POCO, funciones y estructuras/tuplas/arrays/listas/records o similar. La idea es que los OO son mas flexibles si se usan al estilo como el creador de smaltalk los visiono y que modernamente esta implementado el modelo de Actor.

Que es otra forma muy sofisticada de decir que es buena idea aplanar el arbol de herencia, pensar bien como se combinan las clases y usar funciones/datos (y tipos, si el lenguaje lo da) si es posible para reducir la necesidad de crear muchas clases.

Empezado por Al González

Por otra parte, en la POO moderna se ha venido usando la palabra sellada (sealed) para indicar el impedimento de derivación. Por lo tanto, creo que podemos ir acuñando ya una distinción clara entre lo que es clase hoja: que no tiene subclases, y una clase sellada: que no puede tener subclases. Vaya, en términos de reproducción, que no es lo mismo inmadurez que esterilidad.

Volviendo a "como nombro esto?"

Veo al buscar que es claro que un Leaf Class es una clase sin hijos. Lo de que "no deberia" es una recomendación de diseño, pero no altera que igual esta no tiene hijos. Si el codigo solo lo ve tu libreria da igual, pero si esto lo ve un programador X, creo que es mas claro decir "NoChilds" que "LeafClass". Nunca hay que dudar que la mayoria no esta empapado de la terminologia tecnica de todo esto.

No se como se llaman las otras clases (la de si tiene hijos y no se que mas) como para ver que "estilo" o tema tienes al nombrar las cosas, para mantener la simetria.

Puede ser ListLeafClasses o ListNoChildClasses...

P.D: Por otro lado, si la idea es tener una lista de clases, no veo porque hay que crear una clase que diga "esto es una lista de clases sin hijos". Me parece mas simple tener 1 funcion que me devuelva una Lista/Array y ya.

[[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...