2006-01-22

Briefing : Design Patterns (Erik & Elisabeth Freeman)


Este es nuestro primer briefing sobre un libro técnico para profesionales de las TIC interesados en mejorar las técnicas de programación (Design Patterns de la editiorial O'Reilly). Porque aunque nos llenamos la boca sobre la programación orientada a objectos (OO) mi experiencia me dice que poca gente la aplica de forma adecuada al 100% , A veces por defecto a veces por exceso conseguir un modelo de programación que sea antetodo mantenible es la clave para obtener un software de calidad.
Calidad, en informática siempre va ligado a mantenibilidad y explotación; si un código no es mantenible , extensible y explotable de forma óptima seguro que no estará correctamente diseñado.
Este libro prestado, cortesía de un compañero y amigo (RamonMaría), nos detalla de forma amena, los principales patrones de programación con ejemplos através de un lenguaje de proposito general como Java, pero que se puede trasladar a cualquier lenguaje que disponga de los principios fundamentales de la OO. Es un libro muy básico para entrar en el mundo de los patrones pero que permite orientar al analista informático hacia el camino de la iluminación del código de calidad.

Aquí os dejo el pequeño resumen que he realizado en su versión original , un inglés muy básico que se lee con facilidad...

Extracto de “Head First Design Patterns”

A Pattern is a solution to a problem in a context.

The context is the situation in which the pattern applies. This should be a recurring situation.

The problem refers to the goal you are trying to achieve in this context, but it also refers to any constraints that occur in the context.

The solution is what you’re after:a general design that anyone can apply which resolves the goal and set of constraints.

OO Basics : Abstraction, Encapsulation, Polymorphism, Inheritance.

Design Principle :

- Identify the aspects of your application that vary and separate them from what stays the same.

- Program to an interace, not an implementation. (“Program to an interface” really menas “Program to a supertype”).

- Favor composition over inheritance.

- Strive for llosely coupled designs between objects that interact.

- Classes should be open for extension, but closed for modification.

- Depend upon abstractions. Do not depend upon concrete classes.

- Principle of Least Knowledge talk only to your immediate friends.

- The Hollywood Principle : Don’t call us, we’ll call you.

- A class should have only one reason to change.

Explain Patterns

The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchageable. Strategy lets the algorithm vary independently from clients that use it.

Publishers + Subscribers = Observer Pattern
The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.

The Decorator Pattern attaches additional responsabilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

The Factory Method Pattern defines an interface for creating an object, buy lets subclasses decide which class to instantiate. Factory method lets a class defer instantiation tu subclasses.

The Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes.

The Singleton Pattern ensures a class has only one instance, and provides a global point of access to it.

The Command Pattern encapsulates a request as an object, thereby letting you parameterize other objects with different requests, queue or log requests, and support undoable operations.

The Adapter Pattern converts the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. Facade defines a higherlevel interface that makes the subsystem easier to use.

The Template Method Pattern defines the skeleton of an algorithm in a method, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

The Iterator Pattern provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

The Composite Pattern allows you to compose object into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

The State Pattern allows an object to alter its behavior when its internal state changes. The object will appear to change its class.

The Proxy Pattern provides a surrogate or placeholder for another object to control access to it.

A Compound Pattern combines two or more patterns into a solution that solves a recurring or general problem.


An Anti-Pattern tells you how to go from a problem to a BAD solution.

Others Patterns

Bridge : Use the Bridge Pattern to vary not only your implementations, buy also your abstractions.

Builder : use the Builder Pattern to encapsulate the construction of a product and allow it to be constructed in steps.

Chain of Responsibility : use the Chain of Responsability Pattern when you want to give more than one object a chance to handle a request.

Flyweight : Use the Flyweight Pattern when one instance of a class can be used to provide many “virtual instances”.

Interpreter : Use the Interpreter Pattern to build an interpreter for a language.

Mediator : Use the Mediator Pattern to centralize complex communications and control between related objects.

Memento : Use the Memento Pattern when you need to be able to return an object to one of its previous states; for instance, if your user requests an “undo”.

Prototype : Use the Prototyp Pattern when creating an instance of a given class is either expensive or complicated.

Visitor : Use the Visitor Pattern when you want to add capabilities to a composite of objects and encapsulation is not important.


Technoratis Tags : JAVA, OO, OrientadoObjeto, Patrones, Informática, Código , HeadFirst.

No hay comentarios:

Publicar un comentario en la entrada