style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

Es String o es Int

Necesito algo así y no se me ocurre como

String ="juan";
int edad = 20;

if(si es un string){

{
sentencia

}
if(si es un int){
sentencias
}

A ver si me dan una idea por donde buscar o algun ejemplo.

Saludos.

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.

Puedes usar instanceOf pero

Puedes usar instanceOf pero seguramente se te empezará a llenar tu código de if's así..

Podrías usar polimorfismo y dejar que el tipo de dato decida el camino.

Por cierto para el "instanceOf" tienes que usar un objeto, no funciona con primitivos.

Sería algo como:

public void decide( Object value  ) {
   if( value instanceof String ) {
       out.pritln("Fue un string");
   } else if( value instanceof Integer ) {
       out.println("Fue un entero");
  }
}

Pero de nuevo debe de haber una mejor opción dependiendo de lo que intentes hacer.

Imagen de ezamudio

qué cosa?

pero qué cosa es un String o un int? o estás preguntando por instanceof?

Object x; //llega de algun lado
if (x instanceof String) {
  ((String)x).length();
} else if (x instanceof Integer) {
  ((Integer)x).intValue();
}

No puedes preguntar directamente si algo es un int porque int es un tipo primitivo.

Aqui va lo que intento hacer espero las criticas

Mi codigo para criticas

//Armando mi acceso a datos

package manager.empaque.model;

import java.util.Vector;

import manager.empaque.domain.Recepcion;

public class RecepcionModel {
       
        private String[] columna = {"rec_codigo","rec_folio","rec_hrini","rec_hrfin",
                                                                "rec_lote","rec_tabla","rec_peso","rec_supervisor",
                                                                "rec_jefe_cuadrilla","rec_hrentrada","rec_cua_salario",
                                                                "rec_fletero","rec_productore","rec_ruta"};
       
        private String tablaBD="recepciones";
        private Object[] array = new Object[14];

       
        //Como puedo pasar AQUI un objeto de cualquier clase y no solo de la clase Recepcion
        public void guardar(Recepcion recepcion){
                array[0]=recepcion.getCodigo();
                array[1]=recepcion.getFolio();
                array[2]=recepcion.getHrInicio();
                array[3]=recepcion.getHrFin();
                array[4]=recepcion.getLote();
                array[5]=recepcion.getLabla();
                array[6]=recepcion.getPeso();
                array[7]=recepcion.getSupervisor();
                array[8]=recepcion.getCuadrilla();
                array[9]=recepcion.getHrEntrada();
                array[10]=recepcion.getSalario();
                array[11]=recepcion.getFletero().getCodigo();
                array[12]=recepcion.getProductor().getCodigo();
                array[13]=recepcion.getRuta().getCodigo();
                String sql="INSERT INTO "+tablaBD+" (";
                int len= columna.length;
                try {
                        for(int i = 0; i<len-1;i++){
                                sql=sql+columna[i]+",";
                        }
                        sql=sql+columna[len-1]+") VALUE(";
                        for(int i =0;i<len-1;i++){
                                if(array[i] instanceof String){
                                        System.out.println("soy string");
                                        sql=sql+"'"+array[i]+"'"+",";
                                }else{
                                        System.out.println("soy integer");
                                        sql=sql+array[i]+",";
                                }
                        }
                        if(array[len-1] instanceof String){
                                sql=sql+"'"+array[len-1]+"'"+",)";
                        }else{
                                sql=sql+array[len-1]+",)";
                        }
                        System.out.println();
                        System.out.println(sql);
                       
                        //ya que tengo la consulta armada puedo guardar, y solo cambio los valores y tamaños
                        //de array y columna

                } catch (Exception e) {
                        // TODO: handle exception
                }
        }

}

Imagen de ezamudio

Problema de fondo

Me parece que estás queriendo hacer tu propio ORM. A menos que seas uno de esos fanáticos anti-frameworks y anti-DRY, te recomiendo que mejor revises opciones como iBatis o Hibernate. Ambos están bastante maduros, bastante avanzados, y si tienes tu clase Recepcion o cualquier otra clase de dominio (o sea que la clase se mapea con una tabla o varias), puedes reducir todo ese código que tienes ahí a algo como esto:

Session session = bla;//obtener una sesión de Hibenate
session.save(recepcion);
session.flush();

Ahhhh el cláaaaaasico. :) :)

Ahhhh el cláaaaaasico.

:) :)

Lee esto:

http://www.javamexico.org/foros/java_standard_edition/formato_de_fecha_v...

Y vuelvelo a leer hasta que te digas a ti mismo: Ok, voy a usar el prepared statement

Luego utiliza preparedStatement.setXyz( index, value );

O yaaaa en última instancia:

preparedStatement.setObject( index, value );

No construyas el string tu mismo.

En realidad no necesariamente

En realidad no necesariamente escribir JDBC implica querer hacer un ORM, a veces dependiendo de la complejidad del problema se puede usar un TransactionScript ( es por ejemplo lo que usa StackOveflow dado el volumen )

