Ley de Demeter LoD

Tambien llamado Principio del Minimo Conocimiento (Northeastern University, 1987).

(Sacado del articulo de Jorge Rodriguez, “pruebas-unitarias“)

Esta ley dice que un objeto solo debe depender de objetos que esten muy cercanos a el, o sea no debería usar objetos globales.

Ejemplo:

  • helper.metodo(); // BIEN
  • helper.getSegundoHelper().metodo(); // MAL
Anuncios
Ley de Demeter LoD

Versiones de Java

Articulo original

Java 1

Java 1.0 (Enero 1996) – 8 paquetes, 212 clases –
Primera versión pública. La presión hizo que se hiciera pública demasiado pronto, lo cual significa que el diseño del lenguaje no es demasiado bueno y hay montones de errores. Respecto a seguridad, es restrictivo por defecto, no dejando hacer demasiado al código no fiable.

Java 1.1 (Marzo 1997) – 23 paquetes, 504 clases –
Mejoras de rendimiento en la JVM, nuevo modelo de eventos en AWT, clases anidadas, serialización de objetos, API de JavaBeans, archivos jar, internacionalización, API Reflection (Reflexión), JDBC (Java Data base Connectivity), RMI (Remote Method Invocation). Se añade la firma del código y la autentificación. Es la primera versión lo suficientemente estable y robusta.

Java 2

Java 1.2 (Diciembre 1998 ) – 59 paquetes, 1520 clases –
JFC (Swing), Drag and Drop, Java2D, Corba, API Collections. Se producen notables mejoras a todos los niveles. Para enfatizar esto Sun lo renombra como “Java 2”. El JDK (Java Development Kit) se renombra como SDK (Software Development Kit). Se divide en J2SE, J2EE y J2ME.

Java 1.3 (Abril 2000) – 77 paquetes, 1595 clases –
Orientada sobre todo a la resolución de errores y a la mejora del rendimiento; se producen algunos cambios menores como la inclusión de JNDI (Java Naming and Directory Interface) y la API Java Sound. También incluye un nuevo compilador de alto rendimiento JIT (Just In Time).

Java 1.4 (2002) – 103 paquetes, 2175 clases –
También conocido como Merlin, es la versión actual. Mejora notablemente el rendimiento y añade entre otros soporte de expresiones regulares, una nueva API de entrada/salida de bajo nivel (NIO, New I/O), clases para el trabajo con Collections, procesado de XML; y mejoras de seguridad como el soporte para la criptografía mediante las Java Cryptography Extension (JCE), la inclusión de la Java Secure Socket Extension (JSSE) y el Java Authentication and Authorization Service (JAAS).

Java 1.5 (Octubre 2004) – 131 paquetes, 2656 clases –
También conocido como Tiger, renombrado por motivos de marketing como Java 5.0.
Incluye como principales novedades: tipos genéricos (generics), autoboxing/unboxing conversiones impliticas entre tipos primitivos y los wrappers correspondientes, Enumerados, Bucles simplificados, printf, Funciones con número de parámetros variable, Metadatos en clases y métodos.

Java 1.6 (diciembre de 2006) —
También conocido como Mustang. Estuvo en desarrollo bajo la JSR 270. En esta versión, Sun cambió el nombre “J2SE” por Java SE y eliminó el “.0” del número de versión.
Los cambios más importantes introducidos en esta versión son: Incluye un nuevo marco de trabajo y APIs que hacen posible la combinación de Java con lenguajes dinámicos como PHP, Python, Ruby y JavaScript. Incluye el motor Rhino, de Mozilla, una implementación de Javascript en Java. Incluye un cliente completo de Servicios Web y soporta las últimas especificaciones para Servicios Web, como JAX-WS 2.0, JAXB 2.0, STAX y JAXP. Mejoras en la interfaz gráfica y en el rendimiento.

Versiones de Java

Patrones de Diseño

Los patrones de diseño (design patterns) son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Maneras de implementar, mediante interfaces, casos específicos en programación.

Patrones de Diseño

Patrones de Diseño

Los patrones de diseño (design patterns) son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Maneras de implementar, mediante interfaces, casos específicos en programación.

Patrones de Diseño

Inversión de Control (IoC) & Inyección de Dependencia (DI)

<!– @page { margin: 2cm } P { margin-bottom: 0.21cm } –>

En los comienzos de la programación, los programas eran lineales y monolíticos. El flujo de ejecución era simplemente ejecutar línea tras linea.

