Design Patterns in Spring Framework

Published in

An Idea (by Ingenious Piece)

5 min readJul 24, 2020

Are you using Spring Framework to build web enterprise applications? Do you know how many design patterns in Spring Framework? As I wrote in the previous article then Design Pattern is only a solution that helps us to solve our problem. When we use Design Pattern in our project that will guarantee our code comply with Software Design Principles (SOLID, KISS, DRY, YAGNI). They make our code: easy to read, easy to understand, easy to maintain (add/modify features, and fix bugs).

What is Design Pattern?

“In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into a source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.” - Source: wikipedia.org

Using a Design Pattern doesn’t depend on what language you are using? Maybe Java or Kotlin language. I highly recommend using Kotlin language for new your project. Some projects, have used Java language when the project started. You should refactor them by small steps if you wanna use Kotlin language.

Besides, you should use the Spring Boot framework to build web applications. It’s based on Spring Framework and has a lot of useful features. More details: https://spring.io/projects/spring-boot

Inversion of Control (IOC)

In my option, it’s a pattern. Some people have assumed it is a principle. Have you read Martin Fowler Blog about IoC yet? Martin Fowler has called it a principle also known as the Hollywood Principle — “Don’t call us, we’ll call you”. There is a little confusion here. What is the difference between IOC and DIP (Dependency Inversion Principle)? Here is my answer: When we use IOC that will guarantee your code abide by DIP. IOC only is a programming technique.

In the Spring project, we have IOC Container which helps us to manage beans in our application: initialize, manage, destroy bean life cycle. In my option, IOC is only about project structure and Dependency Injection is about “How to works?”.

Dependency Injection (DI)

It’s one of a lot of solutions for IOC. In Spring Boot, you achieve DI via @Autowried annotation easily. There are three ways to use it:

@Autowired on properties
@Autowired on setters
@Autowired on constructors

Note: If you use Lombok you can use @RequiredArgsConstructor annotation

Proxy Pattern

It is applied widely in AOP. It’s very familiar with almost of people. Most of the company has a Proxy Internet which all requests will go through it. If request URL in the blacklist site you will not access it. Otherwise, If the request URL in the whitelist of Proxy Internet then you can access it normally. Another example, If you use Spring Data JPA/Spring boot 2.x then you are using Connection Pool (HikariCP) to communicate with Database. In my option, it’s a proxy for the database. For more details, you can read my article with a specific example.

Singleton Pattern

In the spring framework, IOC manages a lot of beans. As a default, a bean is created which has a singleton scope. Singleton means “A class of which only a single instance can exit”. So, How to set a singleton in the project? It’s very simple. The answer is very difficult to singleton setting correctly. In Java, we have a Reflection API which can edit access modifier of methods. Moreover, we have to pay attention to concurrency (Use synchronized keyword). Besides, we still need to handle logic save/load data from JSON data (Serialize/Deserialize object). Finally, Here is my advice: If you can use static variables instead of singleton then you should use static variables. It will guarantee your code which is only one instance that exists in the whole application.

Factory Pattern

This pattern is used by spring to load beans using BeanFactory and ApplicationContext. What is the difference between BeanFactory and ApplicationContent?

In Short, the BeanFactory provides the configuration framework and basic functionality, and the ApplicationContext adds more enterprise-specific functionality. The ApplicationContext includes all the functionality of a BeanFactory. So, you should use an ApplicationContext unless you have a good reason.

BeanFactory vs ApplicationContext. Source: docs.spring.io

More details: https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#beans-beanfactory

Decorator Pattern

In my opinion, this pattern is very important and has applied to a lot of famous libraries/frameworks. In Java libraries, the decorator is pretty standard, especially in code related to streams. Some examples, all subclasses of java.io.InputStream, OutputStream, Reader, Writer, and java.util.Collections (checkedX(), synchronizedX(), unmodifiableX() method), …

In short, the Decorator Pattern is “Add responsibilities to objects dynamically”. For more details, you can read my article or search on the internet about this pattern.

Strategy Pattern

Basically, the Strategy Pattern is a behavioral software design pattern that enables selecting an algorithm at runtime. Applying Strategy Pattern in your code will guarantee your code abide by the Open/Closed Principle. This principle is applied widely in everywhere. For example, you can imagine to plugin architecture in IntelliJ IDEA/Visual Studio Code: make to easy for adding/modifying a feature with an available plugin. For more details, you can read my article or search on the internet about this pattern.

Conclusion

The learning design pattern isn’t difficult, you can found a lot of materials on the internet but identify and apply it in your project not easy.
Maybe in the future, you wanna create your library/framework be like Laravel (Taylor Otwell) or contribute to famous open-source. You should understand deeply core design patterns before doing them.