Sin embargo lo que si está mal, es querer hacer lo que el driver de JDBC ya hace muy bien, que es crear el SQL correcto dandole formato a las fechas, numeros, strings y demás.

Ejemplo:

PreparedStatement pstmt = connection.prepareStatement("INSERT INTO TABLE ( FECHA, CANTIDAD, DESCRIPTION ) values ( ?, ? , ? )");
pstmt.setTime( 1, aDate );
pstmt.setInt( 2, anInt );
pstmt.setString( 3 , aString );

Y el driver hace lo correcto con cada uno.

Imagen de AlexSnake

Y una lista?

como pasarias una lista en el pstmt?

Ejemplo? Es decir como se

¿Por ejemplo? Es decir: ¿como se ve el SQL a insertar?

Si te refieres así como un "select in " yo llegué a hacer algo como esto:

StringBuilder b = new StringBuilder("SELECT x FROM whatever WHERE id in ( ");

// Crear un ?  por cada elemento
for( int id :  lista ) {
    b.append("?, ");
}

// Borrar la última coma
b.deleteCharAt( b.lenght()  -1 );

// Cerrar el parentesis
b.append( ")" );

//Y luego

pstmt = connection.prepareStatement( b.toString() );

// Poner los valores.
int i = 1 ;
for( int id : lista ) {
  pstmt.setInt( i++, id );
}

...

O algo así era, hace años que no hago eso, pero funcionaba muy bien.

Se puede argumentar que se va a crear un pstmt por cada combinacion, pero a favor diré en la aplicación habrá un número finito de combinaciones y habrá en el peor de los casos N pstmt, que pueden ser reutilizados por el RDBMS, por otro lado usar un statement simple involucra que el RDBMS va a "1.- parsearlo, 2.- Validarlo , 3.- Ejecutarlo" siempre. Y con el pstmt el día que se vuelva a dar la combinación .. se evita el paso 1.

Imagen de AlexSnake

OK

Exacto a eso me referia. grax.

Imagen de ezamudio

Por qué

Aquí un ejemplo de por qué es importante usar PreparedStatements. La inyección de SQL es un peligro muy real.

Imagen de ezamudio

Oscar

Yo lo que entendí del código es que esta persona quiere hacer un generador de SQL para insertar cualquier objeto en su tabla correspondiente. Eso lo saqué del comentario del método guardar:

//Como puedo pasar AQUI un objeto de cualquier clase y no solo de la clase Recepcion

Eso me suena a que quiere hacer un ORM. Entiendo lo que dices y obviamente el primer paso sería simplemente arreglar su método para que use PreparedStatements, no concatene tanto, etc, pero eso no responde a la pregunta que puso en el comentario del método. Por eso me fui más allá y propuse una solución más a fondo, que es usar un ORM. Pero OK... nos podemos ir por una solución extremadamente rudimentaria y hacer nuestro propio ORM de petatiux, más o menos así:

//Aqui vamos a guardar la lista de columnas bajo el nombre de la clase correspondiente
Map<String, List<String>> cols;
//Aquí los nombres de las propiedades de cada clase
Map<String, List<String>> props;
//Aquí va el nombre de la tabla que corresponde a cada clase
Map<String, String> tablas;

