Decorator Pattern

The decorator pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

From what I have learnt from my ventures through software development is that developers are often faced with scenarios where they have to adapt, or add extra functionality to an existing application.

Now an important design principle for OOP is that Classes should be open for extension, but closed for modification.

This means that the internal logic of an existing class shouldn’t have to be changed if additional functionality needs to be added. However one should be able to extend the functionality using Decorators.

We often see the use of “Decorating” within API’s where a defined set of classes are initiated. The programmer using the API doesn’t have access to directly alter the logic of these classes however they have the ability to extend the functionality using Decorators. Such as the stream classes within the java API

I will demonstrate how the decorator pattern is implemented with an example similar to MTV’S pimp my ride    ; )

In this example the main component will be the car that will be “pimped” and the decorators will represent the additional car parts.

 

The diagram shows the base class Car which acts as the component class; the three concrete components represent our cars to be “pimped”: SUV, Coupe and Old school. The abstract class CarParts that inherit the base class Car is used by the decorators: BodyKit, Exhaust, Spoiler and Brakes to add functionality to the derived Car classes. 

Code

Results

Latter I will do a brief analysis of each pattern and highlight their advantages and disadvantages... Please stay tuned.........

Strategy Pattern

The strategy pattern defines a family of algorithms, encapsulates each one and makes them interchangeable. This pattern allows the algorithms to vary independently from clients that use them.

When using inheritance one often has the problem of inheriting behaviours which are not applicable to certain derived classes. 

This diagram below shows the class structure of characters within my example fighting game.

As you can see the subclasses derive the methods of the abstract base class.  In this particular game the characters have the choice to use a range of weapons.

Now with this current class structure the weapon behaviour is fixed, and cannot be changed at runtime.

Also with a long list of characters, each character will need the logic in its weapon method to be added and if amendments need to be made to a weapon then it is likely that multiple characters will have their weapon method changed.

The strategy pattern was created to resolve these complications and reduce time consumption.

From what has been explained previously we know that the weapon behaviour is the behaviour that varies within the character class.

We do as the strategy pattern tells us and encapsulate the weapon behaviour.

We do this by creating a weapon interface, and classes (representing different weapons) that implement the weapon interface as seen below.

We also add the “set_weapon” method to the character class.

 

Code

Below shows the programing implementaion of the example fighting game (described above) using the stratergy pattern.

This is our fighting game character class

 This is our weapon interface

This one of our weapon classes  

in the main of this example i have tried to demonstrate how assignment of the weapon assignment to characters are interchangeable.

When complied these are the results we receive

I further adapted the main program to demonstrate how a weapon can be assigned to a character at runtime, as seen below:

when complied these are the results we receive

FOR THE NEXT POST I WILL BE COVERING "THE DECORATOR PATTERN", PLEASE STAY TUNED

Observer Pattern

The observer pattern defines one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.

This pattern is described as one similar to a newspaper subscription. The publisher sends newspapers to the subscribers whenever a paper is released.  Potential subscribers have the ability to subscribe and subscribers have the ability to a unsubscribe.

According to the observer design pattern, the object distributing the data (publisher) is called the subject. Those objects that receive the data (subscriber) are called observers.

I have developed an example of the object pattern using the following example.

The example I used is a model of the rate of growth of different tress within a particular niche.  Trees situated within the same environment receive the same parameters i.e.  The same amount of Sun, Rain and Carbon dioxide. Even though they receive the same parameters the effect these parameters have on each tree is different.  i.e.  They differ in their level of growth, the amount oxygen they produce and the fruits grown.

Nature is designed to provide the sustenance and in this case will be the SUBJECT. The trees retrieve this sustenance and will in this case be the OBSERVER.

Below shows a class diagram of the observer pattern and how it will be implemented in code.

 

 Code

This is the subject interface which will be implemented by the Subject class nature.

This is the observer interface which will be implemented by the tree classes

 The subject class

Below is an observer class 

the programs main function

when complied these are the results I received

Conclusion

I constructed this code as a simple example to get acquainted with the fundamental implementation of the observer pattern.

The benefits of the observer pattern is that if you wish to change the parameters of the subject you don’t have to make changes to all the observers. The subject and observers are loosely coupled so it doesn’t matter what type the observers are, as long as they implement the Observer interface then everything will run nice. The observer could be a colony of ants or a mushroom.  You could also change how each observer manipulates the parameter data without having to edit any other of the registered observers or the subject itself. 

Once I have learned the fundamentals of each design pattern I will revise the objective pattern as its complexity extends beyond the small example I gave. For instance the iObserver and iObservable interface in .Net is something I hope to explore.

 

Design Patterns

I have created this blog because as a fairly junior programmer I often discover and implement different programming technologies and methods.

I have found problems memorising and keeping track of these technologies and methods, so have started blogging as I believe that this may be the solution.

Being a programmer I am more acquainted with binary than grammar. So if you do take a liking to my posts than please excuse my literal deficiencies. Also if you notice any mistakes in my posts then I would fully appreciate if you correct me, or add ideas and any related content.

This particular blog is focused on design patterns. A Design pattern is a readymade solution to common issues within software design. These patterns are not actual finished code however they serve more as a template which can be reused.

You can find further information here 
 

As it is the first time I am discovering the use of design patterns some of the Post maybe fairly basic I hope to revise these posts when my understanding increases.

I have been using a book entitled ‘head first design patterns’ to gain my understanding of design patterns.  So far I have found the book very insightful also the way the content is formatted it makes it a very easy read.
 You can find this book here

I hope you enjoy.........................