Design pattern

The design patterns are techniques for solving common problems in software development and other fields related to interaction or interface design.

A design pattern turns out to be a solution to a design problem. For a solution to be considered a pattern, it must possess certain characteristics. One of them is that you must have proven its effectiveness by solving similar problems on previous occasions. Another is that it should be reusable, which means that it is applicable to different design problems in different circumstances.

History

In 1979 the architect Christopher Alexander contributed to the world of architecture the book The Timeless Way of Building; in it he proposed the learning and use of a series of patterns for the construction of higher quality buildings, in which that higher quality referred to ancient architecture and the lower quality corresponded to modern architecture, that breaking with architecture Antigua had lost that connection to what people thought of as quality.

In the words of this author, "Each pattern describes a problem that occurs an infinite number of times in our environment, as well as the solution to it, in such a way that we can use this solution a million times later without having to I have to think about it again."

The patterns that Christopher Alexander and his colleagues defined, published in a volume called A Pattern Language, are an attempt to formalize and capture generations of architectural knowledge in a practical way. Patterns are not abstract principles that require rediscovery for successful application, nor are they specific to a particular situation or culture; they are something in between. A pattern defines a possible correct solution to a design problem within a given context, describing the invariant qualities of all solutions. Among Christopher Alexander's solutions are how cities should be designed and where doorknobs should go.

Later, in 1987, Ward Cunningham and Kent Beck, overwhelmed by the poor training new object-oriented programmers received, wondered how good ideas could be captured and then somehow passed on to new programmers. programmers newly trained in inheritance and polymorphism. Reading Alexander, they realized the parallel between good architecture proposed by Alexander and good OO architecture, so they used several of Alexander's ideas to develop five patterns of human-computer interaction (HCI) and published a paper in OOPSLA- 87 titled Using Pattern Languages for OO Programs.

However, it wasn't until the early 1990s that design patterns found great success in the computer world after the publication of the book Design Patterns written by the group Gang of Four (GoF) composed of Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, which collected 23 common design patterns.

Objectives of patterns

Design patterns are intended to:

• Provide reusable element catalogs in the design of software systems.
• Avoid reiteration in the search for solutions to problems already known and previously solved.
• Formalize a common vocabulary among designers.
• Standardize the way the design is made.
• Facilitate learning to new generations of designers by condensing existing knowledge.

Furthermore, they do not intend to:

• Impose certain design alternatives in front of others.
• Eliminate the creativity inherent in the design process.

It is not mandatory to use the patterns, it is only advisable in the case of having the same or similar problem that the pattern solves, always keeping in mind that in a particular case it may not be applicable. "Abusing or forcing the use of patterns can be a mistake".

Pattern Categories

According to the scale or level of abstraction:

• Architecture patterns: Those who express a fundamental structural organizational scheme for software systems.
• Design patterns: Those who express schemes to define design structures (or their relationships) with which to build software systems.
• Dialects: Low-level patterns specific to programming language or specific environment.

In addition, it is also important to note the concept of "design anti-pattern", which in the form of a pattern, tries to prevent against common design errors in software. The idea of anti-patterns is to make known the problems that certain very frequent designs cause, to try to avoid that different systems end up again and again in the same dead end for having made the same mistakes.

Structures or pattern templates

To describe a pattern, more or less standardized templates are used, so that they are expressed uniformly and can effectively constitute a uniform means of communication between designers. Several eminent authors in this area have proposed slightly different templates, although most define the same basic concepts.

The most common template is the one used precisely by the GoF and consists of the following sections:

• Pattern name: standard name of the pattern by which it will be recognized in the community (usually expressed in English).
• Pattern classification: creational, structural or behavioral.
• Intention: What is the problem of solving the pattern?
• Also known as: Other common use names for the pattern.
• Motivation: Example stage for the application of the pattern.
• Applicability: Common uses and pattern applicability criteria.
• Structure: Timetables of classes to describe the classes involved in the pattern.
• Participants: Enumeration and description of the abstract entities (and their roles) that participate in the pattern.
• Collaborations: Explanation of the interrelations between the participants.
• Consequences: Positive and negative consequences in the design derived from the application of the pattern.
• Implementation: Appropriate techniques or comments for the implementation of the pattern.
• Example code: Source code example of pattern implementation.
• Known uses: Examples of real systems that use the pattern.
• Related patterns: Cross references with other patterns.

List of main GoF (Gang Of Four) patterns

Creational Patterns

They correspond to software design patterns that solve instantiation problems. They help us to encapsulate and abstract that creation:

• Object Pool (does not belong to the patterns specified by GoF): creates a set of initialized objects prepared for use, rather than creating them on demand. It is useful when creating these objects is costly (e.g. by creating an object that manages a connection with a database).
• Abstract Factory (abstract factory): allows you to work with objects from different families so that families do not mix with each other and make transparent the type of specific family being used. The problem to be solved by this pattern is to create different families of objects, such as creating graphical interfaces of different types (window, menu, button, etc.).
• Builder (virtual construction): Abstracts the process of creating a complex object, centralizing that process at a single point.
• Factory Method (manufacturing method): it centralizes in a construction class the creation of objects of a subtype of a certain type, hiding the user from the casuistics, that is, the diversity of particular cases that can be foreseen, to choose the subtype to create. Part of the principle that subclasses determine the class to implement. Below is an example of this pattern:

