Strict Standards: Redefining already defined constructor for class wpdb in /home/blobgle/public_html/blog/wp-includes/wp-db.php on line 56

Deprecated: Assigning the return value of new by reference is deprecated in /home/blobgle/public_html/blog/wp-includes/cache.php on line 36

Strict Standards: Redefining already defined constructor for class WP_Object_Cache in /home/blobgle/public_html/blog/wp-includes/cache.php on line 384

Strict Standards: Declaration of Walker_Page::start_lvl() should be compatible with Walker::start_lvl($output) in /home/blobgle/public_html/blog/wp-includes/classes.php on line 541

Strict Standards: Declaration of Walker_Page::end_lvl() should be compatible with Walker::end_lvl($output) in /home/blobgle/public_html/blog/wp-includes/classes.php on line 541

Strict Standards: Declaration of Walker_Page::start_el() should be compatible with Walker::start_el($output) in /home/blobgle/public_html/blog/wp-includes/classes.php on line 541

Strict Standards: Declaration of Walker_Page::end_el() should be compatible with Walker::end_el($output) in /home/blobgle/public_html/blog/wp-includes/classes.php on line 541

Strict Standards: Declaration of Walker_PageDropdown::start_el() should be compatible with Walker::start_el($output) in /home/blobgle/public_html/blog/wp-includes/classes.php on line 560

Strict Standards: Declaration of Walker_Category::start_lvl() should be compatible with Walker::start_lvl($output) in /home/blobgle/public_html/blog/wp-includes/classes.php on line 659

Strict Standards: Declaration of Walker_Category::end_lvl() should be compatible with Walker::end_lvl($output) in /home/blobgle/public_html/blog/wp-includes/classes.php on line 659

Strict Standards: Declaration of Walker_Category::start_el() should be compatible with Walker::start_el($output) in /home/blobgle/public_html/blog/wp-includes/classes.php on line 659

Strict Standards: Declaration of Walker_Category::end_el() should be compatible with Walker::end_el($output) in /home/blobgle/public_html/blog/wp-includes/classes.php on line 659

Strict Standards: Declaration of Walker_CategoryDropdown::start_el() should be compatible with Walker::start_el($output) in /home/blobgle/public_html/blog/wp-includes/classes.php on line 684

Deprecated: Assigning the return value of new by reference is deprecated in /home/blobgle/public_html/blog/wp-includes/query.php on line 21

Deprecated: Assigning the return value of new by reference is deprecated in /home/blobgle/public_html/blog/wp-includes/theme.php on line 540
blobgle.com » .net

Posts Tagged ‘.net’

Buenas Prácticas: Definición de Excepciones Propias

Wednesday, November 7th, 2007

Inicio una nueva saga de opinión relacionado con las buenas prácticas. La primera, está relacionada con la programación, en concreto con la creación de excepciones propias, relacionadas con las clases que vayamos generando.

Para los que no conozcan o no hayan trabajado con excepciones, me ahorro la definición y me uno a la reutilización de código: http://es.wikipedia.org/wiki/Manejo_de_excepciones

Una vez situados en el contexto, paso a describir la práctica con un ejemplo.

Supongamos que utilizamos una clase que nos ayudará a extraer datos de un dispositivo GPS, que en un alarde originalidad vamos a llamar “GPS”. La clase tiene varios métodos y no tenemos acceso al código, ya que la importamos a traves de una dll.

1) CountSatelitesDisponibles(): Retorna el total de satélites disponibles para el dispositivo GPS
2) GetLongitud(): Retorna la longitud actual
3) GetLatitud(): Retorna la latitud actual
4) Conectar(): Conecta el dispositivo GPS
5) Desconectar(): Desconecta el dispositivo GPS
6) IsConexion(): Retorna verdadero si hay conexión con el gps, retorna falso en caso contrario

