Design patterns are sets of solutions to common design problems that occur over and over in development. They work as a solution template in which an abstract solution for a common problem is described and the user then applies it, adapting it to their problem. In object-oriented programming, the design pattern provides a way to design reusable classes and objects for a specific problem as well as defining the relationship between objects and classes. In addition, design patterns provide a common idiom among programming languages that allows architects and software developers to communicate about a common and recurring problem regardless of the programming language they are using. With this, we are able to identify a problem and its solution by the name of the pattern and thinking about a solution by a model point of view in a high abstraction level of language programming details.

The design patterns theme gained strength in 1994 after the Gang of Four (formed by Rich Gamma, Richard Helm, Ralph Johnson, and John Vlissides) wrote Design Patterns: Elements of Reusable Object‐Oriented Software. Here, they described 23 design patterns that were later known as GoF design patterns and are still used today. 

The Gang of Four (GoF) design patterns are 23 patterns that are classified as creational patterns, structural patterns, and behavioral patterns. The creational patterns control the creation and initialization of the object and class selection; the structural patterns define the relationship between classes and objects, and the behavioral patterns control the communication and interaction between objects. As well as this, the GoF design patterns have two types of scope which define the focus of solutions. These scopes are object scope, which resolves problems about object relations, and class scope, which resolves problems about class relations. 

The object scope works with composition and the behavior changes are done in a runtime. Thus, the object can have a dynamic behavior. The class scope works with inheritance and its behavior is static-fixed at compile-time way. Then, to change the behavior of a class-scope pattern, we need to change the class and recompile.

Patterns classified as class scope solve problems about the relationship between classes and are static (fixed at compile time and cannot be changed once compiled). However, patterns classified under the object scope solve problems about the relationship between objects and can be changed at runtime.

The following diagram shows us the three classifications, as well as their patterns and scope:

In the preceding diagram, we can see the Factory Method pattern on the Class section and the Abstract Factory pattern on the Object section. This occurs because the Factory Method works with inheritance and the abstract method pattern works with composition. Then, the Factory Method is static-fixed at compile time and cannot be changed after compilation. However, the Abstract Factory is dynamic and can be changed at runtime.

GoF design patterns are generally described using a graphical notation such as a use case diagram, and an example of the implementation's code. The used notation must be able to describe the classes and objects as well as the relationship between these classes and objects. 

The pattern's name is an important part of the design patterns. This is because it is what the developer uses to quickly identify the problem related to the pattern and to understand how the pattern will solve it. The name of the pattern must be brief and refer to the problem and its solution.

A design pattern is a great tool for designing software development, but its use needs to be analyzed to determine if the design pattern is really required in order to solve the problem.

Names of design patterns need be succinct, making them easy to identify. This is because design patterns create a vocabulary for communicating between developers independent of programming language, permitting developers to identify problems and solutions only by name of a design pattern.

In design patterns, a catalog is a set of pattern names which are designed to permit a better communication between developers.

The catalog of GoF's design patterns has 23 patterns, as shown in the preceding diagram. Here is a description of these patterns: 