class ConcreteCreator extensions Creator{ protected Product factoryMethod(){ return new ConcreteProduct(); !!interface Product{... !class ConcreteProduct implements Product{... !public class Client{ public static void main(String args[]){ Creator aCreator = new ConcreteCreator(); Product aProduct = aCreator.factoryMethod();!!

• Prototype (prototype): creates new objects cloning them from an existing instance.
• Singleton (unique substance): guarantees the existence of a single instance for a class and the creation of a mechanism for global access to such an instance. Restrict the instance of a class or value of a type to a single object. Below is an example of this pattern:

public sealed class Singleton{ private static volatile Singleton instance; private static object syncRoot = new Object(); private Singleton() { System.Windows.Forms.MessageBox.Show("New Singleton"); ! public static Singleton GetInstance { get { if (instance ♪ null) { Lock(syncRoot) { if (instance ♪ null) instance = new Singleton(); ! ! return instance; ! !!

• Model View Controller (MVC) In Spanish: Model View Controller. It is a software architecture pattern that separates data and business logic from an application from the user interface and the module responsible for managing events and communications. This pattern poses the separation of the problem in three layers: the layer modelwhich represents reality; the layer controller , which knows the methods and attributes of the model, receives and performs what the user wants to do; and the layer View, which shows a look of the model and is used by the previous layer to interact with the user.

Structural Patterns

These are software design patterns that solve problems of composition (aggregation) of classes and objects:

• Adapter or Wrapper (Adapter or Wrapper): Adapts an interface so that it can be used by a class that otherwise could not use it.
• Bridge (Point): Disappears an abstraction of its implementation.
• Composite (Composite object): It allows to treat composite objects as if it were a simple one.
• Decorator: Adds functionality to a class dynamically.
• Facade (Fachada): It provides a simple unified interface to access a subsystem interface or interface group.
• Flyweight (Light weight): Reduces redundancy when many objects have identical information.
• Proxy: Provides an intermediary of an object to control your access.
• Module: Group several related elements, such as classes, singletons, and methods, used globally, in a single entity.

Behavioral patterns

They are defined as software design patterns that offer solutions regarding the interaction and responsibilities between classes and objects, as well as the algorithms that encapsulate:

• Chain of Responsibility (Cadena de responsabilidad): It allows you to set the line that the messages should take to make the objects perform the task.
• Command (Orden): Encapsulates an operation in an object, allowing to execute such operation without knowing the contents of it.
• Interpreter: Given a language, defines a grammar for that language, as well as the tools necessary to interpret it.
• Iterator (Iterator): It allows you to perform tours on composite objects regardless of their implementation.
• Mediator (Mediator): Defines an object that coordinates communication between objects of different classes, but that work as a set.
• Memento (Record): Allows you to return to previous states of the system.
• Observer (Observer): Defines a unit of one-to-many objects, so that when an object changes in status all objects that depend on it are automatically notified and updated.
• State (State): Allows an object to change its behavior whenever it changes its internal status.
• Strategy (Strategy): It allows you to have several methods to solve a problem and choose which one to use in execution time.
• Template Method: Defines in an operation the skeleton of an algorithm, delegating in the subclasses some of its steps, this allows the subclasses to redefine certain steps of an algorithm without changing its structure.
• Visitor (Visitor): It allows to define new operations on a class hierarchy without modifying the classes on which it operates.

Interaction patterns

The first attempt to apply this concept to user interface design was made by Ward Cummingham and Kent Beck who adapted C. Alexander's proposal and created five interface patterns: Window per task, Few panes, Standard panes, Nouns and verbs, and Short Menu. In more recent years, researchers such as Martin Van Welie and Jennifer Tidwell have developed collections of interaction patterns for the World Wide Web. In these collections, they capture the experience of expert programmers and designers in the development of usable interfaces and condense this experience into a series of guides or recommendations that can be used by novice developers so that in a short time they acquire the ability to design interfaces that affect user satisfaction. The interaction patterns seek the reuse of efficient interfaces and optimal management of web page resources, making the consumption of time in the design of the website more efficient and allowing novice programmers to acquire more experience.

Application in specific areas

In addition to its direct application in the construction of software in general, and derived precisely from the great success they have had, design patterns have been applied to multiple specific areas, producing "pattern languages" and extensive "catalogues" by various authors.

In particular, the efforts in the following areas are notable:

• User interface patterns, that is, those that try to define the best ways to build man-machine interfaces (see Person-Computer Interaction, User Graphic Interface).
• Patterns for the construction of business systems, where special efforts are required in software infrastructures and an important level of abstraction to maximize factors such as scalability or system maintenance.
• Patterns for system integration (see Integration of Business Applications), i.e., for intercommunication and coordination of heterogeneous systems.
• Workflow patterns, this is for the definition, construction and integration of abstract workflow management systems and processes with business systems. See also BPM.