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.