menu
Blog
La ley de Demeter es un principio básico de la programación orientada a objetos. Sorprende al conocerlo su gran utilidad, sus resultados en proyectos de todos los tamaños y el poco conocimiento que la comunidad de desarrolladores tiene de su existencia.
Su enunciado básico es:
A method of an object should invoke only the methods of the following kinds of objects:
- itself
- its parameters
- any objects it creates/instantiates
- its direct component objects
Mejora de forma considerable la encapsulación y la cambiabilidad de nuestro código. Explicaremos en este artículo cual es su significado y como detectar los lugares en nuestro código donde no se cumple.
Una forma de comprender mejor esta ley podemos dar la vuelta al enunciado y enumerar los casos prohibidos: no se debe llamar a métodos de los objetos devueltos por otros métodos.
El caso más común que debemos evitar son las cadenas de métodos, de la forma:
a.getX().getY().getValue();
y sustituirlas por funciones que realicen dicha acción:
a.getXYValue();
JSON-RPC-Java permite, como comentamos en el post anterior, la comunicación transparente entre el código JavaScript y Java.
Otra de las características que hacen tremendamente interesante a esta tecnología es el tratamiento que hace a los objetos devueltos. Esta librería es capaz de serializar los objetos Java y de deserializarlos como objetos JavaScript. Así ahorramos el tiempo necesario para determinar el formato de la información a enviar, siendo innecesario definir esquemas para nuestros XML o JSON como hacíamos sin JSON-RPC-Java.
Devolviendo Beans
Un Bean (o JavaBean) es un objeto Java que cumple las siguientes características:
- Implementa un constructor sin parámetros.
- Sus atributos son accesibles vía getters y setters.
- Implementa la interfaz Serializable.
Podéis encontrar más información en la Web de esta tecnología.
Con JSON-RPC-Java, si una función de un objeto registrado devuelve un Bean este se serializa y se envia. De tal forma que podremos acceder a el como si se tratara de un objeto JavaScript.
Por ejemplo, un objeto de la siguiente clase:
public class Ejemplo implements Serializable {
Desde hace un tiempo, en diferentes proyectos, utilizamos esta librería, que simplifica enormemente el desarrollo de aplicaciones Web que hacen uso del archiconocido Ajax. Os explicaremos e este articulo como instalarlo y empezar a usarlo.
JSON-RPC-Java permite al programador JavaScript acceder de forma transparente a las funciones de servidor de una aplicación Web J2EE.
Para empezar a usar JSON-RPC-Java debemos definir cuales son las clases que deseamos que se puedan acceder desde JavaScript. Usaremos la siguiente, por ejemplo:
package com.ateneaTech.jsonrpcjava;
public class Ejemplo {
public String foo() {
return "Hola, foo!";
}
}
El siguiente paso es registrar esta clase. Solo es necesario registrar una clase una vez en cada sesión. Aunque existen formas de registrar clases desde un JSP, nosotros recomendamos, por claridad en el código, hacerlo en un servlet. Para ello utilizamos la clase JSONRPCBridge que nos permite registrar nuestra clase en el RPC. Mantendremos una instancia de JSONRPCBridge por cada sesión, con el código:
Estas dos ultimas semanas he estado trabajando con XmlBeans. Para aquellos que no lo sepáis de lo que hablo, os pongo una pequeña definición de la página oficial de Apache:
XMLBeans is a technology for accessing XML by binding it to Java types. XMLBeans provides several ways to get at the XML
Mediante este proyecto se pretende facilitar el acceso a documentos XML desde Java proporcionando un sistema que genera a partir del schema XML las clases que representan las entidades XML así como una API para instanciar dichos objetos a partir del documento XML.
La verdad es que todas estas definiciones quedan muy bonitas, pero una vez nos ponemos el mono de trabajo van surgiendo los problemas. Dedicaré este post a explicar todas las piedras que he ido encontrando por el camino y creo que puede ser realmente útil para todos aquellos que quieran utilizar este sistema de mapeo en sus aplicaciones.
1. java.io.IOException al ejecutar "scomp":
Hemos modificado la dirección de nuestro RSS para que pase por FeedBurner, para así poder obtener mejores estadísticas sobre el acceso y el uso de nuestro boletín. La nueva dirección es:
Actualizad vuestros lectores de feeds.
Ya hace unos días que estamos en linea y desde el primero de ellos venimos utilizando una herramienta que ofrece nuestro proveedor de hosting para analizar el tráfico de nuestra Web. Nos permite saber el numero, la forma de acceso y el lugar del mismo de nuestros visitantes.
Queriendo saber más de vosotros nos acordamos de la, ya suficientemente blogeado por dos o tres, alternativa del todo poderoso Google: Analytics. Un espectáculo de fuegos artificiales, drag&drops y mapas de colores.
Tras superar el formulario de login sin problemas, como si entraras en el correo, solo es necesario dar cuatro datos sobre el dominio a seguir y copiar en cada una de nuestras páginas un sencillo código JavaScript:
Tras este simple paso, Google mantendrá un log sobre cada una de las páginas que contengan el código. Lo peor: los visitantes que no tengan activado JavaScript en su navegador o accedan usando otros dispositivos que no lo soporten no serán indexados.
Dentro de poco la versión de PHP más utilizada se descontinuará. A partir del primer dia de enero de 2008 dejarán de aparecer mejoras en el sistema y a partir del 8 de agosto del mismo año, también cesará la aparición de parches de seguridad.
PHP4 ha estado entre nosotros largo tiempo y su sucesor PHP5 lleva ya entre nosotros más de tres años desde el 13 de julio de 2004. La falta de documentación y la gran base de programadores de PHP4 han hecho que su uso no descienda desde la aparición de PHP5 y plantea un escenario sin precedentes: se descontinuará la versión más utilizada en favor de otra menos conocida pero indudablemente mejor.
Las principales mejoras de PHP5 respecto a PHP4 son:
El termino peyorativo código espagueti hace referencia al aspecto que tiene un archivo de código en el que se entremezclan diferentes lenguajes. El desarrollo Web con PHP es un claro ejemplo de ello: HTML mezclado con PHP hacen el código prácticamete ilegible.
Los motores de plantillas son una buena solución en este caso. Un motor de plantillas permite extraer el control de la presentación del código PHP. Y entre ellos destaca Smarty.
A efectos prácticos, utilizando Smarty o cualquier otro motor de plantillas, tendremos ya no un archivo con código PHP y HTML entremezclado, sino dos archivos con código separado y limpio:
- La plantilla contendrá el código HTML y una serie de etiquetas que permitan controlar la presentación.
- El archivo PHP que será el encargado de obtener los datos y pasarlos a la plantilla.
Poniendo un simil con otro lenguaje, en J2EE, la forma tradicional de programar en PHP seria un Model 1 i la forma de de trabajar con Smarty y PHP seria más similar a un Model 2, donde los servlets realizan las acciones y buscan la información y los JSPs se encargan de la presentación.
En posts venideros os explicaremos como se utiliza.
Enlaces relacionados:
Aquí os presento los links que he enviado a Luis durante esta semana:
De un tiempo a esta parte, como setas en otoño o urbanizaciones en la costa Murciana, aparecen por estos lares del desarrollo los llamados "Web aplicatión frameworks".
Estos engendros, normalmente de distribución gratuita como la cerveza (incluso, en algún caso, libres como la palabra) y empapados de buenrollismo, permiten el desarrollo rápido de aplicaciones. Implementan las partes más comunes en un desarrollo y las estructuras que permiten adaptarlas a nuestras necesidades concretas. Implican cada uno de ellos una way-of-life diferente para quien las usa y le obliga a conocer sus capacidades y su uso, sus librerías y sus archivos de configuración. Pero, seamos formales, según la Wikipedia:
Pages
Categorías
- Empresa 126
- Eventos 103
- Proyectos 117
- Tutoriales 63