DevLog

The pattern I am going to talk about today is the Observer Pattern. Another new and cool pattern to discuss.

Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Not clear? Its ok, we'll restate again.

The idea is simple, take the example of the publisher and subscibers!

A newspaper paper publisher publihes newspaper every morning right? nothing new :)

Suppose I am company X, and want to have the newspaper arrive to my officies every morning.

So I(observer) go to the publisher (subject) and tell him/her please I want to subscribe to your newspaper to get my newspaper (update) every morning.

What happens is that, once a new newspaper is published every morning, the publisher will update my office with that new newspaper.

So the main players are the Subject and Observer. The observer registers with the Subject, then the subject's responsiblity to update the state of each observer registered. Observers can register and unregister from a subject.

Usually we use two interfaces, one for the subject and one for the observers. This way any object wants to register with the subject has only to implement that interface.

Hope this helps you,

Regards

Tags: Design Patterns

This is the first post for me in the field of Design Patterns. I am new to this field, but decided to summarize each pattern I cover in my great book called: Head First Design Patterns.

The Strategy Pattern:

Defines a family of algorithms, encapsulates each one, and makes them interchangable. Strategy let the algorithm vary independently from clients that use it.

The idea is as follows: Suppose you are developing a game where you will have different players or characters. Each character can make use of one Weapon at a time, but can change the weapon at any time during the game.

We have several characters in the game, we think directly of having a base Character object, and each character can inherit from that base class.

Now, as mentioned, each character needs to use a weapon, which is nothing but a behaviour, but also wants to be able to change that weapon at run time. We might have different kinds of Weapons. Every weapon has a behaviour, so you might think of having an Interface called Weapon and all the behaviours of that Weapon will be represented by algorithms or objects implementing that interface, each having its own implementation of the Weapon, hence each having its own algorithm.

So the base class we had before, now has its own behaviour implemented by the family of algorithms that implement the Weapon Interface.

This way, any object inheriting from the base Character class, can use any Weapon implementation, and can change from one Weapon to another at run time, but means of an inherited member placed in the base Character class of type Weapon Interface.

So when you have several objects that are basically the same but only differ in their behaviours. It is better to use the Strategy pattern, in which you seperate the objects from their behaviour, making the addition of new behaviours easy, and then alalowing those objects to change any behaviour at run time and hence getting rid of the subclassing method to provide common behaviour to the objects.

Hope this helps,

Regards

Tags: Design Patterns