What are Design Patterns?

Don't reinvent the wheel

In many engineering disciplines, the problems that most businesses face are not unique, and hence the solutions that they provide to those problems should not be unique either. However, without understanding the existing solutions for similar problems, there will be a tendency to reinvent the wheel. Learning design patterns will not only help save you from unnecessary engineering but will also introduce you to more elegant solutions that you would not have thought of otherwise.

So, in engineering, a design pattern is a general, repeatable solution to a commonly occurring problem in design. Although this term started in other core engineering disciplines, it is very much relevant to Software Engineering as well.

A design pattern will not provide you with a code implementation but will provide a description or template for how to solve a problem with a solution that is more elegant. In most cases, the solution is the result of many years of iterative improvements and expertise from seasoned engineers.

Although there are many Design Patterns in Java, the most common ones are described below, and the Singleton pattern is covered in the next lesson.

MVC Pattern

The Model-View-Controller (MVC) pattern is mostly applied to User Interface (UI) applications. If you take a simple HTML page as a reference, the page consists of pure data on which certain visual effects are applied and then presented to the user. Instead of mixing the data with display logic, visual effects, and the logic associated with user interactions, this pattern lets you separate the concerns and provides you with three main components:

• Model - This class is just a Plain Old Java Object (POJO) that has instance variables to carry the state of the object and its corresponding getters and setter methods. The object instance carries pure data devoid of any markups for visuals or coding logic for behavior changes.
• Controller - This class orchestrates user interactions by directing the user to appropriate views and providing appropriate models for the views. The Controller also has the business logic necessary to handle user interactions.
• View - This class knows how to present the pure data that is given to it in the form of a Model. The View is responsible for laying out the data in the format, color, and visual effects that are needed for the project.

Frameworks using MVC: Most of the modern software development frameworks use the MVC pattern. In Java, Spring MVC is a classic example.

Reference: https://www.tutorialspoint.com/design_pattern/mvc_pattern.htm

Data Access Object

In most software systems, the data that is manipulated by the software system is persisted in some backend system. It could be an RDBMS (relational database management system) like Oracle, MySQL, etc.; it could be a NoSQL database like MongoDB, Cassandra, etc.; or it could just be a plain old file system. And sometimes, a software system may be using one database management system and might decide to change it at a later point in time to another system. In such cases, if the software system were using a DAO pattern for data access management, then swapping one system with another becomes a lot easier.

The Data Access Object (DAO) design pattern helps in delineating all the data access methods in an interface. This interface can then be implemented by any class that encapsulates the specific mechanism in which a particular database has to be accessed.

Since it is the interface that the business logic classes are using, changing the implementation class at any point in time will not affect most of the codebase.

References

• https://www.oracle.com/java/technologies/dataaccessobject.html
• https://www.oracle.com/java/technologies/design-patterns-catalog.html
• http://www.corej2eepatterns.com/

Data Transfer Object

The Data Transfer Object Design Pattern is a pattern in which you create an instance of this class to aggregate and encapsulate data to transfer from one layer to another in a multi-tier architecture. A Data Transfer Object is, for the most part, a data structure that holds pure data with no business logic or presentation aspects associated with it. Since this object may be stored and restored from a persistent storage, it may have serialization and deserialization mechanisms.

You have already been using the EmailDTO in the examples given thus far, so a detailed example is not shown here.