• Abstract Factory: This provides an interface to create objects without specifying their concrete class, making it possible to decouple the business logic and the object creation logic. With this, we can update the object creation logic in an easy way.
• Adapter: This provides an interface that makes it possible for two incompatible interfaces to work together. The adapter pattern works as a bridge between interfaces, adapting these interfaces to work together. Furthermore, the adapter can adopt a class or objects.
• Bridge: This pattern decouples an abstraction from its implementation, making them vary independently. With this, we can modify the implementations without impacting the abstractions and we can also modify the abstractions without impacting the implementations. The class of abstraction hides implementations and its complexity.
• Builder: This pattern separates the construction of a complex object from its representation. With this, we can construct the objects of several representations using the same process to that. Thus, we create a standard process of construction of objects that have a complex process to construct. 
• Chain of responsibility: This pattern avoids coupling the sender and receiver of a request creating some objects that have a chance to treat the requests. These objects create a chain of receiver objects for a sender's request. Each object of this chain receives the request and verifies whether or not it will treat this request. 
• Command: This pattern encapsulates a request for an object and creates a wrapper of requests containing their information about the request. With this, we can do a request to some object sending parameters without knowing about this operation. Furthermore, the command permits us to execute an undo operation.
• Composite: This pattern composes objects into a tree structure, which represents a part-whole hierarchy. It permits you to treat a group of objects as a single object.
• Decorator: This pattern permit extends a functionality of a class with flexibility, without use subclass. It allows you to dynamically attach a new responsibility to an object.
• Facade: This hides the complexity of the system, applying a unified interface to a set of interfaces on a subsystem. This makes the subsystem easy to use.
• Factory Method: This defines an interface for creating an object, and the subclass states which class to initiate. 
• Flyweight: This uses sharing to efficiently support a large number of fine-grained objects. This pattern reduces the number of objects created.
• Interpreter: This pattern represents language grammar and uses it to interpret them as sentences of a language.
• Iterator: This pattern provides a way to sequentially access the elements of a set of objects without knowing its underlying representation.
• Mediator: This reduces the complexity of communication by creating an object that encapsulates all the communication and interaction between objects.
• Memento: This pattern captures the object's internal states without hurting encapsulated concepts, with this, the state of the object can be restored by the object. This pattern works as a backup that maintains the current state of an object.
• Observer: This defines a one-to-many dependency between objects. This means that if one object is modified, all of its dependents are automatically notified and updated.
• Prototype: This pattern permits us to create a new object using an object or instance as a prototype. This pattern creates a copy of an object, creating a new object with the same state of the object used as a prototype. 
• Proxy: This pattern creates a surrogate object (proxy object) for another object (original object) in order to control the access to the original object.
• State: This permits an object to alter its behavior when its internal state changes.
• Singleton: This ensures that a class has only one instance in the entire project, and the same instance of the object is returned every time the creation process is performed/run.
• Strategy: This creates a family of algorithms, encapsulating each one and making them interchangeable. This pattern permits you to change the algorithm at runtime.
• Template method: This defines a skeleton for an algorithm in an operation, and the subclass defines some steps to the algorithm. This pattern algorithm structure and the subclass redefine some steps of this algorithm without modifying its structure.
• Visitor: This represents an operation to be performed on an object structure. This pattern permits us to add new operations to an element without modifying its class. 

Creating an object-oriented design is a tough task. This is because we have several important elements to think about with regard to the scenario that we'll work in and the problem we'll solve. This includes defining the appropriate objects that we need to create in order to reach the solution; defining the granularity of objects and looking at what interfaces we need to create. These tasks need to be addressed during the creation process in design. Objects can be created to represent a real-world object or to represent a process with its algorithms and responsibilities. Furthermore, we even need to consider the number of objects, their size, and the interface we need to access. 

Design patterns are great tools for helping us to identify classes and objects that don't represent real-world objects and objects that are less-obvious abstractions. Moreover, design patterns help us to apply the finest granularity to objects and they also allow us to analyze a problem and solution as a model. Design patterns make the design flexible, providing a decoupling between classes and objects. They also provide the ability to organize solutions, allowing delegate responsibilities to classes with the best way.

Building software is an expensive process for companies because it requires capable professionals and infrastructure to build and maintain the software. Design patterns, with their flexibility and decoupled design, make maintenance easy and therefore decrease its cost.

All GoF patterns have a good purpose and solve major problems of object-oriented design, but some patterns are most commonly used in the Java and Java EE ecosystem. In this book, these patterns are treated as basic design patterns because they are most commonly used to implement solutions on Java's APIs, frameworks, and algorithms. Consequently, understanding these patterns will help us to understand these APIs, frameworks, and algorithms, and we'll, in turn, be able to create a better solution using Java. These patterns are Singleton, Abstract Factory, Facade, Iterator, and Proxy.

In a software project, in some solutions, we may want to ensure that a class has only one instance of an object throughout the project and that this object is accessible at any point in the project. Creating a global instance or static instance will not ensure that this class will not be used at another point in another instance. The best way to solve this is by using the Singleton pattern, which ensures that there is only one instance of a class in the entire project. In the following diagram, we are showing the structure of Singleton and how it is designed:

