behavioral pattern

behavioral pattern, Java, OOP, Strategy

Design Patterns: Strategy

The Strategy design pattern belongs to Behavioral family. It helps us to change behavior at runtime. The definition from Gang of Four book is following.
[quote name=”Gang of Four”]Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from client that use it.[/quote]

When do we have to use it

  • We use Strategy pattern when we need to hide the implementation of an algorithm.
  • When we have many related classes which differ in their behavior providing a way to configure another class with one of many behaviors.
  • Using Strategy we avoid to expose the complexity of an algorithm.
  • If you have many conditionals in front of you, and each one contains different behaviors of a class, then it is time to use Strategy pattern.

How do I use it

The Strategy design pattern is really easy to use. We just need to provide an Interface. This Interface is going to be used creating multiple implementations of different algorithms.
After implementing our algorithms we just need to create a context (Composition) which is going to use our interface gaining access to algorithms.


Supposing that we develop a game, there is a character and has two or many special powers to use.

Let’s start with the interface and its implementations.

Now we are going to create the context class.

Let’s run an example.


You can download the source code from GitHub.

behavioral pattern, Design Patterns, Java, OOP, Programming

Design Patterns: Mediator

The mediator pattern belongs in the family of Behavioral Patterns. It contains the entire logic of how objects interact with each other. So, it helps us decouple objects.

What’s the problem

In case we have many objects that interact with each other, we end up with very complex and nonmaintainable code. That’s why it is a good case to use the Mediator design pattern.

There are many times that we have interaction among objects. We usually create a sufficient amount of objects allowing us to communicate with each other with the intention of building entities that act together for a specific reason.

When something happens to an object then another one has to do something or change its behavior.

Building a complex code allowing many objects (2 or more) to communicate with each other, you will end up with spaghetti code, nonmaintainable, and you will face a nightmare every time you want to find and fix a bug or to enhance the code.

This problem increases if you normally have a back and forth and complex interaction.

How do I solve this problem

The solution comes using the Mediator pattern. This pattern allows you to keep the whole logic of communication in one place (object) and every object used to interact with other objects now interacts only with the one which is aware of how to act on every occasion.

So, we can understand very quickly that objects are decoupled. The code is more simple than it used to be. That’s exactly what we try to achieve using OOP and design patterns.


Using the Mediator pattern and keeping the whole interaction among objects in one place (object) means that we are going to move complexity from one place to the other.

It is very easy to turn the Mediator pattern into a mess if you don’t separate objects appropriately. Even if you want to use the same objects but somehow different, you have to keep each behavior in separate mediator objects.

So, there is a need to simplify the mediator if necessary.

How do I code the Mediator Pattern?

It is really easy to write code with a mediator pattern.

We start with classes that encapsulate mediators and instead of interacting with each other, they interact with the mediator.

Every time each class needs to interact with an object, it calls a method from the mediator and only the mediator knows what object needs to be called.

For the mediator, we just need an interface. It is a good practice to use an interface or an abstract class for the mediator. In this way, you are able to have different implementation of the mediator object.


Greek public services are a mess. Each time a Greek citizen needs to use a public service, he faces a huge bureaucracy. So, a citizen has to transfer and get a bunch of documents from one public service to the other. In this case the Greek citizen is the mediator. He is the one who has to go and find the right document in a group of public services. This is wrong from many aspects but it is a reality.

Let’s start our example by implementing this situation but a little differently, in the right way. Instead of using citizen as an intermediary mean, we will create a mediator which is going to be aware of all public services and how to use them. So, the citizen can go and ask the mediator for something and it is going to interact with public services (objects) for the desirable result.

In the following example, a Greek citizen who wants to start a new company is represented.

We start with an interface for the mediator.

Let’s implement this mediator.

Now it’s time to implement the objects which are going to interact with the mediator.

The following code is representing the Greek citizen.

Let’s create a function which runs the code


You can download the source code from GitHub.

behavioral pattern, Java, observer pattern, OOP, Programming, Software Engineering

Design Patterns: Observer

An observer is a pattern that falls under Behavioral Patterns. It is used when there is one-to-many relationships between objects. So, when an object’s state is changed then all its dependent objects are notified automatically.

When do you have to use Observer

  • When a change to one object requires to notify other objects.
  • We don’t need to be aware of how many objects need to be changed.
  • We don’t want these objects tightly coupled.

How to use it

The concept behind the Observer pattern is simple. We have a subject that is going to keep track of the observers. Every time this subject changes, all its observers are notified automatically. The subject contains some methods that allow observers to be registered or unregistered.

When the state of the subject changes then the subject has to notify all the observers which are registered.

This pattern is so flexible that sometimes we want to change this behavior and let observers ask the subject for the state and if it is changed, then the observer acts appropriately.


Let’s suppose that we are at a university and we want to update every student who is registered in a course. If the student is registered in a specific course then every time the state of the course is changed, registered students will receive a notification.

Start with the Subject interface

We will implement the Subject interface.

Let’s create one more interface named Observer

StudentObserver class is going to implement the interface above.

Last but not least StudentObserver we have one more class named Email, and as you can imagine we are going to use this class so as to send emails to students.

Now we are ready to use these classes.


You can download the source code from GitHub.

