Design Patterns

Behavioral Design Patterns

Template method

Defines the program skeleton of an algorithm in a method. This method is called template method. 

• The method defers some steps to subclasses
• It lets one redefine certain steps of an algorithm without changing the algorithm's structure.

• Subclasses that override the template method implement and/or override one or more of the algorithm steps, differing behaviors while ensuring that the overarching algorithm is still followed.
• In object-oriented programming, first an abstract (See abstract class) super-class is defined that provides the basic steps of an algorithm. These steps are implemented using abstract methods. Later on, subclasses change the abstract methods to implement real actions. Thus the general algorithm is saved in one place (the abstract superclass) but the concrete steps may be changed by the subclasses.

User Interface Design Patterns

MVC

MVC is a design pattern that divides an application into three major areas:

• Model component - Data-model components. For example, if an application deals with Business Data, a model is all the application objects that deals with business data and represents a Business Model of that data.

• View component - Display media components for the end user. If, for example, the application is a web application, the view may be represented by an "html", "jsp", "jspx", "xhtml" etc.

• Controller component - Controller components controls an application flow and navigation. For example, a controller may check if a request comes from a login-page, and according to a requested operation may navigate a user to home screen if a login operation was successful, or back to the login-page if a login operation failed.

Dividing an application to three MVC major areas eases the developement of the code, because each of these areas use different application resources, while still making it easy to maintain and manage each area separately. Each area needs to interact with the two other areas, and thus each area provides specific interaction / access / entry points to work with.

Web Design Patterns

Conversation Scope

The Need

Often a user operation consists of multiple requests to the server. Take for example the case of a wizard that spans multiple web pages. Data need to be stored on the server throughout the wizard operation. On the end of the wizard operation, (when a "Save" or "Finish" button is pressed) the data need to be discarded.

This scenario is called a conversation because what actually happens is a conversation between the user (the client) and the server, that starts from the first screen of the wizard (in our example) and ends on the last screen.

The problem

Traditional application servers and web programming languages provide only three scopes for data to be stored in:

• Application scope - Application scope is only rarely in use. The data that it stores is shared between all users of a web application.
• Request scope - Request scope is in very common use and stores data only for a specific request. All data that is stored in a request scope is discarded at the end of each request (after the response is sent).
• Session scope - Session scope is also in common use. It stores data throughout a specific session. One may think that a session scope can be used in a conversation, but actually it suffers from a number of issues:
• Discarding all to a conversation specific data - is a difficult task to do when using a session scope, and thus may cause memory leaks.
• A session is typically shared across all tabs and all windows of a web browser - A session is usually tracked using cookies. Because all windows associated with the same browser share cookies, they are considered to be within the same "session". If two windows are created for the same session then very strange effects can be caused due to the same "backing beans" being used by the two windows.
• Initializing a new conversation - when a user wants to start a new conversation of the same type it is usually better for the server objects to be initialized, rather than having whatever state they had on the previous pass. This is difficult to achieve in a session scope.

The Solution

There are many frameworks that provide a native use of conversational scopes.

• Mojarra JSF2
• Java CDI
• Spring Custom Bean Scope
• Apache Orchestra

GRASP Patterns (object-oriented design)

General Responsibility Assignment Software Patterns (or Principles), abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.

The patterns on this category answer some software problem, and in almost every case these problems are common to almost every software development project.

The different patterns and principles used in GRASP are: Controller, Creator, Indirection, Information Expert, High Cohesion, Low Coupling, Polymorphism, Protected Variations, and Pure Fabrication.

Controller (See also: Model–view–controller [MVC])

The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario.

Creator (See also: Factory pattern)

Responsible for creating an object of class

Indirection (See also: Delegation pattern)

Supports low coupling between two elements by assigning the responsibility of mediation between them to an intermediate object. An example of this is the controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern.

Information Expert (See also: Information hiding, Expert or Expert Principle)

Used to determine where to delegate responsibilities. These responsibilities include methods, computed fields, and so on.

High Cohesion

This pattern attempts to keep objects appropriately focused, manageable and understandable. Breaking programs into classes and subsystems is an example of activities that increase the cohesive properties of a system.

Low Coupling (See also: Loose coupling)

This pattern dictates how to assign responsibilities to support:

• Lower dependency between the classes
• Change in one class having lower impact on other classes
• Higher reuse potential.

Polymorphism

Responsibility of defining the variation of behaviors are based on the type.

Protected Variations (See also: Delegation pattern)

Protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

Pure Fabrication (See also: Service [systems architecture])

A Pure Fabrication is a class that is specially made up to achieve low coupling, high cohesion, and the reuse potential thereof derived.

This kind of class is called "Service" in Domain-driven design.