01 J2EE patrones

© Copyright 2011. All rights reserved. Ernesto del Puerto. 1

Conceptos básicos

Patrones

© Copyright 2011. All rights reserved. Ernesto del Puerto 2

Patrones de diseño y de arquitectura

Un arquitecto planifica los sistemas utilizando un proceso de razonamiento basado en patrones.

Un arquitecto debe estar familiarizado con una variedad de catálogos de patrones para ser efectivo.

Tipos de patrones:

Los patrones de diseño definen la estructura y el comportamiento de componentes OO de software reutilizables que permitan realizar los requerimientos funcionales.

Los patrones de arquitectura definen la estructura y el comportamiento del sistema y de los subsistemas para cumplimentar los requerimientos no funcionales


Patrones de diseño

A software pattern is a “description of communicating objects and classes that are customized to solve a general design problem in a particular context.” (Gamma, Helm, Johnson, and Vlissides page 3)

Está inspirado en los patrones de la arquitectura tradicional (construcción de edificios)

Los elementos esenciales de un patrón son:

Nombre

Problema

Solución

Consecuencias


Nivel de los patrones de software

Patrones de arquitectura:Ponen en manifiesto las estructuras de alto nivel de software y hardware

Usualmente soportan los NFRs Patrones de diseño:

Ponen en manifiesto las estructuras de nivel medio de software

Usualmente soportan los FRs

Idioms:Ponen en manifiesto las estructuras de bajo nivel de software (clases y metodos)

Usualmente soportan funcionalidades específicas del lenguaje


Los GoFs


Patrones JEE


Principio en los patrones

Existen varios principios para los patrones:Open Closed Principle (OCP)Composite Reuse Principle (CRP)Dependency Inversion Principle (DIP)

Veamos el siguiente ejemplo:


OCP – Open Close Principle

“Classes should be open for extension but closed for modification.” (Knoernschild page 8)


CRP – Composite Reuse Principle …

“Favor polymorphic composition of objects over inheritance.” (Knoernschild página 17)


… CRP – Composite Reuse Principle

CRP leads to flexible reuse through delegation


DIP – Dependency Inversion Principle …

“Depend on abstractions. Do not depend on concretions.” (Knoernschild page 12)

Una abstracción puede ser una clase abstracta


… DIP – Dependency Inversion Principle

Una abstracción puede ser una interface


Patrón Composite, descripción …

“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” (GoF page 163)


… Patrón Composite, descripción …

Problem (caracteristicas del problema):

You want to represent whole-part hierarchies of objects

You want to use the same interface on the assemblies and the components in an assembly

Solution (caracteristicas de la solucion) :

Create an abstract class, Component, that acts as the superclass for concrete “leaf” and Composite classes.

The Composite class can be treated as a component because it supports the Component class interface.



El modelo del patrón Composite de GoF



Modelo alternativo del patrón Composite de GoF



Participantes:

Component (Gráfico):

Declares the interface for objects in the composition

Implements default behavior for the interface common to all classes, as appropriate

Declares an interface for accessing and managing its child components

Leaf (Rectángulo, Línea, Texto, etc):

Represents leaf of objects in the composition. A leaf has no children

Defines behavior for primitive objects in the composition



Composite (Dibujo):

Defines behavior for components having children

Stores child components

Implements child-related operations in the Component interface

Client:

Manipulates objects in the composition through the Component interface


… Patrón Composite, descripción

Consequences:

Makes the client simple

Makes it easier to add new kinds of components

Can make the design model too general


Patrón Strategy, descripción

“Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.” (GoF page 315)


Introducing Creational Patterns

Creational patterns hide the details of object creation.

Pattern Primary Function

Factory Method Creates objects of a class or its subclasses through a method call

Abstract Factory Creates a family of objects through a single interface

Singleton Restricts a class to one globally accessible instance


Applying the Singleton Pattern

Example Problem

The hotel system uses a pool of threads to invoke processing

There should only be one instance of the thread pool so that all parts of the application are borrowing threads from the same pool

The thread pool must be easily accessible throughout the application

Problem Forces

There are some classes that are intended to only have a single instance

The single instance of a class may need to be easily accessible to different parts of the application

The only way to secure a constructor is to hide it


Singleton Pattern Structure

Three steps are needed to create a Singleton class:

1. The Singleton class’ constructor is private or protected, hiding it from client view

2. The Singleton class has a private static reference to the only instance of itself

3. The Singleton class has a public static method that returns the single instance


Singleton structure code

public class Singleton {

private static Singleton uniqueInstance;

public static Singleton getInstance( ) {

if (uniqueInstance == null) {

uniqueInstance = new Singleton();

}

return uniqueInstance;

}

private Singleton( ) {

}

//Add attributes and methods for class functionality

}


Singleton Pattern Example Solution


Applying the Singleton Pattern

Consequences

Advantages:

A client can easily obtain a reference to the single object

A singleton can construct the instance at the class loading time or on-demand

Singleton can guard several instances at once, not just one

Disadvantages:

Singleton can replace global variables, but this hint is often misapplied

Singleton must make on-demand instances thread-safe


Bibliografía

Design Petterns. Elements of Reusable Object-Oriented Software. E. Gamma, R. Helm, R. Johnson y J. Vlissides. Addison-Wesley. 32nd. Printing. April 2005. ISBN: 0201663612.

SL-500. J2EE Patterns. Student Guide. Sun Education. Revision C. 2003.

Patterns of Enterprise Application Architecture. Martin Fowler. Addison-Wesley. Thirteenth Printing. October 2007. ISBN: 0-321-12742-0.

Head First Design Patterns. Eric y Elisabeth Freeman. O’Reilly. First Edition. October 2004. ISBN: 0-596-00712-4.

01 J2EE patrones

Technology

Transcript of 01 J2EE patrones