behavioral pattern, Design Patterns, Java, template method

Design Patterns: Template Method

Hi guys, I am going to continue with behavioral design patterns and today I will introduce you to the Template Method pattern.

Template Method pattern provides a template method that defines a set of steps (it calls other methods) and the implementation of steps (methods) can be formed in sub-classes if a step has varied implementations. If not, then it’s a good practice to implement this step in the superclass.

According to Gang Of Four Book :

Defines the skeleton of an algorithm in a method, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm structure.

As you can imagine, in order to create a template method pattern, an abstract class is mandatory. We can use an abstract class in order to create the template method with the steps, we can create steps if they are stable and also create abstract methods for steps that are changing depending on circumstances.

Why the Template Method Pattern?

  • When there is an algorithm with steps that may vary.
  •  Because we can avoid duplicate code and we can use inheritance through a subclass in order to use the same code.
  •  We can create a skeleton of an algorithm that helps us to simplify the complexity.

It is very easy to create a template design pattern, so, it would be better to continue with an example.


Let’s start with a simple example. We have some users who have access to a platform to fill out a test. After test completion, we extract some scores. So, we have to create a system that computes the score in two different scenarios.

At first, we will create an abstract class named Scoring with 3 methods. The first one is always a standard method “computeScore()” that returns the sum of the 2 other methods. The computation1() and computation2() methods are abstract and we are going to implement two different scenarios.

Let’s continue with the first scenario. We create a class Scenario1 which is a subclass of the Scoring abstract class.

Continuing with the second scenario and Scenario2 class.

As you can see, we have two totally different implementations of computation1() & computation2() methods in our classes. These computation approaches do not have an impact in real life, I just wrote the first thing that came to my mind.

Now we are ready to call these 2 classes.

The score from scenario 1 is: 70.0%
The score from scenario 2 is: 38.0%

Caveat: As you can see, we have an abstract class, and we extend this class in order to implement some methods. We are able to use another abstract class which is going to extend the first abstract class and so on.

When you catch yourself to act like that then STOP immediately or be careful. Do not use more than two abstract classes. In my opinion, do not use more than one abstract class because you are going to lose instead of gaining something from inheritance.

The reason is simple. The code becomes hard for debugging, you add more complexity and complexity is never good, difficult to maintain the code, and even more difficult to add new functionalities. Also, it’s a good practice to restrict the usage of this pattern because it doesn’t fit very well with the open/closed principle.

Also, you can read this article so as to get a better insight into why the Template Method pattern is a bad practice.

You can download the source code from GitHub.

behavioral pattern, Design Patterns, Game Development, OOP, Programming

Design patterns: State

Hi guys, I made a decision to see a different category of design patterns and this category is behavioral design patterns.

What a behavioral design pattern is. The text following is from Gang of Four.

Behavioral patterns are concerned with algorithms and the assignment of responsibilities between objects. Behavioral patterns describe not just patterns of objects or classes but also the patterns of communication between them. These patterns characterize complex control flow that’s difficult to follow at run-time. They shift your focus away from the flow of control to let you concentrate just on the way objects are interconnected.

So, today we will see the State design pattern.

What a State design pattern is. The text following is from Gang of Four.

Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.

The state design pattern is one of those that is used widely in game development. It helps us to describe the different states of a game-changing object’s behavior but keeping objects loosely coupled.

For example, we have a character who is able to jump only if he is standing and not sitting, and he is able to sit only when he touches the ground.

If we try to implement this character’s behavior we will come out with a code of full “if,elseif” and multiple complex conditions that make our code ugly.

Let’s try to add some functionalities to our character, he is able to shoot only if he is standing or jumping but not when he is sitting.

As you can imagine our code is already quite complex and unwieldy in order to find a quick and easy way to add this functionality.

So, the code’s maintainability is almost unattainable, and also there are many bugs and unpredictable behaviors hidden.

For this reason, the State design pattern helps us to simplify our code. The code will be more readable and maintainable.

Let’s see the next example


We will have a character with a gun. There will be 2 different behaviors of the gun. In this example, we will see only the gun’s behaviors.

So, the gun has 2 states. In the first one, the gun is loaded with ammo and ready to fire, and in the second one, it is empty of ammo.

Let’s start to design the code using the State pattern.

Interface GunState

Now, we will create the 2 classes that implement the GunState interface. ShotGunHasAmmo & ShotGunHasNoAmmo.

Finally, we implement the GunContext class in order to see a changed behavior when it changes state.

Run The code

Shotgun is in has ammo state
Shotgun is shooting. Left Bulets 2
Shotgun is shooting. Left Bulets 1
Shotgun is shooting. Left Bulets 0
Shotgun is in empty of ammo state
Shotgun is empty!
Shotgun is empty!
Shotgun is in has ammo state
Shotgun is shooting. Left Bulets 3
Shotgun is shooting. Left Bulets 2
Shotgun is shooting. Left Bulets 1
Append 2 bullets in Shotgun
Shotgun is shooting. Left Bulets 2
Shotgun is shooting. Left Bulets 1
Shotgun is shooting. Left Bulets 0
Shotgun is in empty of ammo state
Shotgun is empty!
Shotgun is empty!

You can download the source code from GitHub.

View More