Aparecieron dos conceptos que revolucionaron la programación: la modularidad y la reutilización de los componetes: se crean librerías de componentes reutilizables. El flujo se complica, saltando de componente a componente, y aparece un nuevo problema: la dependencia (acoplamiento) entre nuestros componentes.

El problema se empieza a considerar lo suficientmente importante como para definir nuevos conceptos en el diseño :

  • Inversion of Control (IoC)

  • Dependency Injection (DI)

La utilización de interfaces y la aparición de los frameworks es un primer paso para minimizar estas dependencias entre componentes, aunque pagamos un precio: la configuración en ficheros xml se empieza a volver monolítica, difícil de mantener, crítica y es fácil cometer errores.

Inversión de Control (IoC) & Inyección de Dependencia (DI)

Inyeccion de Dependencia (Dependency Injection, DI)

Es un término comúnmente confundido con Inversion de Control.

En un escenario en el que utilizamos IoC, delegamos en una entidad “Contenedor” no solo la gestión de las instancias, sino la inyección de las sub-partes (dependencias). Si una venta se compone de un cliente y un producto, al instanciar un objeto venta la DI le inyecta directamente su cliente y su producto específicos.

La arquitectura de Spring esta basada en patrón de diseño llamado “Dependency Injection”, Rob Harrop define a este patrón como: “Es la manera de externalizar la creación y el manejo de las dependencias de los componentes”.

Clases e InterfacesPara comprender el patrón Dependency Injection considere la figura 1 la cual es un diagrama de clases, la clase Foo depende de una instancia de la clase Bar, para realizar algún tipo de procesamiento, tradicionalmente en la clase Foo se tendría la sentencia Bar bar=new Bar(); para crear el objeto bar, usando Dependency Injection una instancia de Bar (o bien una subclase) es proporcionada a la clase Foo en tiempo de ejecución por algún proceso externo, es decir la clase Foo no llama a crear el objeto bar si no que el proceso externo le proporciona el objeto bar a la clase Foo, es por eso que Rod Johnson define a Dependency Injection con la frase: “No me llames, yo te llamo”.

James Shore explica concisamente, “consiste en dar valores a las variables de un objeto”. Una clase, para estar completa necesita información, datos de otra. Con la DI, lo que hacemos es proporcionárselos, ya no tiene que pedir esos datos, se le dan.

1La idea se basa en que dado un objeto, “algo” resuelva sus dependencias, inyectandoselas ya sea a través de métodos setXXX o de uno de los constructores del objeto; para que esto sea posible, ese “algo” debe manejar el ciclo de vida del objeto.

Tipos de DI según Martin Fowler:

  1. TIpo 1 – Inyeccion de Interface.
  2. Tipo 2 – Inyeccion de Setter.
  3. Tipo 3 – Inyeccion de Contructor.

1Jorge Rodriguez, Interplanet S.A (Chile)

Inyeccion de Dependencia (Dependency Injection, DI)

Inversión de Control (Inversion of Control, IoC)

<!– @page { margin: 2cm } P { margin-bottom: 0.21cm } –>

Es una técnica que inverte el flujo tradicional. Lo tradicional es que el código que implementes llame a las librerías; la inversión de control ocurre cuando son las librerías las que llaman a tu código.

En cierto modo es una implementación del Principio de Hollywood (no nos llames a nosotros; nosotros te llamaremos a tí.), una metodología de diseño de software.

En Spring, la inversión de control consiste en ceder el control a una entidad externa a la aplicación, llamada “Contenedor”, que se encargará de gestionar las instancias (así como sus creaciones y destrucciones).

¿Quién determina cómo deben inyectarse las dependencias?: El framework de Inversión de Control según los ficheros xml de configuración.

Beneficios

  • Elimina la responsabilidad de buscar o crear los objetos dependientes y la traslada a la configuración

  • Reduce el acoplamiento entre objetos

  • Fomenta el diseño basado en interfaces

  • Permite reconfigurar una aplicación sin modificar el código.

Se puede interpretar como que el Contenedor es un robot. Contiene piezas, engranajes, un Sistema Operativo, memoria, microprocesador… El contenedor esta esperando que le indiquemos que debe realizar para hacerlo, necesita que le programemos unas rutinas para trabajar. Esas rutinas configuradas mediante documentos xml, *.properties, permiten al robot saber que es lo que tiene que hacer. Pero es Inteligente, no le tienes que programar todo de arriba abajo, solo unas partes.

Inversión de Control (Inversion of Control, IoC)