Decorator Design Pattern

Last post I discussed Strategy Design Pattern, continuing with the same topic, today I will write something about Decorator Design Pattern.

In case of Strategy, you encapsulate code in external algorithms for easy use rather than spreading it around inside your core code and modifying it throughout that code.

The Decorator takes a different approach. Instead of using external algorithms, this design pattern is all about using wrapper code to extend your core code.

The formal definition of the Decorator pattern from the GoF book (Design Patterns: Elements of Reusable Object-Oriented Software) says you can, “Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.”

Lets see how the example code looks like.

1.     First you define an interface class with a method operation() of type string.

2.     Next you define a class that implements this interface and method operation() returns “computer”.

3.     Now you define an abstract class that implements the interface you defined earlier. This class is actually a pass through class with a method new() having a parameter.

4.     Now you define two concrete classes that extend the abstract class you created in previous step. Notice the operation() methods.

5.     Finally you need a job to put all the pieces together.

6.     The infolog

This is what is happening. When you call the monitor’s operation() method, the following occurs in this order:

1. The monitor’s operation() method calls the disk wrapper’s operation() method.

2. The disk wrapper’s operation() method calls the computer object’s operation() method.

3. The computer object’s operation() method returns the text "You are getting a computer and a disk".

4. The monitor wrapper’s operation() object then adds "and a monitor" to give you the resulting final string, "You are getting a computer and a disk and a monitor".

Hope the post was clear and feel free to ask me for the xpo.

Design Patterns in AX - Strategy Design Pattern

Design Patterns help developers solve recurring complex problems in their code. We see lot of inheritance getting used in AX code. Inheritance is a good OOPS concept and helps in writing smart code. But only to an extent. In some situations, code becomes too deep, too hard to maintain, debug or upgrade. That's when design patterns come to the rescue. The Gang of Four (GOF) introduced the concept of Design Patterns in their book http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612
There are a total of 23 patterns in the book.

I always wanted to write on this topic and this post will cover one of the patterns - Strategy Design Pattern. Quoting from the GOF book, the Strategy design pattern is defined as “Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.”
I will use some sample AX code to supplement my post.

1. First we define our interface class named Strategy with one method algorithm.

 2. Then we define three concrete classes aptly named ConcreteStrategyA, ConcreteStrategyB and ConcreteStrategyC with their implementations of method algorithm.

3. Next we have a class StrategyContext which is actually a pass through class whose working we will see shortly in the job.

4. Finally we define the job. We initialize the three concrete classes, define a switch case, call the contextInterface method and depending on the value in the variable condition, algorithm method of the corresponding concrete class is called.

5. The Infolog.

The Strategy Design Pattern says that you should extract the volatile parts of your code and encapsulate them as objects; you can use those objects as you need them. You can customize your code by creating composites of objects. At runtime, you just use polymorphism to choose the object(s) you want to work with. Feel free to ask me for the xpo. I will be posting more posts on this topic.