Design Patterns in Java
4.3 (3,883 ratings)
Course Ratings are calculated from individual students’ ratings and a variety of other signals, like age of rating and reliability, to ensure that they reflect course quality fairly and accurately.
24,575 students enrolled

Design Patterns in Java

Discover the modern implementation of design patterns in Java
4.3 (3,883 ratings)
Course Ratings are calculated from individual students’ ratings and a variety of other signals, like age of rating and reliability, to ensure that they reflect course quality fairly and accurately.
24,575 students enrolled
Created by Dmitri Nesteruk
Last updated 4/2020
English [Auto], French [Auto], 8 more
  • German [Auto]
  • Indonesian [Auto]
  • Italian [Auto]
  • Polish [Auto]
  • Portuguese [Auto]
  • Romanian [Auto]
  • Spanish [Auto]
  • Thai [Auto]
Current price: $69.99 Original price: $99.99 Discount: 30% off
5 hours left at this price!
30-Day Money-Back Guarantee
This course includes
  • 10.5 hours on-demand video
  • 1 article
  • 94 downloadable resources
  • 22 coding exercises
  • Full lifetime access
  • Access on mobile and TV
  • Certificate of Completion
Training 5 or more people?

Get your team access to 4,000+ top Udemy courses anytime, anywhere.

Try Udemy for Business
What you'll learn
  • Recognize and apply design patterns
  • Refactor existing designs to use design patterns
  • Reason about applicability and usability of design patterns
Course content
Expand all 123 lectures 10:30:51
+ Introduction
1 lecture 05:11

An overview of the different topics that we'll encounter in this course as well as some info on the way the course is organized and a few words about the instructor (that's me!)

Preview 05:11
+ SOLID Design Principles
7 lectures 01:07:11

The Single Responsibility Principle (SRP) states that a class should have a single reason to change (i.e., one primary responsibility). The opposite of an SRP-adhering class is an antipattern called God Object.

Single Responsibility Principle (SRP)

A look at the Open-Closed Principle (OCP) through the prism of the Specification pattern. Two for the price of one! :)

Preview 18:00

The Liskov Substitution Principle (LSP) suggests that you should be able to substitute a base class for a derived class. What does it mean? Watch the lesson to find out.

Liskov Substitution Principle (LSP)

