Skip to main content

Posts

Showing posts with the label Design Pattern

Template Method Pattern: Don't Call Us, We'll Call You!

So far, the Template Method has been my most used design pattern. That is the reason why this post is quite long. J Definition from Wiki The Template Method defines the program skeleton of an algorithm in a method, deferring some steps to subclasses. It lets one redefine certain steps of an algorithm without changing the algorithm's structure. A Real World Use Case Imagine that you have many different kinds of documents. You want to generate a pdf file from a corresponding word template. Each type has its own small modifications but the main process for document generating is the same. We apply the Template Method for this case. We define a final method including some steps (such as preparing for content, generating file) at a superclass. There are three possibilities for these steps at subclasses: Must be overridden: abstract methods. Not mandatory to be overridden: default protected methods. Can not be overridden: default private methods. Dissecting the Patt

Make Our Code More Testable with Proxy Design Pattern

If you heard about the term separation of concerns , you could agree this concept is very important for making a system "clean". One of the most important characteristics of a clean system is testable. Let me tell you my story about how I've just come acrosss the design pattern Proxy. Note: to get started, you can find a very simple example of the pattern Proxy  here .  Let's start! I have an interface as below: public interface DocumentGenerator { File generate(Document document) throws BusinessException; } The following is my first implementation for a concrete class of DocumentGenerator . public class DocumentGeneratorImpl implements DocumentGenerator { private Dossier dossier; private Locale locale; public DocumentGeneratorImpl(Dossier dossier, Locale locale) { validateNotNullParams(dossier, locale); this.dossier = dossier; this.locale = locale; } private void validateNotNullParams(LibertyDossier dossier, Locale locale) { if(Objec

Separate Constructing a System from Using It

I n the real world, in order to use a building (hotel, supermarket, etc) we need to construct it first. This concern should be applied for software development as well. Step by step, I would like to show you the issue about no separation of constructing and using it and then I'll give you some approaches to overcome this issue. | Note : you can find the  below  demonstrated code here    Take a Look the Following Simple Application Used tools and technologies: Eclipse (Mars), JDK 1.8 I had an App which uses Controller . Controller uses Service (an interface). Finally, Service has one concrete class is DefaultService . //package vn.nvanhuong.system.separationconstructing; public class App { public static void main(String[] args) { Controller controller = new Controller(); controller.doAction(); } } public class Controller { private Service service; public void doAction(){ System.out.println("doAction in Controller"); getService().execute();

Building a Wizard with Chain of Responsibility Pattern

What is the Idea? We want to create a page that there are some steps and each step has its own business. Users are able to click on a step and its status could be changed. Primefaces owns a component " Wizard " but it it quite hard for us in order to apply our very specific and complicated business domain logic on each step; even we cannot click on a step of this component. We somehow are able to use the component " TabView " works with a strong back-end mechanism. A backend mechanism! what do I mean? Yes, we need it because we want to abstract the behaviors of each step otherwise we will get trouble with many events handling. Obviously, each step has some behaviors  such as "next", "back" and "switch' are the same and they are related to each other; but the business of these behaviors can be different totally. That is where the pattern "Chain of Responsibility" can be applied. Step by Step Building It! In this simple pr

Changing source code at run-time with Service Locator pattern

I have a service to get some data but the result can be different basing on where the implementation is. Technically, I have two or more concrete implementation of an interface and I am able to switch using these concrete classes at run-time. That means I have a place to configure it without re-deploying the application. In order to overcome this issue, I use Service Locator design pattern and here I only care about two advantages below: Encapsulating the specific implementation, we just declare the name and don't care about the implementation of the service. Changing the implementation at run-time. Client : an object that invokes the services via Service Locator Business services : services that is used by Client.

Strategy Design Pattern

For example, I have a program with an Animal abstract class and two sub-classes Dog and Bird. I want to add new behavior for the class Animal, this is "fly".  Now, I face two approaches to solve this issue: 1. Adding an abstract method "fly" into the class Animal. Then, I force the sub-classes should be implemented this method, something like: public abstract class Animal{ //bla bla public abstract void fly(); } public class Bird extends Animal{ //bla bla public void fly(){ System.out.println("Fly high"); } } public class Dog extends Animal{ //bla bla public void fly(){ System.out.println("Cant fly"); } } 2. Creating an interface with method "fly" inside. The same issue to an abstract class, I force the classes these implement this interface should have a method "fly" inside: public interface Flyable{ public void fly(); } public class Bird implements Flyable{ //bla bla public void fly(){ System.out.pr