01 J2EE patrones

Conceptos básicos

Patrones

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

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

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

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

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a 01 J2EE patrones

Semelhante a 01 J2EE patrones (20)

Último

Último (20)

01 J2EE patrones

Notas do Editor