//Eso se puede poblar así:
cols.put(Recepcion.class.getName(), Arrays.asList("rec_codigo","rec_folio","rec_hrini","rec_hrfin", etc);
props.put(Recepcion.class.getName(), Arrays.asList("getCodigo", "getFolio", "getHrInicio", "getHrFin", etc);
tablas.put(Recepcion.class.getName(), "recepciones"); //Que por cierto es "mala práctica" ponerle nombre en plural a las tablas. Es una entidad y por lo tanto debe ir en singular "recepcion"

public void guardar(Object obj) throws SQLException {
  //Obtenemos la tabla, las columnas y las propiedades
  String tabla = tablas.get(obj.getClass().getName());
  String _cols = cols.get(obj.getClass().getName());
  String _props = props.get(obj.getClass().getName());
  //Validamos nulos, etc, eso me lo salto qué hueva
  //...
  //Construimos el SQL
  StringBuilder sb = new StringBuilder("INSERT INTO ");
  StringBuilder vals = new StringBuilder(") VALUES (");
  sb.append(tabla).append(" (");
  //Pegamos las columnas
  for (String colname : _cols) {
    sb.append(colname);
    sb.append(',');
    vals.append("?,");
  }
  sb.deleteCharAt(sb.length()-1);
  vals.deleteCharAt(vals.length()-1);
  sb.append(vals);
  //Ahora lo interesante, hacer el statement
  PreparedStatement ps = conexion.prepareStatement(sb.toString());
  int idx = 1;
  for (String pname: _props) {
    //Hay como 40 excepciones que cachar aquí de reflection, me lo salto ahorita
    java.lang.reflect.Method m = obj.getClass().getMethod(pname);
    Object v = m.invoke(obj);
    if (v == null) {
      ps.setNull(idx++);
    } else {
      ps.setObject(idx++, v);
    }
  }
  conexion.executeUpdate(ps);
}

Ahí les dejo de tarea agregar un mapa adicional con los tipos SQL para columnas que los requieran (java.sql.Types).

Estaba intentando hacer un ORM entendible por mi

Leí un poco de hibernate y no cache mucho así que trate de hacer algo propio y que yo entendiera, gracias a sus comentarios estoy adquiriendo experiencias nuevas.

Muchas Gracias Saludos.

Si acepto cocolazos

Los de las tablas en plural es por que también estoy usando cakephp para un par de cosas con esta misma BD y en las convecniones de este framework esta usar nombres en plural.

Yeap, es como si la historia

Yeap, es como si la historia se repitiera.

Alguna vez hice lo mismo pero entonces Hibernate ni existía lo que había era Toplink y la licencia constaba una lana.

Lo que yo encontré en ese entonces es que era mejor recibir el query que podía ser optimizado por un DBA y yo buscar al vuelo los objetos.

No era tan malo como parecía.

Lo usé un buen rato para iniciar mis desarrollos en lo que la gente de otros equipos hacía todo el código de BD y demás.

También me servia de sustituto de visor de SQL, jejeje tampoco había SQuirreL ni nada de eso y como lo que me importaba era ver la conexión JDBC pues no tenía caso usar TOAD o SQLNavigator ni nada de eso.

Le pongo un snippet en unos minutos de como se veía eso ( y como creo que se vería hoy en día )

Imagen de ezamudio

Cayenne

Oscar (y cualquiera otra persona interesada), has visto Cayenne? Te recuerda algo?

Je je si.. demasiado

Je je si.. demasiado parecido.

Alguna vez evalue los 4, Toplink, Cayenne, Hibernate y EOModeler, eso fue eeeen... el 2005 quizá :-S

En ese entonces me gustó más Cayenne, pero terminamos usando ( y después arrepintiendonos ) por TopLink

:)

Imagen de Jvan

Apache DbUtils

Si no te quieres meter con un ORM como tal, revisa Apache DbUtils que te permite hacer algo similar, te ayuda con mucho de lo que quieres hacer, según recuerdo Spring tambien te da soporte para esto.

Como sea, revisa la documentación en el sitio de Apache, creo que no es algo tan difícil de comprender.

Después de una buena consulta

Después de una buena consulta a StackOverflow sobre como usar expresiones regulares, aquí va mi versión "actual" de algo que hice hace como 10 años y que quedo en el olvido.

En ese entonces, no había los muchos frameworks que hay ahora y yo recordaba el código mucho más extenso que este, pero con la experiencia y los cambios en Java esta versión ya no está tan horrible.

Un approach es como el que tiene Enrique hecho en 10 - 15 minutos, lo cual está super, pero conserva la desventaja del "mapeo" que en los ORM's es necesario; sino como XML, como annotations o en listas como lo muestra Enrique.

A mi nunca me gustó eso, pero es muy necesario de otra forma el ORM no puede general el query correcto.

Llendonos un paso más atrás, sin intentar Mapear un Objeto a una base de datos pseudo ( antes que nos caiga @Luxpes ) Relacional ( Por eso se llaman ORM's) , se puede hacer que le pasemos el objeto y el query que es exactamente como @Jvan dice con Apache DbUtils, Spring y creo que hasta Hibernate tiene soporte para algo así.

La idea es poder usar algo como esto:

    DbDao dao = new DbDao();
    Persona p = new Persona(1,"Oscar","Reyes", new Date());
    dao.update( p, "UPDATE OTRA_TABLA set nombre_empleado = :name , fecha_ingreso = :birthDate WHERE id_empleado = :id " );
    dao.insert( p, "INSERT INTO PERSONA values( :name  )" );
    dao.delete( p, "DELETE FROM una_mas WHERE fecha_nac = :birthDate");

Es decir pasarle el objeto y un SQL aribtrario e idealmente revisado por un DBA o que sé yo. Algo que pueda incluso copy/paste'tearse de la herramienta de SQL a Java, sin tener que romper muchas cosas. La "singularidad" está en usar una notacion :property para obtener el nombre del getter ( que por cierto, no estoy seguro sí así se usan parametros nombredos en SQL, pero algo así me arrojo Google )

El update quedaría así:

  public <T> void update( T t,  String updateStatement ) {
   Connection connection = null;
   PreparedStatement pstmt = null;
    try {  

      QueryAndMethods qam = getQueryAndMethodsFor( t, updateStatement );
      connection   = getConnection();
      pstmt = connection.prepareStatement( qam.getStatement() ); // setea el query
      setValuesInto( pstmt, t, qam ); // Setea los valores
      pstmt.executeUpdate();
      pstmt.close();
    } catch( Exception e ) {
      throw new RuntimeException( e );
    } finally {
        close( connection,  pstmt ); // cierre con seguridad
    }
  }

Es decir se construye un objeto QueryAndMethods que después contiene los getters y el query sustituyendo los :property por "?" para ser usado por el prepared statement.

El chiste para no estar buscando los métodos una y otra vez está en tener un cache ( un mapa ) relacionando el query con este objeto, así solamente se ejecuta una vez:

   // 100 caracteres para una declaración!!! Ya ves Java, por eso se quejan...
  private final static Map<String, QueryAndMethods> methodsForQuery = new HashMap<String,QueryAndMethods>();
  //
  //
  private <T> QueryAndMethods getQueryAndMethodsFor( T t, String statement )
  throws NoSuchMethodException {
      QueryAndMethods qam = methodsForQuery.get( statement );
      if( qam == null ) {
        methodsForQuery.put( statement, QueryAndMethods.createFrom( t.getClass() , statement ));
        qam = methodsForQuery.get( statement );
      }
      return qam;
  }

Si ya está, lo usamos si no lo creamos:

  // Este es el que hace la magia de las propiedades.
  private final static Pattern propertiesPattern = Pattern.compile(":([^,\\s]+)");

  public static QueryAndMethods createFrom( Class<?> theClass , String statementWithProperties )
  throws NoSuchMethodException {

        // Get the statement to use in a preparedStatement
        Matcher m = propertiesPattern.matcher( statementWithProperties );
        String statement = m.replaceAll( "?"); // le quita :name y le pone ?
        m.reset();

        // Get the getters to use
        List<Method> methods = new ArrayList<Method>();
        while( m.find() ) {
          // busca un método que se llame getName()
          methods.add( theClass.getMethod(getGetterFor( m.group( 1 ))));
        }
        return new QueryAndMethods( statement, Collections.unmodifiableList( methods ) );
 }

Y listo!! ya podemos hacer algo no tan complejo como un ORM, pero sí mucho más eficiente que crear el query el vuelo.

Por ejemplo en un minibeanchmark, ejecutando este método 10 millones de veces se ejecuto en ~8 segundos ( vs. ~2 la versión sin reflection ) usando la opción "java -server", no sé si la JVM se da cuenta que no uso el valor y lo quita en la optimización, espero que no.

Solamente se crean "3" objetos QueryAndMethods y claro, por cada uno solo hay una referencia a cada getter usado.

Salida:

$ javac -Xlint:unchecked -d .   DbDao.java ; time  java -server sqlbinder.DbDao
//
Returning: Statement=INSERT INTO PERSONA values( ?  ),
                      methods=[public java.lang.String sqlbinder.Persona.getName()]
//
Returning: Statement=UPDATE OTRA_TABLA set nombre_empleado = ? , fecha_ingreso = ? WHERE id_empleado = ? ,
    methods=[public java.lang.String sqlbinder.Persona.getName(),
        public java.util.Date sqlbinder.Persona.getBirthDate(),
        public int sqlbinder.Persona.getId()]
//
Returning: Statement=DELETE FROM una_mas WHERE fecha_nac = ?,
                     methods=[public java.util.Date sqlbinder.Persona.getBirthDate()]
//
real    0m7.375s
user    0m0.015s
sys     0m0.015s

Ahí les dejo el código por si alguien lo quiere probar en su base de datos, me dicen como les fue.

Se ve apantallador pero es extremadamente fácil ( cerca de 100 lineas sin comentarios ni bean de ejemplo )

https://gist.github.com/1007227

Imagen de ezamudio

el punto era...

El punto que quería ilustrar con mi ORM de petatiux, era que hay ciertos problemas que son complejos, punto. Un ORM es inherentemente complejo. Pero puede ser complejo por "debajo del cofre" y ofrecer una API inicialmente muy simple y que se vaya complicando conforme sea necesario... Esto por el comentario inicial de jamilMX cuando le sugerí Hibernate y dijo: "Leí un poco de hibernate y no cache mucho así que trate de hacer algo propio y que yo entendiera".

Así que en vez de leer algo de documentación, seguir un par de tutoriales, hacer unas pruebas, pelearse con la configuración inicial (siempre es una lata eso, con CUALQUIER framework; te peleas con la config al principio o después cuando quieres que se cambie algun parámetro que antes era automágico), en vez de trepar esa cumbre inicial para tener acceso finalmente a un framework bastante completo que resuelve tus problemas inmediatos y que está listo para resolver problemas que todavía ni tienes... no... mejor inventar el hilo negro y hacer tu propio ORM, qué tan difícil puede ser?.

Para tratar de ilustrar que no es simple, puse el código para insertar un objeto mapeado a una tabla. Cualquier Java Bean, mapeado a cualquier tabla, tal y como lo preguntaba en el comentario de su código: //Como puedo pasar AQUI un objeto de cualquier clase y no solo de la clase Recepcion.

Como yo lo veo, escribir código de ese tipo es un desperdicio de tiempo, porque ya hay cosas como Hibernate, Apache DbUtils, etc que ya lo hacen. Invertir tiempo en escribir ese tipo de código no es invertir tiempo, es desperdiciarlo, porque es tiempo que se puede usar en resolver los problemas de la aplicación que se está desarrollando, las cosas de la lógica de negocio, las pruebas necesarias, etc. Pero en vez de usar el tiempo en eso, se usa en escribir código de infraestructura, que no es simple, que no va a ser breve (mi método de inserción pinchurriento son 24 líneas, sin contar configuración y le faltan varias validaciones).

Saben lo que es la densidad de defectos? Es el número de defectos que se insertan por cada mil líneas de código tecleadas. Un buen programador puede tener una densidad de defectos de 60. Un programador promedio llega a 100. Eso significa que cada que tecleaste 10 líneas de código (efectivas, no contando una llave que cierra o una línea en blanco, etc), puedes estar seguro que tienes por ahí algún defecto: te falta un punto y coma, tienes una variable sin inicializar, o tienes algún defecto más grave, de esos que no salen en compilación, a veces ni en pruebas, sino hasta producción, porque solamente bajo ciertas circunstancias ocurre el problema.

Si mi densidad de defectos es de 50, entonces en esas 24 líneas de mi ejemplo de ORM de petatiux, es casi seguro que hay UN defecto. Y está super incompleto. Si vas a escribir tu propio ORM, y mide 500 líneas y tu densidad de defectos es de 60, entonces debe haber unos 30 defectos iniciales. Entonces, ¿para qué escribir ese código, cuando ya hay bibliotecas/frameworks que hacen lo mismo y mejor, porque ya fueron revisados una y otra vez y ya están mucho muy depurados?

Pero creo que se fueron por el lado de "ah pues yo lo haría de esta manera". No. La mejor manera es entrar a hibernate.org, ibatis.apache.org, http://commons.apache.org/dbutils/ y leer la documentación, hacer pruebas y elegir el que más convenga. ESO es invertir el tiempo, no estar escribiendo código de infraestructura tratando de reinventar el hilo negro.

Re: Aqui va lo que intento hacer espero las criticas

No has propado con PreparedStatement y un HashMap...El PreparedStatement para que te ayude con lo de SQL-Injection y el HashMap pues que te diga el tipo de dato que es, por ejemplo:

HashMap hashMap = new HashMap();
hashMap.add("nombre_de_la_columna", Tipo.getClass);

De ahí, creo que puedes para "librarte un poco" utilizar un método de los preparedstatements llamado setObject. O en todo caso tener un super switch en donde incluyas los diferentes tipos y aplicar según sea el caso un setInt o setDouble o setString...

Re: Problema de fondo

No necesariamente tiene que se un anti-frameworks o anti-DRY. Probablemente quiere hacerlo cómo un ejercicio, cómo lo estoy haciendo yo con el único fin de aprender bien lo que es la API de reflection.

Ahora, pues también está el otro lado que esté en una empresa donde pues no hay de otra y no eres quien decide que usar y por ejemplo un marco de trabajo de persistencia pues es algo a tomar en cuenta...Porqué de la mayoría de programadores un 80% te maneja bien SQL, pero sólo un 20% o 25% te maneja de manera aceptable un ORM for pros cómo los de Java que son muy flexibles PERO tienes que saber cómo usarlos (si, nada que ver con ActiveRecord u la implementación rara de Play! que se basa en hibernate sobre JPA) de lo contrario tendrás aplicaciones con persistencias lentas, por eso muchas empresas lo que hacen es usar algo "más estándar" y pasarse a consultas a más bajo nivel (que no de complejidad).

¿Qué no iBatis se murió?

Tenía entendido que ahora ya no existe iBatis, ahora creo que el "sucesor natural" de iBatis es MyBatis...Aunque creo que si vamos a MyBatis es viajar al pasado del XMLHell. Francamente creo que si se quiere aprender un ORM no hay cómo aprender JPA, simple facilito y la configuración la haces en la misma clase sin tener que crear otro archivo de configuración (o propiedades).

Hay que usar las mejores herramientas y practicar y practicar.

Je je espero que no lo digas po mí.

Pero si así fuera, diré que lo que yo escribí me tomó 1 hr ( + / - ) ( más el tiempo de investigación de la regexp en SO ) y solo el 3/4 más de texto que te tomó a ti escribir la otra versión + el rant.

No es mucho y hay un fondo de todo esto. Ahora le vienen a llamar "Katas" pero es algo que siempre ha existido:

Practicar en resolver un problema que ya está resuelto te ayuda a mejorar tus habilidades de programador!

Es por todos aceptado que la mejor de mejorar es practicar. Para la mayoría de las disciplinas esta claro como practicar, si eres deportista entrenas hasta el desmayo, si eres músico practicas y practicas hasta que te vuelvas loco, si eres actor o bailarín te ves en el espejo ¿Y si eres programador? ¿lees blogs?, ¿libros?, claro que sí, te dan fundamentos que son muy necesarios ( de la misma manera que un futbolista tiene que estudar sistemas de juego ) ayuda claro , pero ¿cuando prácticas tu disciplina?, definitivamente no debería de ser con el código que va a producción. Es claro, no hay nada en el mundo como la experiencia con un sistema real, NADA ENSEÑA MÁS QUE EL SISTEMA DE PRODUCCIÓN ESTE ABAJO y tu tengas que levantarlo, pero hasta los polis entrenan ( o deberían ) y una muy buena forma de entrenar para ser programador ( si no es que la mejor ), es programando algo que sepas de antemano como se resuelve.

No es lo mismo leer el código y decir, "ahh si , ajá, ya le entendí", que luego tomar el editor, ver la hoja en blanco y decir Achís.. ¿como era? y luego poner los dedos en el teclado y ver como empieza a salir el código de tus dedos, sin tener que estar viendo el javadoc ( Já y pensar que hay quién no lo ve pero porque no sabe ni que existe ) ni tener que estar dependiendo del IDE siempre.

Ahora, no creas que no entiendo tu punto. Hay que ser responsable y usar las mejores herramientas para cada situación, cuando no se hace puede ser por ignorancia o por necedad.

La ignorancia es más o menos salvable, todos somos ignorantes por naturaleza y con el tiempo se quita e idealmente siempre hay alguien que evite que nos lancemos al vacío. Pero cuando se es necio si hay problemas, porque no hay forma de hacer entrar en razón a un necio.

Solo un necio o un ignorante pondría código como el que aquí publicamos directo en producción ( y peor aún, tal y como está ) habiendo tantas y tan buenas herramientas. No hay que hacerlo, hay que dedicar un buen tiempo en aprender bien las herramientas que están a la mano.

Hay que practicar mucho para poder usar esas herramientas bien y cuando se necesita.

En resumen, haganos caso a Enrique y a mí :) :) No re-inventen el hilo negro en producción y dediquen tiempo para practicar su programación.

