1. Home
  2. Training Library
  3. Programming
  4. Programming Courses
  5. Using Design Patterns in Java Projects

Decorator

Contents

keyboard_tab
Design Patterns
1
Design Patterns
PREVIEW2m 26s
2
Singleton Pattern
PREVIEW3m 13s
9
Decorator
7m 48s
10
Flyweight
9m 20s
11
Proxy
7m 36s
12
Facade
6m 5s
14
Command
11m 44s
15
Iterator
8m 24s
16
Visitor
9m 4s
17
Mediator
11m 38s
18
Memento
9m 48s
19
Observer
10m 40s
20
Strategy
8m 27s
21
State
10m 27s
22
Template
7m 56s
23
MVC
10m 27s
26
DAO
10m 27s
27

The course is part of this learning path

Start course
Overview
Difficulty
Intermediate
Duration
4h 56m
Students
26
Ratings
5/5
starstarstarstarstar
Description

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.

Prerequisites

Basic knowledge of Java programming.

 

Transcript

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
Students
512
Courses
47
Learning Paths
3

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