martes 20 de febrero de 2007

Subclases

Hace unos días estaba en el trabajo escribiendo un caso de test (algo muy raro, aunque me gustaría hacerlo más seguido) y necesité dada una clase, obtener todas sus subclases.

Arranque buscando por la clase Class, y me encontré con que no existía ningún método que dada una clase, me responda todas las subclases. En ese momento me dije internamente, ¿Es posible que sea algo complejo obtener las subclases de una clase en Java?. Recuerdo que en Smalltalk bastaba con lo siguiente:

Después de buscar un poco por Internet, me di cuenta de que no es algo muy simple que digamos:

¿Será quizás esta simple pregunta un reflejo del poder reflexivo de Java?

6 comentarios:

Tomás dijo...

No recuerdo bien cómo era Smalltalk, pero creo que cuando deployabas, "cortabas" el árbol de clases para quedarte con las que necesitabas. De ahí que en runtime el intérprete (o equivalente) cargaba todas las clases.

En Java tenés la complicación de la máquina virtual, es decir, el proceso arranca y va cargando las clases "on demand" usando un class loader que busca en el classpath. Todos conocen lo ofuscado que es este mecanismo, pero la cuestión es que podés tener varios classloaders que busquen en diferentes classpaths, y no hay una manera directa de saber las subclases de una clase.

Lo que me imagino es que tu problema reside en algún test sobre el modelo de negocio. Un workaround fácil es usar el mapeo para pedirle todas las clases de negocio y con cada clase podés ver si son subclases de alguna en particular.

Slaudos!

Claudio Acciaresi dijo...

Gracias por el comentario!, entiendo lo que decís, pero que pasa si estoy en una etapa inicial del proyecto y todavía no tengo el mapeo realizado?

En Smalltalk, las clases son objetos y viven dentro de la imagen, en donde residen todos los otros objetos. En Smalltalk la diferenciación entre Runtime y Compile-time es muy pequeña, un método se compila cuando se guarda una modificación al mismo. Es como que estas en Runtime todo el día...

Entonces parecería que una posible (fea) solución al problema sería forzar la carga de las subclases de la clase que se va a utilizar?

BA Nigga dijo...

Hola Claudito!!!
Parece que estas extrañando a ST? jejeje... Este es uno de los tantos "pero si en ST es un simple mensaje? Por que en Java es todo complicado y la re:@#~$!!!" jejeje

Una vez tuvimos un problema simil y una solucion posible que surgio era recorrer el classpath para ver que clases tenes... bien hackeroso, pero bueh...

Bueno, master of the universe, te mando un abrazo y en breve me estaré comunicando contigo para arreglar un encuentro filosófico :P

PD: Aguante el abayarde!! Puñeta!!!!!!!

Claudio Acciaresi dijo...

Sr. Silva, a ud no le sucede lo mismo? O mejor dicho, por momentos no le pasa lo mismo, quiero decir.. que extraña...?

Mil gracias por el comentario!

Claudio dijo...

Como andás Claudito!
Mirá, La cuestión no tiene nada que ver ni con la VM ni con las diferencias entre Runtime y Programming/Compiling-Time. La cuestión es que en Smalltalk todo es un objeto, incluso las clases, y por ende todo comparte la maravillosa propiedad de ser SIMPLE. En Java las clases no son Objetos, son Clases. (Más allá de que existan Objetos de la clase Class, cuyas instancias representan a las clases y nos proveen de algo de reflection).
Verdolagas saludos,
Claudio

Claudio Acciaresi dijo...

Nooo! Cómo va Claudio!! Todo bien... ? Espero que sí!!! Mil gracias por el comentario!! Y sí coincido con vos con el tema de que todo es más simple, estaba pensando en escribir algo de eso...

Mil gracias por el comentario.
Saludos!