Imagen de ezamudio

coman frutas y verduras

Todo con exceso nada con medida

Re: Hay que usar las mejores herramientas y practicar y practica

Una cosa que pongo en cuestión:

En resumen, haganos caso a Enrique y a mí :) :) No re-inventen el hilo negro en producción y dediquen tiempo para practicar su programación.

Yo sé que pues utilizar un framework sea a nivel qué sea, nos ayudan con experiencias previas de otras personas que se toparon con problemas, que si no son iguales a los nuestros son parecidos. Y qué mejor que utilizar la experiencia de otras personas y nosotros pues ni nos despeinamos en manejar el bajo nivel (por ejemplo para hacer un ORM propio tendríamos que saber utilizar la API de reflection y tener bases sobre metaprogramación). Sin embargo a veces es interesante hacerlo con el fin de obtener un conocimiento que no se tiene (en mi caso estoy haciendo un ORM con reflection).

Otra cosa es lo que ya dije en un comentario en esta entrada, muchas veces en las empresas se dice: "Vamos a hacer aplicaciones Java con JDBC y JSP."...Y tú puedes pasarte las horas dando millones de argumentos porqué sería mejor utilizar Spring MVC, Hibernate y otros módulos de Spring; pero muchas veces te dicen: "Sí, pero tú si sabes eso; el problema es que cuando tenga que contratar a alguien más necesitaré que sea alguien con un perfil muy específico; en cambio JDBC y JSP son cosas base de Java, por lo que la mayoría de programadores Java debe saberlas...es más simple para mí"...y cómo tu jefe es quien paga.

