Francisco, si mis contratos son Interfaces. El usuario solo recibe en el constructor la interface que puede usar...sea virtual o no la implementacion, no tengo de que preocuparme.
En general mi intencion es que cualquier metodo publico sea heredable de manera que pueda decorarlo con logging, transactions o lo que me interese. Por supuesto que usando AOP puedo evitar esta limitacion. Pero AOP por lastima no es inherente al framework, o sea que preferiria que o el Framework me de una manera sencilla de decorar, o por defecto me de la libertad de decorar, y no que me encuentre que cuando quiero agarrar el codigo de otro y hacer algo no puedo porque no marco nada virtual, y no es que no marco por versionado o porque queria sellar el metodo, sino que directamente no penso y uso lo que venia por defecto. Tanto tu argumento como el argumento de Carlos y por supuesto lo que entendio Dario al ver el post es valido, pero a mi gusto si bien quizas no genera mas problemas, al menos no genera menos que la decision de Java. Gustavo. 2009/1/14 Francisco A. Lozano <[email protected]> > > Sí hay buenos argumentos, lo que ocurre es que no son aplicables siempre. > > Norlamente es bueno fomentar la reutilización por composición y no por > herencia, y con el "final" por defecto puedes fomentarlo. Además, tus > contratos están más claros, menos sujetos a interpretación: si no pone > virtual, no está pensado para que sobre-escribas ese método. En java, > con la permisividad por defecto, ni dios pone "final" si no es que le > hace falta (porque algo se utilice en un inner class o cosas así). > > Lo que ocurre es que, a la hora de hacer "magias" (proxies y cosas > así), el tener que marcar como virtual es incoherente... porque aunque > tu código no sea consciente, estás heredando de tus clases... y te > toca marcarlo como virtual: Tu intención no es que cualquiera pueda > sobreescribir tus métodos, sino que a lo mejor (probablemente) tu > intención es que sólo el proxy del ORM (un elemento que yo > consideraría infraestructura y no parte del API de tu aplicación) > pueda sobre-escribir tus métodos. > > Francisco A. Lozano > > > On Wed, Jan 14, 2009 at 07:40, Gustavo Ringel <[email protected]> > wrote: > > > > Dario, no veo ninguna razon valida en el mail que mandaste, vos si? > > Es la escuela de siempre de Microsoft: Te damos esto para que no cometas > errores porque la mayoria de nuestros usuarios son estupidos. O sea que la > gente que si sabe cuando quiere virtual y cuando no tiene que sufrir. > > Porque no hacen todas las clases sealed tambien de entrada con ese > criterio? > > > > Gustavo. > > > > On Tue, Jan 13, 2009 at 11:47 PM, Dario Quintana < > [email protected]> wrote: > >> > >> Hola gente > >> > >> En realidad, por "algunas razones" no es virtual, me lo desayuné hace > algún tiempo en este link que me pasaron (en las listas del MUG): > >> http://www.artima.com/intv/nonvirtual.html > >> > >> Saludos > >> > >> On Tue, Jan 13, 2009 at 6:45 PM, Gustavo Ringel < > [email protected]> wrote: > >>> > >>> La respuesta te la diste vos mismo el castle dynamic proxy usa virtual > para lazy loading. > >>> Ahora te pregunto, la pregunta era solo informativa o hay algo que te > molesta? Simplemente si queres usar el dynamic proxy de Castle para lazy > loading tenes que usar virtual. > >>> Virtual es una palabrita magica y agradable que te permite aplicar > proxy, decorator, extender clases, testear...sin tener que cambiar > codigo...en el mundo de .NET por alguna razon no es el default, en Java todo > es virtual si no se dice lo contrario... > >>> > >>> Gustavo. > >> > >> -- > >> Dario Quintana > >> http://darioquintana.com.ar > >> > >> > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano -~----------~----~----~----~------~----~------~--~---
