Start course
4h 56m

This course takes an in-depth look at how to use design patterns in your Java projects. We will then run through some example questions of what you could expect from the Oracle Certified Java EE exam.

Learning Objectives

  • Understand what design patterns are
  • Learn about the myriad of design patterns that you can use in your projects

Intended Audience

This course is intended for anyone who already has basic knowledge of Java and now wants to learn about Java EE 6.


Basic knowledge of Java programming.



Hello dear friends. In this video, we will examine the decorator design pattern. Let's begin. In software engineering, decorator design pattern is used to add additional features or behaviors to a particular instance of a class while not modifying the other instances of same class. Decorators provide a flexible alternative to sub classing for extended functionality. This pattern is very important to understand because once you know the techniques of decorating, you'll be able to give your or someone else's objects new responsibilities without making any code changes to the underlying classes. This pattern is also very useful and frequently asked about in Java interviews when discussing design patterns. In other words, the decorator pattern uses composition instead of inheritance to extend the functionality of an object at runtime. Suppose we want to implement different kinds of cars, we can create an interface car to define the 'assemble()' method, and then we can have a basic car.

Furthermore, we can extend it to sports car and luxury car. Let's look at the UML schema of the decorator pattern. The concrete component class is the one for which we'll like to add additional behaviors at runtime. The concrete decorator is the decorator class, which holds the logic to decorate a given component. The abstract decorator class aggregates any other type of component which allows us to stack components, one on top of the other. Also, both the concrete component and decorator classes implement a common interface as component. Let's look at the advantages and disadvantages. First, let's start with advantages. Decorator provides greater flexibility than static inheritance and it avoids the need to place feature laden classes higher up in the hierarchy, decorator simplifies coding by allowing you to develop a series of functionally targeted classes instead of coding all of the behavior into the object.

Also, the decorator enhances the extensibility of the object because changes are made by coding new classes. There are also some disadvantages of decorator pattern, such as, decorators can complicate the process of instantiating the component because you not only have to instantiate the component, but wrap it in a number of decorators. It can be compiled to have decorators keep track of other decorators because to look back into multiple layers of the decorator chain starts to push the decorator pattern beyond its true intent. So, when should we use this pattern in our projects? When you want to add responsibly to objects transparently and dynamically without affecting other objects. Or in cases where you want to add responsibility to the objects that you may want to change in the future, the use of the decorator design pattern will be beneficial for the project. I know that listening theoretically is not enough to fully understand the decorator pattern. So, let's see and code with an example.

Create a project and name it decorator pattern. We previously spoke about a car, so, let's use a car object in our example. First, we need a car interface. Add a method as a symbol. This interface is our component interface. Let's define component implementation. Add a new car, and name it BasicCar, implements car. Let's override the method. Now we need decorator. CarDecorator implements car. First, we will add a car as protected. Decorator class implements the component interface and has a 'Has-a' relationship with the component interface. The component variable should be accessible to the child decorator classes. So, we will make this variable protected. Defined constructor. Override method. Now we have to add car types as decorator creators, Sportcars. Define constructor and override method. Now the other creator. Done. Now we have finished structure. Let's use. First create a sportscar, call assemble() method. Now create a luxury car, call assemble() method. Done. Let's run the application and see the results. Great. We could see both the sports car and the luxury car, and that means our application has executed flawlessly. I believe that concludes our discussion of decorator. In the following video, we will look at the flyweight pattern. See you in the following video.


About the Author
Learning Paths

OAK Academy is made up of tech experts who have been in the sector for years and years and are deeply rooted in the tech world. They specialize in critical areas like cybersecurity, coding, IT, game development, app monetization, and mobile development.

Covered Topics