The Interface Segregation Principle (ISP) suggests that you split interfaces into smaller interfaces so that clients don't have to implement things they don't need. Also related to the YAGNI (You Ain't Going to Need It) principle.

Interface Segregation Principle (ISP)

The Dependency Inversion Principle (DIP) states that high-level modules should not depend on low-level modules but on abstractions. I also suggests a preference for depending on abstractions (interfaces/abstract classes) over concrete implementations.

Dependency Inversion Principle (DIP)
+ Builder
8 lectures 43:19

A brief note about the three categories of design patterns: creational, structural and behavioral.

Gamma Categorization

An overview of the Builder design pattern.


There's at least one well-known builder in Java: the StringBuilder. But what problem does it solve, exactly?

Builders in Java

Let's implement our own builder for constructing HTML lists!


Fluent interfaces allow multiple calls of a builder to be called as part of a single invocation chain.

Fluent Builder

And you thought recursive generics were just for Enum? No way! They are also useful when inheriting from classes that have fluent interfaces.

Preview 09:25

Sometimes the object is complicated enough so that you need more than one builder. This lesson illustrates how several related builders can interact with one another through inheritance and a fluent interface.

Faceted Builder
Builder Coding Exercise
1 question

A summary of all the things we've learned about the Builder design pattern.

+ Factories
5 lectures 29:33

An overview of the Factory design pattern.


Having a static function for making an object allows us to avoid overloading problems. We can have two factory methods with identical sets of parameter types, but different names.

Factory Method

Let's relocate all factory methods to a separate class. We have a problem: private field are no longer accessible!


The Abstract Factory design pattern allows you to create hierarchy of factories corresponding to a hierarchy of types those factories create.

Abstract Factory
Factory Coding Exercise
1 question

A summary of all the thing we've learned about the Factory design patterns.

+ Prototype
5 lectures 21:05

An overview of the Prototype design pattern.


If we have Object.clone() and the Cloneable interface, why don't we just use them?

Don't Use Cloneable

How can we be explicit about the fact we are making a deep copy? From the land of C++ comes the idea of making copy constructors.

Copy Constructors

If your object graph has 10 classes in it, making 10 copy constructors (or dedicated cloning methods) is unrealistic. But we can automate the copying process via serialization.

Copy Through Serialization
Prototype Coding Exercise
1 question

A summary of all the things we've learned about the Prototype design pattern.

+ Singleton
12 lectures 01:01:10

A look at all the things we'll learn about the Singleton design pattern.


Let's implement the simplest possible singleton!

Basic Singleton

Even though a constructor is private, there are at least two ways of instantiating it. The obvious way is with the use of reflections. A less obvious ways of accidentally replicating the singleton is with the use of serialization.

Serialization Problems

If the singleton constructor can throw, you can initialize the singleton instance in a static block instead.

Static Block Singleton

We discuss two concerns of the Singleton: lazy instantiation and thread safety.

Laziness and Thread Safety

Thread safety issues can be mitigated via the use of a nested class.

Inner Static Singleton

A singleton that exposes itself as an enumeration instance. No problem with reflection or serialization, except... you cannot serialize field values. Also, you cannot inherit from this singleton.

Enum Based Singleton

The Monostate design pattern is a peculiar variation on the Singleton. It's not very practical, but can be used as a 'last resort' whenever Singleton-like behavior needs to be added without breaking existing API usage.


A multiton is a Singleton-like key-value store with (optional) lazy loading.


Why is the Singleton so disliked? One reason is testability. Let's take a look at how a Singleton can become problematic for testing.

Testability Issues

The only socially acceptable way of using a Singleton is via dependency injection: either done by hand or, preferably, through the use of a Dependency Injection framework.

Singleton in Dependency Injection
Singleton Coding Exercise
1 question

A summary of all the things we've learned about the (not-so-scary) Singleton design pattern. This concludes our investigation of Creational design patterns!

+ Adapter
4 lectures 20:21

An overview of the Adapter design pattern.


We consider a scenario where vector objects need to be rendered in raster form... this requires an Adapter!

Vector/Raster Demo

Quite often, implementation of Adapter generate temporary objects. We can implement caching to make sure we're not regenerating them on ever instance of adapter creation.

Adapter Caching
Adapter Coding Exercise
1 question

A summary of all the things we've learned about the Adapter design pattern.

+ Bridge
3 lectures 11:18

An overview of the things we are going to learn about the Bridge design pattern.


A demonstration of vector/raster rendering with the Bridge design pattern using both manual instantiation as well as automation using Google Guice.

Bridge Coding Exercise
1 question

A summary of the things we've learned about the Bridge design pattern.

+ Composite
4 lectures 19:47

An overview of the things we are going to learn about the Bridge design pattern.


We illustrate an implementation of a Composite design pattern with an object that can (optionally) contain child objects.

Geometric Shapes

A slightly more complicated demo where we get a scalar object to behave as an Iterable<> and also implement a default interface method!

Neural Networks
Composite Coding Exercise
1 question

A summary of all the things we've learned about the Composite design pattern.

+ Decorator
6 lectures 31:19

An overview of the Decorator design pattern.


One well-known final class is String. So if we want to give additional behaviors, we need to introduce our own String-like class and then delegate the members. Luckily, IntelliJ IDEA helps here!

String Decorator

Let's build a set of decorators for geometric shapes. These decorators are all composable, so you can mix and match!

Dynamic Decorator Composition

If you want to predefine the composition of decorated types at compile-time, you can do it with Java generics, but you'll have to jump through hoops due to type erasure.

Static Decorator Composition

A look at a hybrid of two patterns, the Adapter and the Decorator.

Decorator Coding Exercise
1 question

A summary of the things we've learned about the Decorator design pattern.

  • Good understanding of Java
  • Familiarity with latest Java features
  • Good understanding of object-oriented design principles
  • A computer with the latest JDK and (hopefully) an IDE

Course Overview

This course provides a comprehensive overview of Design Patterns in Java from a practical perspective. This course in particular covers patterns with the use of:

  • The latest versions of the Java programming language

  • Use of modern programming approaches: dependency injection, reactive programming and more

  • Use of modern developer tools such as IntelliJ IDEA

  • Discussions of pattern variations and alternative approaches

This course provides an overview of all the Gang of Four (GoF) design patterns as outlined in their seminal book, together with modern-day variations, adjustments, discussions of intrinsic use of patterns in the language.

What are Design Patterns?

Design Patterns are reusable solutions to common programming problems. They were popularized with the 1994 book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, John Vlissides, Ralph Johnson and Richard Helm (who are commonly known as a Gang of Four, hence the GoF acronym).

The original book was written using C++ and Smalltalk as examples, but since then, design patterns have been adapted to every programming language imaginable: C#, Java, PHP and even programming languages that aren't strictly object-oriented, such as JavaScript.

The appeal of design patterns is immortal: we see them in libraries, some of them are intrinsic in programming languages, and you probably use them on a daily basis even if you don't realize they are there.

What Patterns Does This Course Cover?

This course covers all the GoF design patterns. In fact, here's the full list of what is covered:

  • SOLID Design Principles: Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle and Dependency Inversion Principle

  • Creational Design Patterns: Builder, Factories (Factory Method and Abstract Factory), Prototype and Singleton

  • Structrural Design Patterns: Adapter, Bridge, Composite, Decorator, Façade, Flyweight and Proxy

  • Behavioral Design Patterns: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Null Object, Observer, State, Strategy, Template Method and Visitor

Who Is the Course For?

This course is for Java developers who want to see not just textbook examples of design patterns, but also the different variations and tricks that can be applied to implement design patterns in a modern way. For example, the use of recursive generics helps us build fluent interfaces even when inheritance is involved.

Presentation Style

This course is presented as a (very large) series of live demonstrations being done in IntelliJ IDEA and presented using the Kinetica rendering engine. Kinetica removes the visual clutter of the IDE, making you focus on code, which is rendered perfectly, whether you are watching the course on a big screen or a mobile phone. 

Most demos are single-file, so you can download the file attached to the lesson and run it in IntelliJ, Eclipse or another IDE of your choice.

This course does not use UML class diagrams; all of demos are live coding. I use IntelliJ and various Maven packages where necessary.

Who this course is for:
  • Software engineers
  • Designers
  • Architects