En mi conclusión, el reinventar el hilo negro tiene sus altos y bajos. Para mí sirve para aprender cómo es que las cosas funcionan; es cómo si te dijera: "¿Para qué haces otro lenguaje de programación, siendo que hay miles allá afuera que ya hacen lo que el tuyo?"...Quizás lo hiciste por una necesidad tuya, o por querer aprender cómo funciona un compilador, una máquina virtual, etc. Ahora, no hay que querer reinventar el hilo negro en nuestro trabajo diario; que ya tenemos suficientes problemas con los bugs del sistema cómo para acarrear los de nuestros propios e inmaduros frameworks ;)

Imagen de ezamudio

katas

creo que Oscar ya dejó muy bien establecido el punto de las katas de software, ejercicios personales de programación donde puedes programar algo que existe, precisamente para aprender cómo funciona. Posteriormente puedes ver el código de lo que estás intentando copiar (a menos que estés tratando de copiar algo propietario). Son, efectivamente, muy buenas maneras de practicas y es muy bueno que lo hagan para aprender.

Los comentarios que he hecho muy particularmente en este foro, son por lo siguiente: Si se fijan, la pregunta inicial ni siquiera era de un ORM, era una pregunta muy básica de Java cuya respuesta era simplemente la palabra reservada instanceof. Pero luego salió a la luz la razón detrás de la pregunta y era hacer algo que se asemejaba a un ORM rústico. Y no tenía cara de ser algo para aprender a programar (al menos esa impresión me dio). Es confuso, tal vez inferí mal, porque pues la pregunta inicial es MUY básica y entonces podría ser un ejercicio escolar o alguien aceptó un proyecto que le está quedando grande o forma parte de un equipo de desarrollo donde ya tiene o quiere dar el paso a un nivel más avanzado pero en vez de irse por las piedritas se está queriendo aventar un gran brinco. Pero bueno, a mi simplemente me dio la impresión de que el programador que hizo la pregunta inicial y que posteriormente puso el código del INSERT que quiere hacer genérico, no lo está haciendo para aprender, sino por un encargo (de lo que sea). Si es código que va a llegar a un sistema en producción, sostengo todo lo que ya dije: no reinventar el hilo, utilizar frameworks de ser posible, etc. Si es un ejercicio de la escuela o personal para aprender a programar, adelante, ya pusimos algunos ejemplos aquí que pueden servir para aprender todavía más (ya después se me ocurrió que se puede usar una anotación como se hace con JPA, para decorar los getters indicando el nombre de la columna en base de datos y de paso el tipo SQL, y la clase se decora con una anotación que indique el nombre de la tabla).

