Patrones de diseño GoF (Gang of Four)

En anteriores post, hemos visto algunos de los patrones que son parte del GOF. Pero como una imagen vale más que mil palabras, aquí les dejo este link en donde podrán encontrar un excelente PDF con los diagramas UML de los principales patrones.

Esta no es la única opción, ya que también existe el poster de Head Fisrt Design Patterns, pero que a diferencia de la opción anterior, esta utlima es pagada.

Este es un poster que Cerebro no puede dejar de tener!!

SCWCD - El descriptor de despliegue web.xml

El archivo web.xml proporciona la configuración y el despliegue de información para los componentes web que conforman una aplicación.

Este archivo debe residir en el directorio WEB-INF dentro del contexto de la jerarquía de directorios que existen para una aplicación Web. Por ejemplo, si la aplicación esta empaquetada en el archivo WAR "dukechile.war", el archivo web.xml se debe colocar en el directorio “dukechile/ WEB-INF”.

Como todos los archivos de configuración xml, este contiene un esquema que describe el contenido del fichero xml y la descripción de las propiedades que va a utilizar. Dentro de este archivo definiremos la configuración de la aplicación web que estemos desarrollando.

Los elementos del web.xml son:

<web-app>: Es el elemento raíz del fichero xml.

<icon>: Define la ruta para las imágenes asociadas a los iconos pequeño y grande que representan a la aplicación.

<display-name>: Es el nombre que representará a la aplicación dentro de las herramientas del servidor de aplicaciones, no es un nombre funcional.

<description>: Texto descriptivo de la aplicación, que al igual que las dos anteriores propiedades, sólo es representativo.

<context-param>: Permite configurar parámetros de inicialización del contexto de nuestra aplicación web.

<br /><context-param><br /> <param-name>nombrehost</param-name><br /> <param-value>localhost</param-value><br /> <description> Nombre del host en cual se esta ejecutando la aplicacion</description> </context-param> <br />

<filter>: Permite definir un filtro en la aplicación.

<br /><filter><br /> <filter-name>LogSolicitudes</filter-name><br /> <filter-class>cl.bee.dukechile.LogSolicitudes</filter-class><br /> <init-param><br /> <param-name>nombrearchivo</param-name><br /> <param-value>registrolog</param-value><br /> </init-param><br /> </filter><br />

<filter-mapping>: Define un mapeo para aplicar las reglas de un determinado filtro a una URL.

