In order to be a successful software developer, having a detailed knowledge of a programming language is not enough. It is also essential to know best practices and techniques of writing a good software.
Design patterns are the the methods of writing software without having to reinvent the wheel; therefore they are defines as techniques of effectively solving commonly occurring problems.
In any commercial software application, more than one design pattern are often used. For example, a SharePoint-based ASP.NET WebForms application will probably utilize Model-View-Presenter, Repository, Service Locator and Trusted Facade patterns. Therefore, before working on such application, it is good to find out what design patterns there are.
In this situation, it may not be very obvious at the beginning why certain things are done in certain way, but getting familiar with the design patterns in use will put everything into perspective and will potentially prevent you from introducing technical debts that would grow into problems in the future.
Design pattern categories
The most popular design patterns that can be used by virtually any software development framework have been originally grouped into three categories: creational patterns, structural patterns and behavioral patterns. These have been described by 4 authors (also known as Gang of Four) in Design patterns: elements of reusable object-oriented software, that has been originally published in 1994. However, since then, new categories have been added to the classification and new design patterns have been added to the existing categories.
Below, I have summarized three original categories and have also provided examples of other design patterns that are mostly relevant to specific commonly-used enterprise-grade software frameworks, such as Microsoft ASP.NET and Oracle (Java) J2EE.
Creational design patterns
These design patterns define how objects or classes are created and instantiated. These can be described as the best practices of applying inheritance and delegation. Therefore, before learning any of the design patterns from this category, it is essential to be familiar with interfaces, inheritance, abstract objects and delegation. Below are some of the examples presented by this category:
Abstract factory
In this design pattern, an interface is used to define a single object that encapsulates interfaces for a family of related objects without specifying their concrete implementation. Therefore, making parametrised calls on a common public object that itself is of fairly simple structure returns different objects depending on what parameters have been put into it.
A good analogy would be a lever on a bottle-making factory. Depending on the position of the lever, the output on the assembly line will either be bottles or caps.
This design pattern is commonly used in portable OS-independent applications. For example, an abstract factory object may return a resource specifically tailored to a particular operating system. Another area where abstract factory is frequently used is graphics, where the same factory object can be used to define shape, border an fill color of geometric objects.
Builder
This design pattern allows to return different representation of the complex objects of the same core type. More often than not, this design pattern is used to return different collections of items by utilizing a single builder object.
Frequently used example of builder design pattern is StringBuilder class used in both Java platform and .NET framework. This class is used to efficiently manipulate strings without having to keep overwriting a single string variable.
Structural design patterns
As the name suggests, these design patterns are concern with the structure. These design patterns heavily rely on inheritance and interfaces to compose object with new functionality from existing objects or making excessively complex objects much more simple to use. These are some of the examples included in this category:
Composite
This design pattern uses a tree structure to allow several objects to be combined into a single object in a hierarchical manner. Both the composite object and its individual parts are treated as separate objects.
Any mechanical device, such as a car, can be used as an analogy for this design pattern. The car is an individual object, yet it consists of several parts, such as wheels, doors, bonnet, lights etc. Each of these parts, it turn, consists of more parts. For example fairly simple parts, like wheels, consist of rims and tires, while more complex parts, such as the engine, are composed of yet more composite parts that themselves consist of composite parts.
Facade
This design patter is used when a complex subsystem is wrapped up in a simple interface, so that the system becomes highly pluggable and easy to use.
An example of its application is to simplify the access to a web service layer. Often, service references (especially of SOAP type) are updated by serializing XML schema into callable classes. However, these classes may be cumbersome to read; therefore a simple Facade object may be used to encapsulate only those public functions of auto-generated service reference class that the rest of the application code absolutely must know about, leaving a short and easily understood list of methods to play with.
Behavioral design patterns
This category contains design patterns that control how individual objects behave and how different objects interact with each other. Here are two of the examples from this category:
State
With this design pattern, the behavior of objects changes when their internal state changes. For example, a session object that controls whether a particular machine is allowed to access a web page will allow the access to the page depending on whether the user has entered his or her credentials.
Likewise, the same object may also control how the page behaves depending on the actions of the user. Therefore, it is not an accident that such object is commonly referred to as “session state”.
Observer
This design pattern defines a way of notifying several object if a state of a single object changes. For example, a query submitted on a search engine page may trigger many processes on a number of servers. One of such processes may trigger many other processes on several other servers, so that the results are returned very quickly. Another process will update the search statistics for the keywords, so the algorithm for showing search suggestions will ensure that the most popular suggestions are shown first.
Platform-specific design patterns
These design patterns are commonly used in commercial software development environment. Some of them are especially popular on certain platforms or frameworks, while others are often used on many. Below are 3 noteworthy examples of such design patterns.
Model-View-Controller (MVC)
This design patterns is commonly used in various popular software development frameworks; however, on ASP.NET framework in particular, it was developed into a technology of its own with dedicated architecture, inbuilt types and file extensions.
In this design pattern, there is one or more controller objects, which are used to initiate all of the actions. Depending on requested action, controller accesses one or more model classes, which represent the data structure and are commonly used to map data between database tables and the code. Once the required data has been loaded, controller calls a view, which is a template for the user interface, such as a web page within a web application or a window within a desktop-based application.
When this pattern is used, all business logic (i.e. data-manipulation) is handled by the model classes, presentation logic is handled by the view templates and all of the routing is done by the controller.
Model-View-Presenter (MVP)
This is less well-known design pattern and one of the places where is is used fairly regularly are ASP.NET applications that are designed to expand the functionality of Microsoft SharePoint. Unlike MVC, this design pattern relies on the user interface objects to receive the requests directly, as there is no central controller. And, unlike MVC, the UI object will only have the definition of its components (i.e. its layout and internal variables).
Although it may also contain functions, there will be no logic in the view itself to call them. Presentation logic (i.e. what data to show and what components to change) is handled by a separate class known as presenter.
The view itself would be represented by an object, rather than a template. Often, the view object would implement an interface, which would be the only part known by the presenter, while the concrete implementation would be passed into the interface at runtime. This allows for effective unit-testing and dependency injection.
In MVP, model plays the same role as it does in MVC and is accessed by presenter classes to retrieve or manipulate the data.
Repository
Repository is a popular design pattern implemented by many framework and is often used in conjunction with MVC or MVP. With this design pattern, there is an additional business logic layer between a model and any object that requires the access to the model. Therefore model classes are purely used for representation of data and nothing else.
For more detailed information on design patterns, visit Sourcemarketing.
To find out more about the design patterns commonly used in Enterprise-level Microsoft applications, visit the official Microsoft website.
For more information on the design patterns commonly used in Java, this page would be helpful.