En cuanto a los frameworks: entiendo que en muchos casos en empresas hay cierta oposición a adoptar algunos frameworks (o todos, cuando de plano sufren un grave caso de NIH). Como profesional del desarrollo de software uno puede presentar argumentos bastante válidos y ofrecer alternativas. No quieren usar Hibernate? OK, ni modo, pero eso no significa que la única otra opción es JDBC pelón; pueden usar JPA, es un estándar de JEE. O JDO, o pues ni modazo EJB 3.0... no quieren usar Play o Grails? OK pero eso no significa que usen JSP pelón; existe JSF que es otro de los estándares de JEE. Y así con varias cosas.

Imagen de luxspes

O puedes usar Spring JDBC, o Spring MVC

En cuanto a los frameworks: entiendo que en muchos casos en empresas hay cierta oposición a adoptar algunos frameworks (o todos, cuando de plano sufren un grave caso de NIH). Como profesional del desarrollo de software uno puede presentar argumentos bastante válidos y ofrecer alternativas. No quieren usar Hibernate? OK, ni modo, pero eso no significa que la única otra opción es JDBC pelón; pueden usar JPA, es un estándar de JEE. O JDO, o pues ni modazo EJB 3.0...

O tambien Spring-JDBC. Casi todos los casos en los que encuentro resistencia contra JPA o Hibernate, aceptan que se use Spring-JDBC.