<br /><filter-mapping><br /> <filter-name> LogSolicitudes </filter-name><br /> <url-pattern>/cl/jug/dukechile/*</url-pattern><br /> </filter-mapping><br />

<listener>: Permite definir una clase oyente, la que puede escuchar eventos relacionados al clico de vida de la aplicación o modificaciones de un objeto.

<br /><listener><br /> <listener-class>cl.jug.dukechile.ListenerDeContexto</listener-class><br /></listener><br />

<servlet>: Permite definir la configuración de nuestros servlets.

<br /><servlet><br /> <servlet-name>DukeChile</servlet-name><br /> <servlet-class>cl.jug.dukechile.MiServlet</servlet-class><br /> <init-param><br /> <param-name>configuracion</param-name><br /> <param-value>/WEB-INF/dukechile-config.xml</param-value><br /> </init-param><br /> <load-on-startup>1</load-on-startup><br /></servlet><br />

<servlet-mapping>: Permite relacionar los servlets que hemos declarado con las URL que van a escuchar.

<br /><servlet-mapping><br /> <servlet-name>DukeChile</servlet-name><br /> <url-pattern>*.jsp</url-pattern><br /></servlet-mapping><br />

<session-config>: Permite definir el timeout de la sesión en minutos.

<br /><session-config><br /> <session-timeout>10</session-timeout><br /></session-config><br />

<mime-mapping>: Permite definir una relación entre las extensiones y los tipos mime.

<br /><mime-mapping><br /> <extension>doc</extension><br /> <mime-type>application/vnd.ms-word</mime-type><br /></mime-mapping><br /><br /><mime-mapping><br /> <extension>dsp</extension><br /> <mime-type>text/html</mime-type><br /></mime-mapping><br />

<welcome-file-list>: Permite definir los ficheros de bienvenida de la aplicacion.

<br /><welcome-file-list><br /> <welcome-file>index.jsp</welcome-file><br /> <welcome-file>index.html</welcome-file><br /></welcome-file-list><br />

<tag-lib>: Permite definir las librerías de etiquetas de los ficheros JSP.

<br /><jsp-config><br /> <taglib><br /> <taglib-uri>/tags/struts-bean</taglib-uri><br /> <taglib-location>/WEB-INF/struts-bean.tld</taglib-location><br /> </taglib><br /></jsp-config><br />

<jsp-property-group<: Permite definir propiedades para un conjunto de JSP que cumplan un patrón.

<br /><jsp-config><br /> <jsp-property-group><br /> <url-pattern>*.jsp</url-pattern><br /> <include-prelude>/cabecera.jsp</include-prelude><br /> <include-coda>/pie.jsp</include-coda><br /> </jsp-property-group><br /></jsp-config><br />

<error-page<: Permite asociar errores HTML y excepciones lanzadas por nuestra aplicación a páginas de error personalizadas para la aplicación.

<br /><error-page><br /> <error-code>404</error-code><br /> <location>/noEncontrado.jsp</location><br /></error-page><br /><br /><error-page><br /> <exception-type>java.lang.Throwable</exception-type><br /> <location>/error.jsp</location><br /></error-page><br />

<resource-ref<: Permite declarar recursos externos que nuestra aplicación va a utilizar. Por ejemplo, una conexión a una base de datos.

<br /><resource-ref><br /> <description>Conexion BD</description><br /> <res-ref-name>jdbc/ConexionMySQL</res-ref-name><br /> <res-type>javax.sql.DataSource</res-type><br /> <res-auth>Container</res-auth><br /></resource-ref> <br />

<resource-env-ref<: Permite declarar recursos externos que nuestra aplicación va a utilizar. Este elemento es una nueva variación del elemento añadido en Servlet 2.4 que es más simple de configurar para recursos que no necesitan información de autenticación.

<br /><resource-env-ref><br /> <resource-env-ref-name>jms/StockQueue</resource-env-ref-name><br /> <resource-env-ref-type>javax.jms.Queue</resource-env-ref-type><br /></resource-env-ref><br />

<security-constraint<: Permite proteger áreas de la aplicación (o la aplicación completa), asociándolas a roles que deben tener los usuarios para poder acceder. Estos usuarios y roles son los declarados en tomcat-users.xml (para el caso de Tomcat).

<br /><security-constraint><br /> <web-resource-collection><br /> <web-resource-name>Seguridad Duke Chile</web-resource-name><br /> <url-pattern>/*</url-pattern><br /> </web-resource-collection><br /> <auth-constraint><br /> <role-name>duke</role-name><br /> </auth-constraint><br /></security-constraint><br />

<login-config<: Permite configurar el tipo de login que se requerirá al entrar en un área protegida previamente declarada.

<br /><login-config><br /> <auth-method>FORM</auth-method><br /> <realm-name>Login por formulario</realm-name><br /> <form-login-config><br /> <form-login-page>/login.jsp</form-login-page><br /> <form-error-page>/error.jsp</form-error-page><br /> </form-login-config><br /></login-config><br />

<security-role<: Permite definir los roles de usuarios que se van a utilizar en la aplicación.

<br /><security-role><br /> <role-name>duke</role-name><br /></security-role><br />

<env-entry<: Permite declarar una posible entrada al entorno (environment) de la aplicación.

<br /><env-entry><br /> <description>Mensaje de bienvenida</description><br /> <env-entry-name>bienvenida</env-entry-name><br /> <env-entry-type>java.lang.String</env-entry-type><br /> <env-entry-value>Bienvenido al sistema DukeChile</env-entry-value><br /></env-entry><br />

<ejb-ref<: Permite definir una referencia a un EJB.

<br /><ejb-ref><br /> <description>EJB DukeChile</description><br /> <ejb-ref-name>ejb/DukeChileHome</ejb-ref-name><br /> <ejb-ref-type>Entity</ejb-ref-type><br /> <home>cl.jug.dukechile.DukeChileHome</home><br /> <remote>cl.jug.dukechile.DukeChile</remote><br /></ejb-ref><br />

<ejb-local-ref<: Permite definir una referencia a un EJB Local.

<br /><ejb-local-ref><br /> <ejb-ref-name>ejb/DukeChile</ejb-ref-name><br /> <ejb-ref-type>Session</ejb-ref-type><br /> <local-home> cl.jug.dukechile.DukeChileHome</local-home><br /> <local>cl.jug.dukechile.DukeChile</local><br /> <ejb-link>DukeChile</ejb-link><br /></ejb-local-ref><br />

<distributable<: Permite definir que la aplicación puede correr en un ambiente cluster.

<br /><web-app><br /> <distributable/><br /></web-app><br />

SCWCD - Seguridad en aplicaciones Web

Uno de los tópicos que se debe estudiar para la certificación SCWCD (Sun Certified Web Component Developer) son los mecanismos de seguridad en las aplicaciones Web.

Mecanismos de seguridad

La seguridad en los servlets se reduce a cuatro conceptos principales:

• authentication: El proceso de autenticación es el encargado de determinar que el interesado en acceder los recursos es realmente quien dice que es. Lo más común es hacer que el usuario o la aplicación envié un password que lo identifica.

• authorization: Es el proceso por el cual se restringe el acceso a ciertos recursos a un conjunto de clientes. En realidad, lo que se define es un conjunto de roles que pueden acceder a ciertos recursos y se asocia cada usuario a uno o más roles.

• data integrity: Es el proceso que asegura que los datos que se reciben (tanto el cliente como el servidor) no han sido corrompidos. Generalmente se usan algoritmos de encriptación para lograr esto.

• confidentiality: Es el proceso que intenta asegurar que solamente los clientes autorizados reciban la información. La manera de lograr esto puede ser a través del uso de claves públicas/privadas.

Tipos de autentificación definidos

La especificación de servlet ofrece cuatro tipos de autentificación:

• BASIC: Este es el método más simple, pero el más inseguro. Cuando usamos este tipo de autenticación, se abre una ventana en el browser del cliente para que este ingrese el usuario y el password. El password se envía al servidor codificado en Base64.

• FORM: Este método es similar a BASIC, pero utiliza un formulario provisto por el programador. Este formulario tiene que cumplir los siguientes requisitos:

1. El atributo “action” debe ser “j_security_check”
2. El casillero de ingreso del usuario debe llamarse “j_username”
3. El casillero de ingreso del password debe llamarse “j_password”
   

<form method="post" action="j_security_check"><br /> Usuario: <input type="text" name="j_username"><br /> Password: <input type="text" name="j_password"><br /></form>

• CLIENT-CERT: En este método se usan certificados digitales. El browser debe tener instalado el certificado para que la comunicación se pueda establecer.

• DIGEST: La autenticación también es hecha utilizando usuario y password, pero el password es enviado encriptado de una forma mucho más segura (por ejemplo, utilizando HTTPS client authentication).

Autorización

El primero paso es definir los roles que se encontraran definidos dentro de nuestro sistema. Para el caso de Tomcat, estos se definen en el archivo tomcat-users.xml. Dentro de este archivo, cada usuario tiene asignado un usuario y password; y puede estar asociado a uno o más roles.

<br /><tomcat-users><br /> <role rolename="”Admin”/"><br /> <role rolename="”Member”/"><br /> <role rolename="”Guest”/"><br /> <user username="”jose”" password="”duke”" roles="”Admin,"><br /></tomcat-users><br />

El siguiente paso es relacionar los roles definidos en el archivo tomcat-users.xml, con los roles a utilizar dentro del sistema. Para esto deberemos utilizar los elementos <security-role> y <role-name> dentro del archivo web.xml.

<br /><security-role><br /> <role-name>Admin</role-name><br /></security-role><br /><br /><security-role><br /> <role-name>Member</role-name><br /> </security-role><br /><br /><security-role><br /> <role-name>Guest</role-name><br /></security-role><br />

Una vez definidos los roles, se procede a establecer “declarativamente” el acceso a un conjunto de recursos en combinación con los métodos, a los cuales tendrán accesos determinados roles. El elemento principal es el <security-constraint>.

<br /><security-constraint> <br /><br /> <web-resource-collection><br /> <web-resource-name>ActulizarDatos</web-resource-name><br /> <url-pattern>/cl/jug/actualizar/*</url-pattern><br /> <url-pattern>/cl/jug/listar/*</url-pattern><br /> <http-method>GET</http-method><br /> <http-method>POST</http-method><br /> </web-resource-collection><br /><br /> <auth-constraint><br /> <role-name>Admin</role-name> <br /> <role-name>Member</role-name> <br /> </auth-constraint><br /><br /></security-constraint><br />

Donde:

• El elemento <web-resource-name> es obligatorio y utilizado principalmente por los IDEs.

• El elemento <url-pattern> define el recurso al cual se limitara el acceso. Al menos se debe definir a lo menos un <url-pattern>.

• El elemento <http-method> describe el método HTTP que será restringido para acceder al recurso definido en los <url-pattern>. Si no se define ningún <http-method>, entonces se restringirá el acceso a todos los métodos HTTP.

• El elemento <auth-constraint&gt; es opcional y permite definir cuales roles pueden llamar a los métodos HTTP restringidos por los elementos <http-method&gt;

Para permitir el acceso a todos los roles, se debe definir el elemento <auth-constraint> de la siguiente forma:

<br /><auth-constraint><br /> <role-name>*</role-name><br /></auth-constraint><br />

O también de la forma:

<br /><auth-constraint></auth-constraint><br />

En el caso de que se quiera bloquear el acceso a todos los roles, se deberá definir el <auth-constraint> de la siguiente forma:

<br /><auth-constraint/><br />

Es importante tener en cuenta que se puede tener más de un elemento <web-resource-collection> dentro de un <security-constraint>. En este caso, el elemento <auth-constraint> se aplica a todos los <web-resource-collection> definidos dentro de un <security-constraint>.

Autentificacion

Anteriormente mencionamos que la especificación de servlet ofrece cuatro tipos de autentificación: BASIC, FORM, CLIENT-CERT y DIGEST.

Cada uno de estos tipos se puede definir en el web.xml de siguiente forma:

<br /><login-config> <br /> <auth-method>BASIC</auth-method><br /></login-config><br /><br /><login-config> <br /> <auth-method>FORM</auth-method> <br /> <form-login-config> <br /> <form-login-page>/loginUsuario.html</form-login-page> <br /> <form-error-page>/loginError.html</form-error-page> <br /> </form-login-config><br /></login-config><br /><br /><login-config> <br /> <auth-method>CLIENT-CERT</auth-method><br /></login-config><br /><br /><login-config> <br /> <auth-method>DIGEST</auth-method><br /></login-config><br />

Un punto importante es que de los cuatro tipos de autentificación, el tipo DIGEST es el único que es opcional para los contenedores JEE.

Modos de transporte

La especificación también define tres modos para indicar la seguridad del transporte de los datos a través de la Web.

• NONE: Ningún tipo de cifrado, simplemente HTTP.

• CONFIDENTIAL: Define la confidencialidad de los datos. Es decir, que nadie pueda ver ni modificar los datos que se envían.

• INTEGRAL: Define la integridad de los datos. Es decir, que aunque alguien pueda ver lo que se envía, se garantice que los datos no se modifiquen por el camino.

<br /><security-constraint> <br /><br /> <web-resource-collection><br /> <web-resource-name>ActulizarDatos</web-resource-name><br /> <url-pattern>/cl/jug/actualizar/*</url-pattern><br /> <url-pattern>/cl/jug/listar/*</url-pattern><br /> <http-method>GET</http-method><br /> <http-method>POST</http-method><br /> </web-resource-collection><br /><br /> <auth-constraint><br /> <role-name>Admin</role-name> <br /> <role-name>Member</role-name> <br /> </auth-constraint><br /><br /> <user-data-constraint><br /> <transport-guarantee>CONFIDENTIAL</transport-guarantee><br /> </user-data-constraint><br /><br /></security-constraint><br />

El metodo isUserInRole()

La clase “HTTPServletRequest” tiene tres métodos que están asociados al manejo de la seguridad de manera “programática”, uno de estos es el método “isUserInRole”.

A través del método “isUserInRole()”, en vez de manejar el acceso a nivel de método HTTP, ahora podremos autorizar el acceso a una parte del código de nuestro método basados en los roles del usuario.

Antes de que se llame al método “isUserInRole()”, el usuario necesita estar autenticado. En el caso de que llame al método sobre un usuario que no ha autenticado, el contenedor retornara “false”.

En el caso de que este autenticado, el contenedor toma el argumento del método y compara este con los roles definidos para el usuario en el “request”.

Si el usuario es mapeado a este rol, el contenedor retornara “true”.

Por ejemplo, dentro del código en el servlet:

<br />if( request.isUserInRole(“DukeChile”)) { <br /> // Permiso para actualizar la informacion<br />} <br />else { <br /> // permiso solo para consultar la informacion <br />}<br />

<br /><servlet><br /> <security-role-ref><br /> <role-name> DukeChile </role-name><br /> <role-link>Admin</role-link><br /> </security-role-ref> <br /> ...<br /> </servlet> <br /><br /><security-role> <br /> <role-name>Admin</role-name> <br /></security-role><br />

El elemento <security-role-ref> permite relacionar un <role-name> definido “programáticamente” (en el servlet) con uno que existe en el web.xml.

JMesa

Muchos desarrolladores Web, alguna vez hemos utilizado DisplayTag para la creación de tablas con exportación y paginación automática. DisplayTag es un tag lib que nos permite ahorrar muchas líneas de código.

Ahora disponemos de una alternativa mucho más actualizada y potente llamada JMesa.

Los pasos para agregar JMesa a sus aplicaciones son muy simples.

Descargan JMesa desde aquí y agregan el tld que se encuentra bajo el directorio /jmesa-2.3.3/dist del zip al directorio /WEB-INF/tld de la aplicación.

También deberan agregar los ficheros css, javascript, las imágenes y por supuesto los jar en sus directorios correspondientes. Como JMesa requiere de JQuery, también deberán agregarlo al directorio js ( JQuery lo pueden obtener desde aquí). No importa donde se coloquen los css ni los javascript dado que se configuraran posteriormente. Las imágenes sin embargo tienen que estar en una ruta determinada que ha de coincidir con la del valor de la clave html.imagesPath especificada en el fichero jmesa.properties.

Este último fichero hay que crearlo y referenciarlo en el web.xml:

<context-param><br /> <param-name>jmesaPreferencesLocation</param-name><br /> <param-value>WEB-INF/jmesa.properties</param-value><br /></context-param><br />

A continuación, deberán crear el archivo jmesa.properties en el directorio WEB-INF de la aplicación.

html.table.component.theme=jmesa<br />html.table.renderer.styleClass=table<br /><br />html.row.renderer.highlightClass=highlight<br />html.row.renderer.evenClass=even<br />html.row.renderer.oddClass=odd<br /><br />html.column.header.renderer.image.sortAsc=sortAsc.gif<br />html.column.header.renderer.image.sortDesc=sortDesc.gif<br />html.column.filter.renderer.image.droplistHandle=droplistHandle.gif<br /><br />html.tbodyClass=tbody<br />html.titleClass=title<br />html.filterClass=filter<br />html.headerClass=header<br />html.toolbarClass=toolbar<br />html.statusBarClass=statusBar<br />html.imagesPath=/images/table/<br />html.rowcount.includePagination=false<br /><br />html.toolbar.maxRowsDroplist.increments=15,50,100<br /><br />html.toolbar.image.csv=csv.png<br />html.toolbar.image.pdf=pdf.gif<br />html.toolbar.image.excel=excel.gif<br />html.toolbar.image.clear=clear.png<br />html.toolbar.image.firstPage=firstPage.png<br />html.toolbar.image.firstPageDisabled=firstPageDisabled.png<br />html.toolbar.image.lastPage=lastPage.png<br />html.toolbar.image.lastPageDisabled=lastPageDisabled.png<br />html.toolbar.image.nextPage=nextPage.png<br />html.toolbar.image.nextPageDisabled=nextPageDisabled.png<br />html.toolbar.image.prevPage=prevPage.png<br />html.toolbar.image.prevPageDisabled=prevPageDisabled.png<br />html.toolbar.image.filter=filter.png<br />html.toolbar.image.separator=separator.gif<br />

Con estos pasos, ya se encuentra listo y configurado. Para utilizarlo hay que definir el namespace de JMesa en nuestra página:

<br /><%@ taglib uri="/WEB-INF/tld/jmesa.tld" prefix="jmesa" %><br />

Ahora simplemente definiremos la siguiente línea:

<jmesa:tablefacade id="tag" items="${listadoDeObjetos}" var="bean"><br /> <jmesa:htmltable><br /> <jmesa:htmlrow><br /> <jmesa:htmlcolumn property="nombre" title="Nombre"><br /> <jmesa:htmlcolumn property="apellido" title="Apellido"><br /> </jmesa:htmlRow><br /> </jmesa:htmlTable><br /></jmesa:tableFacade>

Con estos simples pasos, ya podremos utilizar JMesa dentro de nuestros proyectos.

El patrón “Cadena de Responsabilidad” (Chain of Responsibility) - Parte VI

Los últimos ataques han sido todo un éxito, cada día se logran nuevas conquistas!!!. Debido a esto, Cerebro se ha visto en la necesidad de aumentar el número de robots dentro de sus tropas. Ahora su ejército se encuentra organizado en una estructura jerárquica, para lo cual ascendió a sus mejores solados a rangos como “General” o “Coronel”.

Con esta nueva estructura será mucho fácil dar órdenes a su ejército, el simplemente dará la orden a su “General Mazinger Z” quien al leer el comunicado decidirá si debe ejecutarla el o deberá derivarla a un sub-alterno; y así sucesivamente en la jerarquía hasta llegar al “Soldado El Galactico”.

Genial…..como siempre este plan es simple……es magnífico……es perfecto…….pero!!!!!!!

Cerebro se ha dado cuenta nuevamente que ha olvidado algo muy importante, su mecanismo de comunicación (implementado con el patrón “Observador”) ya no le sirve. Ahora tiene una estructura jerárquica, y necesita que la orden pase a través de esta estructura hasta el sub-alterno al que se le desee enviar este mensaje. Por lo tanto necesita un mecanismo en el cual el receptor del mensaje pueda no solo ejecutar la orden, sino también poder comunicar esta a su sub-alterno en el caso de que no fuera dirigida a él.

Una solución sería ir replicando el patrón “Observador” en cada uno de sus niveles jerárquicos, pero esta no es la solución más optima..

Debido a todos estos problemas, recurre nuevamente a su gurú “Martin Fowler” y encuentra la solución perfecta!!!!. Cerebro ha visto que el patrón “Cadena de Responsabilidad” (Chain of Responsibility) es ideal para solucionar su problema.

Primero necesitara definir la clase “Mensaje”, la cual contendrá a quien esta dirigida la orden y cuáles son las instrucciones a ejecutar.

package cadena.de.responsabilidad;<br /><br />public class Mensaje {<br /><br /> private String para;<br /> private String contenido;<br /><br /> public Mensaje(String para, String contenido) {<br /> this.para = para;<br /> this.contenido = contenido;<br /> }<br /><br /> public String getPara() {<br /> return para;<br /> }<br /><br /> public void setPara(String para) {<br /> this.para = para;<br /> }<br /><br /> public String getContenido() {<br /> return contenido;<br /> }<br /><br /> public void setContenido(String contenido) {<br /> this.contenido = contenido;<br /> }<br /> <br />}

Luego, deberá definir la clase abstracta “EjecutarOrdenAltoMando”, la cual deberán extender cada uno de los elementos de su ejército.

package cadena.de.responsabilidad;<br /><br />abstract class EjecutarOrdenAltoMando {<br /><br /> protected EjecutarOrdenAltoMando subAlterno;<br /><br /><br /> public void setSubAlterno(EjecutarOrdenAltoMando subAlterno){<br /> this.subAlterno = subAlterno;<br /> }<br /><br /> public abstract void ejecutarOrden(Mensaje mensaje);<br /><br />}

Ahora, cada sub-alterno que extienda la clase abstracta, deberá definir un mecanismo que permita discriminar si la orden enviada la debe ejecutar el, o en caso contrario, enviar la orden a su sub-alterno.

package cadena.de.responsabilidad;<br /><br />class GeneralMazingerZ extends EjecutarOrdenAltoMando {<br /><br /> public void ejecutarOrden(Mensaje mensaje){<br /> if (mensaje.getPara().equals("OrdenGeneral")){<br /> System.out.println(mensaje.getContenido());<br /> }<br /> else if (subAlterno != null){<br /> subAlterno.ejecutarOrden(mensaje);<br /> }<br /> }<br /><br />}

package cadena.de.responsabilidad;<br /><br />class CoronelElVengador extends EjecutarOrdenAltoMando {<br /><br /> public void ejecutarOrden(Mensaje mensaje){<br /> if (mensaje.getPara().equals("OrdenCoronel")){<br /> System.out.println(mensaje.getContenido());<br /> }<br /> else if (subAlterno != null){<br /> subAlterno.ejecutarOrden(mensaje);<br /> }<br /> }<br /><br />}

package cadena.de.responsabilidad;<br /><br />class SoldadoElGalatico extends EjecutarOrdenAltoMando {<br /><br /> public void ejecutarOrden(Mensaje mensaje){<br /> if (mensaje.getPara().equals("OrdenSoldado")){<br /> System.out.println(mensaje.getContenido());<br /> }<br /> else{<br /> System.out.println("EL TIPO DE ORDEN NO EXISTE");<br /> }<br /> }<br /><br />}

Finalmente, será muy fácil para Cerebro enviar un mensaje a su ejército, el simplemente dará la orden a su “General” y listo!!

package cadena.de.responsabilidad;<br /><br />public class Cerebro {<br /><br /> public static Mensaje[] generarMensajes(){<br /> Mensaje mensajes [] = {<br /> new Mensaje("OrdenGeneral", "Ejecutar Orden General Mazinger Z"),<br /> new Mensaje("OrdenCoronel", "Ejecutar Orden Coronel El Vengador"),<br /> new Mensaje("OrdenSoldado", "Ejecutar Orden Soldado El Galatico"),<br /> new Mensaje("OrdenCoronel", "Ejecutar Orden Coronel El Vengador"),<br /> new Mensaje("OrdenGeneral", "Ejecutar Orden General Mazinger Z"),<br /> new Mensaje("OrdenSoldado", "Ejecutar Orden Soldado El Galatico") <br /> };<br /> return mensajes;<br /> }<br /><br /> public static EjecutarOrdenAltoMando configurarCadena(){<br /> EjecutarOrdenAltoMando generalMazingerZ = new GeneralMazingerZ();<br /> EjecutarOrdenAltoMando coronelElVengador = new CoronelElVengador();<br /> EjecutarOrdenAltoMando soldadoElGalatico = new SoldadoElGalatico();<br /> generalMazingerZ.setSubAlterno(coronelElVengador);<br /> coronelElVengador.setSubAlterno(soldadoElGalatico);<br /> return generalMazingerZ;<br /> }<br /><br /> public static void main(String[] args) {<br /> EjecutarOrdenAltoMando generalMazingerZ = configurarCadena();<br /> for(Mensaje mensaje : generarMensajes()){<br /> generalMazingerZ.ejecutarOrden(mensaje);<br /> }<br /> }<br /><br />}

Cerebro lo ha conseguido nuevamente, ha logrado diseñar un nuevo mecanismo de comunicación para su ejército, continuando su malvado plan………“TRATAR DE CONQUISTAR AL MUNDO!!!!”