Here, we have one class called Singleton which has a private constructor, as well as a reference variable of Singleton and a method for returning its unique instance. A good example of an application is a situation in which we want to create a class responsible for application configurations (paths to some resource, parameters to access filesystems, behaviors of the environment). Often, the application has some configurations and we need a class to represent these application configurations. Thus, this class of application configuration doesn't need various instances, but only one instance. 

Another application of Singleton is when we want to create an Abstract Factory that will be explained in the following subsection. Generally, we will have only one Abstract Factory throughout the application. With this, we can use a Singleton to guarantee that we will have only one instance of Abstract Factory.

This pattern is often used in frameworks and APIs, but it is common for this pattern to be found in the code of projects, mainly on Java EE.

The use of the Singleton pattern can be a good practice depending on the scenario, but depending on the scenario the use of Singleton can be a bad practice. The Singleton should not be used when the object is stateful and maintain a state, because with Singleton the same instance of the object is shared by all processes of application and if some process updates a state of this object all processes of application will be impacted by this update. Furthermore, we can have a problem with the concurrent update of the state of a Singleton.

Sometimes, we need to create a family of objects in a project. Imagine that we have an e-commerce and we have various kinds of products such as cell phones, notebooks, and tablets. These products are objects of the same family. If we create objects throughout a software, we will face problems if we then need to modify the initialization process of this object.

Using Abstract Factory will help us to solve problems including a system which should be independent of how its products are created, a system that should use one of the multiple families of products, and a system that should work with objects which are designed to be used together. Using this pattern will be beneficial as it isolates concrete classes. This means that with this pattern, we can control which class of objects that can be initiated on software. Furthermore, it permits the exchange of products easily and provides consistency among products.

The Abstract Factory pattern creates a single point of creation for objects and if we need to change the algorithm of object creation, we need only modify the concrete factory. In the following diagram, you can see the structure of Abstract Factory and how it is designed:

In our example, the Abstract Factory's structure has three main classes—AbstractFactory, Product, and Sale. The concrete classes of AbstractFactory are CellPhoneFactory, NotebookFactory, and TabletFactory. CellPhoneFactory is a concrete class responsible for creating the concrete classes CellphoneProduct and CellphoneSale, NotebookFactory is a concrete class responsible for creating the concrete classes NotebookProduct and NotebookSale, and the TabletFactory is a concrete class responsible for creating the concrete classes TabletProduct and TabletSale. A Client is a class responsible for using AbstractFactory to create AbstractProduct and AbstractSale. The concrete factory is created at runtime and it then creates the concrete product and sale.

The Abstract Factory pattern is sometimes used with another pattern such as Singleton, which we described earlier. Abstract Factory is a single point of creation, and often we need only one instance of it in an entire system. With this, using a Singleton pattern can help us create a design better and more efficiently.

This pattern is often used in frameworks and APIs that have a difficult creation process for an object, such as connections or sessions.

Projects can sometimes turn out to be very complex and big, making them difficult to design and organize. To solve this, a great solution is to break a system into subsystems (divide and conquer) and make them less complex and better organized.

The Facade pattern creates a higher-level interface to hide a complexity of a set of interfaces in a subsystem. This pattern reduces the complexity and coupling, minimizing communication and dependencies between subsystems. In the following diagram, you can see the structure of Facade and how it is designed:

In the preceding diagram, we can see the Facade pattern encapsulating all of the calls to subsystems and hiding these calls from the client. The system has one interface, Facade, and the client calls this interface in order to call subsystems. Thus, clients does not call the subsystems directly. With this solution, the client doesn't need to know about the subsystem and its complexity.

This pattern is often used in projects and systems that have high complexity and need to be broken down into subsystems.

Imagine that we want a way to access elements of an aggregate object sequentially without exposing its internal structure. The Iterator pattern does just that.

The Iterator pattern is responsible for sequentially accessing the aggregate object and defining an interface to access the elements without exposing the internal structure. This interface doesn't put a new element on the aggregate object, but simply reads elements to it. In the following diagram, you can see the structure of an Iterator and how it is designed:

In the preceding diagram, we can see the Aggregate and Iterator interfaces with their concrete subclasses. The client is the class that uses the Iterator to access elements of Aggregate.

This pattern is used on Java collections such as list, deque, and set. Understanding this pattern will help you to understand Java collections.