no quieren usar Play o Grails? OK pero eso no significa que usen JSP pelón; existe JSF que es otro de los estándares de JEE. Y así con varias cosas

O Spring-MVC, puede que Play o Grails les parescan muy esotericos, pero Spring-MVC sigue siendo JSP (y puedes usarlo hasta con JDK 1.4 o mas antiguos)... o Weld, que tambien se integra (quiza hasta mejor) con JSP (aunque necesitas usar tomcat 6.0 y JDK 1.6 o superior).

Por otro lado, de usar JSP 2.0 pelon, a usar JSF 1.x, yo mejor me quedaba con JSP 2.0 pelon (disponible desde Tomcat 5.5), ya que JSP si tiene soporte para templating, y en cambio con JSF 1.x, si no te dejan usar tambien Facelets, entraras en un mundo de dolor interminable. En JSF 2.x, los Facelets ya estan integrados.

Imagen de bferro

A veces espantamos

Hay algo que a veces manifestamos de manera involuntaria cuando queremos introducir una nueva tecnología en el equipo de trabajo y dominamos muy bien esa tecnología. Ese algo es que "hablamos de más" y espantamos al que nos oye. Vendemos por ejemplo Spring y comenzamos a contar todo lo que ese marco de trabajo ofrece. El que nos oye y no lo conoce se espanta de inmediato y su respuesta es: too much complicated".
Como bien comenta @luxspes, no es necesario ofrecer todo y es mejor empezar ofreciendo poco a poco lo que ese marco de trabajo ofrece. No creo que sea complicado para alguien que ya maneja un diseño con servlets y jsp ofrecerle Spring MVC como una alternativa. Si se vende bien, pienso que en la mayoría de los casos se acepta. Si muchos problemas de JDBC se resuelven con Spring JDBC, conviene comenzar por ahí y no tratar de convencer con ORM que inicialmente puede ser engorroso, y que en ocasiones no es necesario, aunque nunca diría que sale sobrando, porque lo que no es necesario hoy, quizá mañana lo sea.
Nuestra pasión por lo que sabemos a veces nos traiciona.

Imagen de luxspes

Con paciencia y con calmita...

Hay algo que a veces manifestamos de manera involuntaria cuando queremos introducir una nueva tecnología en el equipo de trabajo y dominamos muy bien esa tecnología. Ese algo es que "hablamos de más" y espantamos al que nos oye. Vendemos por ejemplo Spring y comenzamos a contar todo lo que ese marco de trabajo ofrece. El que nos oye y no lo conoce se espanta de inmediato y su respuesta es: too much complicated".

Exacto, en ves de tratar de apantallar con todo lo que hace Spring-MVC, es mejor decir que "los controllers de Spring-MVC son como servlets, pero mas faciles de usar y de configurar" (ya me funciono una vez) y acontinuacion, mostrar un codigo implementado con servlets y otro con controllers, que deje ver los beneficios.

