Java Design Patterns

Design Patterns are general reusable solution to commonly occurring problems. These are the best practices, used by the experienced developers. Patterns are not complete code, but it can use as a template which can be applied to a problem. In other words, we can think of
patterns as a formal document which contains recurring design problems and its solutions

Creational Patterns Structural Patterns Behavioral Patterns
Factory Adapter Strategy
Builder Composite Iterator
Prototype Facade Observer
Singleton State

Pattern name, is used to provide a single and meaningful name to the pattern which defines a design problem and a solution
for it. Naming a design pattern helps itself to be referred to others easily. It also becomes easy to provide documentation for
and the right vocabulary word makes it easier to think about the design

The problem describes when to apply the pattern. It explains the problem and its context. It might describe specific design
problems such as how to represent algorithms as objects. It might describe a class or object structures that are symptomatic of
an inflexible design. Sometimes the problem will include a list of conditions that must be met before it makes sense to apply
the pattern.

The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations. The
solution is not the complete code, but it works as a template which can be fulfilled with code. Instead, the pattern provides an
abstract description of a design problem and how a general arrangement of elements (classes and objects in our case) solves it.

The results and consequences of applying the pattern. The consequences for software often concern space and time trade-
offs. They may address language and implementation issues as well. Since reuse is often a factor in object-oriented design, the
consequences of a pattern include its impact on a system’s flexibility, extensibility, or portability. Listing these consequences
explicitly helps you understand and evaluate them.

Why use them? Because of: Flexibility, reusability, shared vocabulary, capture best practices.

Adapter:

Facade:

Composite:

Singleton:

When to use Singleton? There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point

Observer:

When to use Observer?

  • When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets you vary
    and reuse them independently.
  • When a change to one object requires changing others, and you don’t know how many objects need to be changed.
  • When an object should be able to notify other objects without making assumptions about who these objects are. In other words,
    you don’t want these objects tightly coupled.

Builder:

When to use Builder?

  • The algorithm for creating a complex object should be independent of the parts that make up the object and how they’re
    assembled.
  •  The construction process must allow different representations for the object that’s constructed.

Factory:

When to use Factory?

  • A class can’t anticipate the class of objects it must create.
  • A class wants its subclasses to specify the objects it creates.
  • Classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper
    subclass is the delegate.

State:

When to use State?

  • An object’s behavior depends on its state, and it must change its behavior at run-time depending on that state.
  • Operations have large, multipart conditional statements that depend on the object’s state. This state is usually represented by one or more enumerated constants. Often, several operations will contain this same conditional structure. The State pattern puts each branch of the conditional in a separate class. This lets you treat the object’s state as an object in its own right that can
    vary independently from other objects.

Strategy:

When to use Strategy?

  • Many related classes differ only in their behavior. Strategies provide a way to configure a class with one of many behaviors.
  • You need different variants of an algorithm. For example, you might define algorithms reflecting different space/time trade-offs.
    Strategies can be used when these variants are implemented as a class hierarchy of algorithms.
  • An algorithm uses data that clients shouldn’t know about. Use the Strategy pattern to avoid exposing complex, algorithm-
    specific data structures.

Iterator:

When to use Iterator?

public void pintar() {
Figura unaFig;
Iterator it = lFiguras.iterator();
while (it.hasNext(){
unaFig=it.next();
unaFig.pintar();
}
}

(Resume: Patter which reflects a “while loop” with helpful methods. Using a List would be a kind of Iterator Pattern use)

 

 

Acerca de S. Vergara

Quiero compartir mis experiencias y mis humildes conocimientos
Esta entrada fue publicada en Backend, Java, UML. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s