Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - sapito169

#211
Java / Re: clases heredadas
6 Diciembre 2011, 23:02 PM
si pero jamas lo hagas eso es una de las peores "feture" de java  >:( cuando pasa eso inmediatamente deduce que el disño es muy malo

simplemente en la clase hija buelve a implementar la funcionalidad asi

class canino{
void rueda(){
//canino salvaje no obedece
ataca();
personamuere();
}
}

class pekines extends canino{

void rueda(){
ruedafelis();
seorinaenlaofombra();
}
}

ademas es recomendable que utilises la anotacion override asi


class pekines extends canino{

@override
void rueda(){
ruedafelis();
seorinaenlaofombra();
}
}


esa es la forma como trabajan casi todos (en realidad que usen poo es un milagro)

porfavor no lo agas la mayoria programan horrible cuando tengas clases parecidas que implementan los mismos metodos de formas diferentes creas una interfase con el metodo en comun luego haces que tus clases concretas implementen ese metodo yo voy aun mucho mas lejos e implemento una solucion mas "a la fuersa bruta" creo la interface luego una implementacion de una clase abstracta paraponer todos los metodos comunes a todas las implementaciones concretas y despues creo todas las implementacion heredando de la clase abstracta  :xD

y porfavor dinos los nombres de las clases es cuestion de vida o muerte todo puede fracasar horriblemente si lo haces mal (aunque no lo paresca) el diseño no tiene mucho que ver con complicados algritmos tiene que ver con la comunicacion y el lenguaje




#212
clases que implementan listener jamas por que expones funcionalidad interna es decir muestras lo que no debes a través de métodos publico que potencial mente serán llamados donde no corresponde

clases externas que implementen listener yo pienso que no es una buen idea por que lo que deberia ser externo y aparte es la acción que realiza el usuario que sea reutilizable por ejemplo si hariamos un sistema de edición de texto tendríamos crearDocumento importarDeWord importarDeXML confirmarCerrar que serian reutilisados desde los formularios así si presionas la x de la ventana ,si presionas escape  o presionas el botón cerrar rutilases confirmarCerrar que te abriria una ventana de confirmación pero este patrón introduciría a una explosión de clases que general mente no serian reutilisadas aparte de generar un poco de boilepart(el cual no es tan innecesario) así que creo que tendría mas sentido solo usarlo después de que exista la necesidad no desde el principio  otro razon para no usar este patrón extensivamente es que esos comportamientos ya estarían dentro de las clases servicios(ServicioImpresion,ServicioExportacion) y también en las de dominio


la otra opción es usar clases anónima internas son horribles gigantescas ensucian la pureza y la belleza de mi código y agrega muchas lineas de indentacion a mi clase aparte de que me obligan a que tengas mas de 300 lineas lo cual me produce un profundo vació en mi corazon y me da una sensacion de fracaso y depresión  :-[

aunque parezca raro yo prefiero la opción de la clase anónima interna aunque mi corazon sufra  :-[ debido a que sus desventajas son miles de veces menores que las desventajas de las otras 2 opciones

si soy un tonto perfeccionista y obsesionado con el código





#214
La utilidad seria auto documentación y facilidad de seguir evolucionando
En realidad la mitad de las clases solo serian gettes y setters y solo por ahora no harían prácticamente nada después serian extremadamente útiles
Vas a ver la utilidad cuando crezca el sistema y le agregues mas funcionalidad luego todos los comportamientos que tengan tus clases (que por ahora no hacen prácticamente nada)van a estar armoniosamente clasificadas y ordenadas dentro de cada clase que le corresponda
Créeme van a ver mas clases de las que te estas imaginando y se va a complicar mas de lo que quieras y además si logras hacer un buen trabajo el usuario le va a gustar mas y te va a pedir que le agregues más cosas más reportes mas ventanas y a la larga vas a ganar tener un proyecto ordenado

#215
La respuesta es sí y no

Tienes razón no servirían de mucho para este ejemplo y específicamente ese es el problema que no ves más allá del problema especifico : huh:

bueno te explico cuando alguien ve tu trabajo debe ser auto documentado si tu proyecto necesita de manera urgente documentación y necesita de manera urgente comentarios o que alguien te explique cómo funciona entonces significa que has hecho un mal trabajo y que as fracasado (si ya se soy muy perfeccionista) aunque funcione ese es mi punto de vista

Si alguien quiere saber de qué trata tu programa se preguntara que clases de dominio tienes pues simplemente vería el paquete que se llama dominio (no es obvio) y si alguien quiere saber dónde está la lógica del portero pues buscaría en el lugar menos pensado la clase portero  :xD y si alguien quisiera ver como son tus vistas pues o sorpresa tendrías un paquete vista y si alguien quisiera usar el formulario principal o sorpresa tienes la clase FrmPrincipal en el paquete vista


en tu caso tiene muy poco sentido por ser un problema trivial igual si quisieras ver que clases tienes pues siempre es casi idéntico que tus tablas las podrías ver en el ide de tu base de datos o en un conjunto de papeles sin sentido que te obligan a ser por costumbres que en el 20 por ciento de las veces es util y que jamás esta actualizado esos papelitos son conocidos como documentación consiste en una serie de dibujitos de monigotes y cajitas con un grado de detalle donde explican asta el ultimo if de tu aplicación con los monigotes y cajitas a esos papelitos se les conoces como binladen (todos an oido hablar de el pero nadie sabe donde esta) cuando por fin logran encontrarlo te das con la sorpresa de que es la versión del anteaño pasado


otro punto es que en tu caso tan simples como estos la mitad de tus clases no harían nada y solo tendrían getters y settes algunos asta se burlan y dicen que mejor pongas todo public(ese es tema para otro flame war)  :xD

bueno seguro estas pensando que te recomendaría que lo isieras a la mala sin clases ni nada es mas como supongo que eres principiante te demorarias muchisimo diseñando tus clases y tratando de entender como es eso de la oo pero yo te recomiendo que lo hicieras por lo que te conte de el codigo auto documentado recuerda que los sistemas crecen y evolucionan que no vas a ser el único que va a ver el código que es una manera de trabajar ya probada y que da buenos resultados y que todo el mundo con experiencia muy básica lo conocen recuerda que no todas tus clases van a ser como la del portero que solo tendría gettes y settes que luego habrían un montón de clases que no sean idénticas a tus tablas también recuerda que potencialmente tus clases podrían realizar acciones en tu caso no se luce pero en otros casos si  como en el caso de una clase factura tendría encapsulada el comportamiento para obtener cuanto es el monto total e impuesto encapsulada dentro de esa clase y no lo tendrías esos comportamientos desperdigados en 100 lugares diferentes por todo el código(todo ayudado por el maldito copia and paste que luego haría imposible optimización y mejoras)

otro tema es que no tienes asco para mostrar las entrañas de tu sistema por todas partes y no te preocupas del código duplicado tendrías tu sql como cadena(jamas uses cadenas son horribles no son type safe no hay ayuda del ide son propensas a errores) repetida por todas partes lo cual haría tu código difícil de entender digamos que quieres optimizar como realisas una consulta simplemente no se podría por que esa consulta estaría como cadena por todas partes(abusando del copy and paste) luego que pasa si quieres realizar una acción después o antes de hacer una consulta especifica pues no podrías por que esta desperdigada por 100 lugares diferentes

qué pasa si descubres que tu base de datos no es la mas adecuada para tus necesidades pues simplemente la cambias pero o sorpresa como esta como cadena por todas partes te das con la ingrata sorpresa que algunas consultas fallan por que no te diste cuenta de que algunas consultas varían de base de datos a base de datos y luego para corregirlo pues no puedes a menos que te pongas a verificar en los 100 lugares y comprobar una por caso por caso
#216
Tu avance para las corrección a qui no se hacen tareas
tu pregunta se parase a como debo clavar un clavo con el martillo de color rosado
o que se cómo se suma 1 manzana con otra manzana si me avían enseñado con peras
Hasta donde yo se se programa en el lenguaje java usando el lenguaje java  que yo sepa no existe otra manera de programar en java que no sea en java :huh:
#217
Java / Re: Duda Sobre .jar con conexión db mysql
11 Septiembre 2011, 21:23 PM
Bueno ahora que ago

Puedes seguir el camino mas fácil y hacerlo como te recomendaron poner un servidor de base de datos y cambiar la url en donde dice localhost pones el ip de la maquina en la red (muy aparte tienes que saber cómo configurar ips puertos y cortafuegos)

O puedes usar jpa hibernate con dervy in memory y dejar que el framework te haga todo
#218
Java / Re: Duda Sobre .jar con conexión db mysql
11 Septiembre 2011, 02:58 AM
Respuesta corta usa dervy en memoria

Para que no necesite ninguna configuración

Con mysql no a menos que encuentres alguna propiedad que diga crear en memoria

Si quieres trabajar sin tener que instalar bd a tener que utilizar dervy in memory con jar el dervy client con la url jdbc:dervy://localhost/memory:testdb;create=true

Pero esto tampoco basta una vez ya tienes la conexión de la base de datos en memoria tienes que ejecutar el script que te cree toda la base de datos junto con sus vistas tablas trigers procedimientos alamacenados funciones constraints jobs

pero eso todavia no basta tienes que asegurarte que el script de creación se ejecute una sola vez y se ejecute antes de que utilices alguna función de la base de datos como una consulta en una tabla(por que todavía no existiría)

Pero eso todavía no basta tienes que asegurarte de que el script de creación que has hecho para mysql sea compatible con el que isiste para dervy es decir tener las mismas tablas vistas procedimientos(con los mismos argumentos y con los mismos nombres) etc que crees consultas equivalentes muchas de las consultas en dervy no van a ser exactamente las mismas en dervy que en mysql(talves sin querer uses algo dependiente de mysql)

Pero eso todavía no basta tienes que asegurarte que crees un buena arquitectura donde separes la vista del acceso a datos(programar bien cosa que es rarísima) y tienes que saber a usar patrones como dao o tener barios archivos properites o xml donde este todo lo dependiente a la base de datos como los querys para la base de datos

pero eso todavía no basta si has leido todo y piensas en aserlo tu mismo y lo estas haciendo mientras lees deja de ser tan inocente y aprende a leer todo un texto completo y entiende que es mejor ser un vago y dejar que te haga todas las cosas que te dije arriba por un framework como la implementación de jpa con hibernate(el que recomiendo) en vez de tardar meses en crear las funcionalidades que describí y enzima comprobar que funcionen(la realidad es que aunque lo pruebes todo siempre te van a salir errores inesperados cuando juentes todo)

pero eso todavía no basta si finalmente tomaste la decisión menos inocente y dejaste a que hivernate te haga todo en vez de hacerlo por tu cuenta propia te darás cuenta que has tenido que leerte infinidad de tutoriales o algún libro o una infinidad de videos en youtube y al final tu aplicación apesta por que se pondrá extremadamente lenta porque te olvidas como configurar hibernate para que confuncione con el mejor rendimiento posible (varias configuraciones en su archivo de configuracion) usano por ejemplo cache indices vistas  

Y si finalmente logras entender todo lo que te dije te darás cuenta porque programar en java es horrible y por que hay pocos que realmente saben lo que hacen porque todos te piden que aprendas como 20 cosas que contienen j jpa jdbc jee ejb y ademas una infinidad de frameworks
Y si lo logras te darás cuenta que muy pocas personas se toma el tiempo en aprenderlas todas medianamente bien y que al final todo el tiempo que lograste ganar al final lo perdiste aprendiendo como usar la herramienta x y configurar todas las herramientas que usas (infinidad de gigantescos y horribles ficheros xml) y eso solo es en la parte de la persistencia el resto es peor

pdta no extoy molesto con nadie solo estoy exorcizando mis demonios internos
#219
Java / Re: JList como hago para..
19 Julio 2011, 23:14 PM
No te entiendo te funciona o no el código
Sabes manejar clases sabes escribir código dentro del constructor?
#220
Java / Re: JList como hago para..
18 Julio 2011, 00:52 AM
Eso tiene una solución la que todo programador promedio aria la mas común pero con el defecto de que no es java.util.list ni tampoco es type safe pero a su ves la mas fácil y la que no requiere librerías externas

Pues simplemente usa la clase defaultListModel


    1 DefaultListModel model = new DefaultListModel();
    2 list = new JList(model);
    3 for (int i = 0; i < 15; i++)
      model.addElement("Element " + i);

1 se crea un defaultlistmodel a partir de ahora llamado modelo esta es una lista que avisa a los cambios al jlist (la vista)
2 se crea un jlist que use la lista que creamos
3 ahora puedes modificar el modelo a tu antojo y mejicamente (la realidad es que deberías preguntarte como lo hace pero generalmente a nadie le importa conocer bien y a profundidad como funcionan las cosas) se actualizara en el formulario

-en primer lugar cuando un objeto avisa al resto de su estado para que se actualicen ese objeto es observable puedes conseguir ese mismo efecto de muchas formas la mas general es usando el patron observador

-te aviso que es una de las tantas cosas por la que swing apesta(esta es una de las menos graves) es por que no tiene una implementación de java.util.list que sea observable es decir que haga lo que tu dices

No dudes en preguntar criticar agradecer maletear o comenzar un flame si es necesario pero responde