Lo mismo con los ORM vs JDBC. JPA e Hibernate ofrecen grandes beneficios, pero tambien un marco conceptual que, si no estas familiarizado con el, puede llevarte a rechazarlo. Spring-JDBC, en cambio, te permite seguir trabajando con tecnicas que hacen sentir comodos a programadores experimetnados en "JDBC Solito", y que les hace mucho mas comoda la vida. Es facil demostrar que Spring-JDBC permite hacer todo lo que JDBC un una fraccion de la complejidad, y sin tener que explicar cuestiones complejas.

(Diablos, mas posts en los que bferro y yo estamos de acuerdo... se ira a acabar el mundo? ;-) )

@luxspes cc: @bferro Siempre

@luxspes cc: @bferro Siempre han estado de acuerdo solo que hasta ahora lo empiezan a notar.

@wishmaster77 Si usaras Ryz en producción el día de hoy, YO mismo te daba un cozcorrón ( dalee... unos ... 4 años más )

Para no dejar en suposiciones

El código que he tirado aquí es para un proyecto laboral.
Un sistema de ABMC, pero en la marcha se me van ocurriendo cosas como lo del ORM, por ahora el proyecto no usara ningun ORM petatiux, se ira a como me esta marcando el libro de howto program 7a edición que es mi refrencia, aunque esta en ingles y es un poco mas complicado leerlo, pero se va adquiriendo soltura con el tiempo.
Tampoco soy un programador java con años de experiencia, solo llevo leyendo, testeando, probando, etc.. 6 semanas.
Donde inicie con conocimiento nulo de java, lo de instanceof si algo muy básico pero cuando no se tiene experiencia en un lenguaje uno quiere hacer las cosas como en lenguajes que conoces(Yo vengo usando php "cakephp" y python).
Y la verdad me ha gustado mucho java.

Saludos a todos y gracias por su colaboración.Me han servido como sensei y he cogido las mejores practicas de cada uno de sus comentarios :)

Gracias.

Re: @luxspes cc: @bferro Siempre

Jejeje...no era el punto, el punto es que tú hiciste Ryz con el fin de aprender algo no con el fin de reinventar algo ya hecho. Es por lo que defiendo el reinventar el hilo negro mientras no sea en producción ;)

Exacto, y finalmente

Exacto, y finalmente absolutamente todos los inventos se generaron a partir de la idea de mejorar algo existente. El punto importante aquí es que para mejorar algo primero hay que conocer lo existente!

De lo contrario no hubiera existido ni Hibernate, ni Java, ni C++, ni C ni las computadoras ni nada y seguiríamos en la edad de las cavernas o trepados de algún árbol.

El ocio es la madre de todos los inventos!!!

instanceOf con reflexion

Un poco tarde (mucho de hecho)

pues aqui tambien hay una forma de hacer esas comparaciones pero con el uso de reflexion

para los que no lo quieran/puedan leer:

   class A {}

   public class instance1 {
      public static void main(String args[])
      {
         try {
            Class cls = Class.forName("A");
            boolean b1
              = cls.isInstance(new Integer(37));
            System.out.println(b1);
            boolean b2 = cls.isInstance(new A());
            System.out.println(b2);
         }
         catch (Throwable e) {
            System.err.println(e);
         }
      }
   }

Imagen de luxspes

ORM de petatiux = Persistencia por programador sin experiencia

Un sistema de ABMC, pero en la marcha se me van ocurriendo cosas como lo del ORM, por ahora el proyecto no usara ningun ORM petatiux,

de hecho... si tu pones ese codigo en tu sistema en production... estaras... poniendole a tu sistema un ORM de petatiux (con enfasis en el petatiux). Si es un sistema de produccion, ya construido sobre JDBC, yo te recomendaria invirtieras tiempo en introducir Spring-JDBC en el proyecto, con el fin de estandarizar y simplificar el codigo de acceso a datos...y mas adelante, para nuevos proyectos, pensar en utilzar JPA, sobretodo si esos nuevos proyectos son mas ABM que C.

Tampoco soy un programador java con años de experiencia, solo llevo leyendo, testeando, probando, etc.. 6 semanas.

De ahi que te convenga agarrarte de una base solida, como Spring-JDBC, y no hace experimentos tu solo. Por otro lado, por supuesto que es buena idea hacer experimentos de este tipo para aprender... pero... meter dicho codigo, que muy probablemente tendra una taza alta de defectos, en un sistema en produccion... bueno... eso no es para nada una buena idea...

Ahora, hacer un ORM es algo muy interesante, aunque sea de petatiux, yo he construido un par y se aprende mucho al hacerlo, pero no es un esfuerzo para nada trivial, y puede convertir un proyectito de 3 meses en un monstruo de 12 meses (de los cuales invertirás 11 haciendo el ORM). Es por eso que es mucho mejor idea usar algo como Spring-JDBC, si el codigo ya esta organizado para "uso directo" de JDBC, o de plano si es un proyecto nuevo, apoyarte en alguno de los ORM que siguen el estandar JPA (Hibernate, EclipseLink) o inclusive de los que lo siguen (como Cayenne, inspirado en EOF de NextStep).

Por otro lado, a los programadores nos encanta reinventar, y de la reinvencion han surgido grandes ideas... pero hay que tener cuidado de entender el precio que puedes acabar pagando por ellas...

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">