Si nos pusiéramos en marcha para utilizar la clase en nuestra aplicación, podríamos crear algo similar a esto (uso sintaxis C#)

public void miMetodo()
{
    try
    {
        GPS objeto = new GPS();
        objeto.Conectar();
        if (objeto.IsConexion())
        {
            if (objeto.countSatelitesDisponibles()>=4)
            {
                // mostrarPorPantalla es un
                // método que genera una pantalla
                // emergente
                mostrarPorPantalla(objeto.GetLongitud());
            }
        }
    }
    catch(Exception ex)
    {
        // tratarExcepcion es un método
       // que se encarga de mostrar el
       // mensaje por pantalla.
        tratarExcepcion(ex);
    }
    finally
    {
        objeto.Desconectar();
    }
}

¿Qué ocurriría si se produce alguna excepción en la ejecución del código? Pues se haría el catch con el objeto Exception, y tratarExcepcion se encargaría de mostrar un mensaje por pantalla. Si hemos tenido suerte que en la definición de la clase GPS el desarrollador incluyó una excepción genérica con un mensaje de texto, con suerte almenos en ex.Message tendremos parte de la descripción del error. Es todo lo que podríamos hacer desde la llamada a la clase GPS con las herramientas que nos brinda. No somos capaces de tratar la excepción en la conexión, o en el recuento de satélites desde nuestro código, ya que no sabemos cúando se produjo el error allí (si hay mensaje podríamos mirar el mensaje… pero eso es una cutrez nada recomendada y menos en este artículo)

A continuación dejo aquí lo que sería la definición del método Conectar de la clase GPS lanzando excepciones genéricas

public void Conectar()
{
    try
    {
        // Código encargado de conectar el dispositivo GPS
    }
    catch(Exception ex)
    {
        throw new Exception(”Error al conectar”);
    }
}

¿Y si en lugar de utilizar excepciones genéricas dejáramos definidas excepciones propias de la clase y las lanzáramos a estas en lugar de usar la excepción genérica?

public void Conectar()
{
    try
    {
        // Código encargado de conectar el dispositivo GPS
    }
    catch(Exception ex)
    {
        throw new NoSeHaPodidoConectarConElGPSException();
    }
}

public class NoSeHaPodidoConectarConElGPSException:Exception
{
    public NoSeHaPodidoConectarConElGPSException() : base(”Error Conectando”) { }
}

Esto ya es otra cosa, ya que ahora, desde nuestra aplicación podremos tratar exáctamente cual ha sido la excepción que se ha producido. Fijaros:

public void miMetodo()
{
    try
    {
        GPS objeto = new GPS();
        objeto.Conectar();
        if (objeto.IsConexion())
        {
            if (objeto.countSatelitesDisponibles()>=4)
            {
                // mostrarPorPantalla
                // es un método que genera
                // una pantalla emergente
                mostrarPorPantalla(objeto.GetLongitud());
            }
        }
    }
    catch(GPS.NoSeHaPodidoConectarConElGPSException ex)
    {
        //mandarEmailServicioTecnicoGPS se 
        //encarga de coger la excepción,
        // generar un email con la información
        // que incluye y mandarlo al técnico
       // con menor carga de trabajo de nuestra
       // organización.
        mandarEmailServicioTecnicoGPS(ex);
    }
    catch(Exception ex)
    {
        // tratarExcepcion es un método que
        // se encarga de mostrar el mensaje
        // por pantalla.
        tratarExcepcion(ex);
    }
    finally
    {
        objeto.Desconectar();
    }
}

¿Mucho mejor no? ¿Merece o no merece la pena el definir excepciones propias?

Extraido de http://www.miguelmatas.es/blog/2007/09/26/buenas-practicas-definicion-de-excepciones-propias/

Java: Buenas Prácticas: Legibilidad y Mantenibilidad del Código

Wednesday, November 7th, 2007

Y es que muchas veces nos olvidamos de que nuestro código va a tener que ser interpretado, leído y mantenido por otras personas, o incluso por nosotros mismos en un futuro.

Mantener estructuras similares a la hora de programar, un estilo de programación, un orden determinado y un código claro, harán que la mantenibilidad de nuestras aplicaciones se dispare. Este aspecto se ve aún más potenciado en grupos de trabajo de alta volatilidad, donde la estabilidad del número de profesionales que forman el grupo es alta. Me refiero tanto a la baja de miembros del equipo como a la rápida incorporación de nuevos profesionales para aumentar el tamaño del grupo.

Quisiera dejar patente la diferencia de legibilidad y mantenibilidad entre dos fragmentos de código que llevan a cabo exactamente la misma funcionalidad

Ejemplo de baja legibilidad y mantenibilidad (código C#):

public bool NumPuerMayorQue(int t)
{
    int n = 0;
    coche[] lista = DameListaCoches();
    for(int i=0;i<lista.lenght;i++)
        n = n + (coche)lista[i].NumPuertas;
    if (n>t)
        return true;
    else
        return false;
}

Ejemplo de mejor legibilidad y mantenibilidad

/// <summary>
/// Añade un nuevo parámetro a la lista
/// </summary>
/// <param name=”numPuertas”>Número de puertas a comparar</param>
/// <param name=”lista”>Lista genérica de coches sobre la que hacer el cálculo</param>
/// <returns>Retorna verdadero en el caso de que la variable numPuertas pasada por parámetro sea mayor que el resultado de sumar todas las puertas de los coches pasados por parámetro en la variable lista. Retorna falso en caso contrario, es decir cuando es menor o igual.</returns>
public bool IsNumeroPuertasMayorQue(int numPuertas, List<coche> lista)
{
    int total = 0;

    foreach (coche unCoche in lista)
    {
        total += unCoche.NumPuertas;
    }

    return (total > numPuertas);
}

Aspectos que hacen notar la mejora de la mantenibilidad y la legibilidad de ambas funciones

1) Se dispone de un comentario sobre qué labor va a realizar la función, qué papel juega cada uno de sus parámetros y qué valores se esperan retornar y en qué condiciones.

2) El nombre de la función, al marcar el prefijo “Is” ya nos da la pista de que va a devolvernos un booleano. IsNumeroPuertasMayorQue da más pistas al desarrollador que NumPuerMayorQue.

3) La lista de coches es pasada por parámetro a la función, siendo además una lista genérica. Sabemos exactamente de dónde nos llega la lista.

4) Uso de foreach en lugar de for. Usando foreach aumentamos la legibilidad y la elegancia de nuestro código.

5) Uso de lista genérica en lugar de arrays. Nos estamos evitando hacer el cast “(coche)lista[i]”, que además no nos asegura que lo que realmente tenga la lista sean objetos de tipo coche, puede darse un error de casting.

6) El nombre de las variables utilizadas es mucho más descriptivo.

7) Llaves en sentencias de una sóla línea. Realmente funcionan igual, pero si a las sentencias for, foreach, if y else le añadimos llaves de apertura y cierre aunque incluyan una única sentencia, lo leeremos mejor.

8) Creo que queda bastante claro que se lee mejor “return (total > numPuertas)”

9) Una linea en blanco entre bloques. ¿La vista lo agradece, no?

extraido de: http://www.miguelmatas.es/blog/2007/10/17/buenas-practicas-legibilidad-y-mantenibilidad-del-codigo/