Sometimes, creating a new object can be a big process and several rules can be involved in creating this object. Imagine that we want to create a list of objects, and these objects represent telecommunication equipment, which has a lot of calculus to generate the information of each object. As well as this, these objects will not be accessed at the same time but will be accessed on demand. A good strategy is to create each object when it is accessed, thereby minimizing the cost and time it takes to create all objects and only access some. The Proxy can help us to solve this.

The Proxy pattern is a pattern that surrogates an object instance (original object) to another object instance (Proxy object) that permitting access control to the original object. In the following diagram, you can see the structure of Proxy and how it is designed:

From the preceding diagram, we can see a structure of the Proxy pattern. If Subject is an interface that clients use to access object operations, then RealSubject is the class of the original object and Proxy is the class that works as a Proxy. Then, when the client accesses the object, they will access the Proxy object, and the Proxy object will then access the RealSubject object and return this object to the client.

This pattern is used in frameworks and APIs that implement JPA specification and object relational mapping (ORM).

Over time, technology has evolved and new tools have emerged and helped to change some areas. Seeing the potential of these technologies, organizations increasingly began to use and invest in these tools to automate their processes and optimize their costs. These tools then began to be referred to as enterprise software.

Enterprise software is a type of software widely used in organizations, companies, or governments that provide a service to make their processes better and optimize the cost and efficiency. Over time, the complexity of this software increased as they began to provide a lot of services. As different services demanded more communication, scalability became increasingly important. With this, some problems surfaced.

Enterprise patterns is a set of solutions for common problems that appear in enterprise software as a result of the complexity of enterprise environments. Many enterprise patterns are based on GoF patterns and differ only in the way in which we implement them. On Java EE, enterprise patterns are divided into three groups: presentation patterns, business patterns, and integration patterns. These patterns act on the presentation tier, business tier, and integration patterns, and we'll cover their details in Chapter 2, Presentation Patterns, which covers presentation patterns, Chapter 3, Business Patterns, which covers business patterns, and Chapter 4, Integration Patterns, which covers integration patterns.

Enterprise patterns are very important for professionals who create software, because bad practices in the creation of software could inflate the cost and risks involved in the projects. Because of the complexity of the enterprise software, an error could propagate along the time and environment, making the enterprise environment unsustainable.

Comparing design patterns with enterprise patterns is not an easy task, because some behaviors are similar. Design patterns were the first subject that arrived, and this was covered in Design Patterns: Elements of Reusable Object-Oriented Software, written by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. These design patterns were also the base to other patterns. Enterprise patterns became necessities that design patterns cannot resolve. This is because the design patterns describe solutions for of classes and objects relationships, but the enterprise environments have other necessities such as integrations between systems and software relations. However, enterprise patterns use some design patterns to solve problems.

The principal difference between design patterns and enterprise patterns is the aim; design patterns aim to organize and optimize the object-oriented design, and enterprise patterns focus on improving the use of Java EE tools as well as making communications between Java EE components better. Design patterns are focused on object-oriented and class and object relations, whereas enterprise patterns are focused on communication between Java EE components.

The use of design patterns makes it possible to reuse algorithms and also makes the design flexible; enterprise design patterns promote an abstraction of the complexity of Java EE tools and make it easier for the architecture to make changes.

Because of the complexity of architecture, the minimal use of enterprise patterns tends to be worse than the minimal use of design patterns. This is because, with the lack of use of enterprise patterns, the professional will always work with Java EE's complexity, increasing the probability of error.

Some implementations of Java EE patterns are already present in Java EE tools, and this makes them easy to use. In the next chapters, we will describe some of these patterns and their implementation using Java EE tools and see how these patterns will favor the design and architecture of your project.

In this chapter, we introduced you to design patterns, explaining the GoF design patterns and their catalog. We covered the basic design patterns of the Java world with a brief introduction to Singleton, Abstract Factory, Facade, Iterator, and Proxy. As well as this, we looked at enterprise patterns and the difference between them and design patterns.

In the next chapter, we will explain presentation patterns, including their concepts and implementation. We will also demonstrate the concepts of presentation patterns and how they help us to write better software. We will then show examples of the implementation of presentation patterns, using real-world problems as an example.