What is Factory Design Pattern

Factory design pattern is a creational pattern- which gives you more control on how you create objects.

The main objective is to encapsulate object creation.





Factory pattern basically comes in three flavours

A) Simple factory

There are three entities. Client- who needs to create objects. Factory- who does the actual creation. Product- the objects that are finally created.

The client has a reference to a the Factory (or this method createObject may be static as well)

The client then asks the factory to create the object it wants



B) Factory Method

It has two sets of classes- Creators and Products.These are implemented as parallel hierarchies

So we have Product A, B, C - (all implementing the same interface Product I)

And in parallel- we will have multiple creators- Creator A,B,C extending Creator Abs.

The Creator Abs defines how Product will be created

Creator A , B and C have specific knowledge about how their counterpart Products will be created

No one except Creator A should know about Product A



An abstract creationMethod is provided in the Abstract Creator

This will be implemented by the Creators A ,B,C



C) Abstract Factory Pattern

This is used to create a family of related objects rather than a single object.

We start with an abstract interface which defines the suite of objects to be created

like createValidator, createPreProcesor, createPostPorocssor.

We will then create a Factory which implements all these methods

The objects that this class will create will all be related or dependent

We can accordingly have another Factory which also implements the same interface- but this one creates another set of objects - also related to each other though



The second thing we need to do is define the family of objects

e.g. you have a POValidator and a DO Validator

POPreprocessor and a DOPreprocessor

PO Validator and DO validator belong to the same family and POPreProcessor and DOPreProcessor belong to another family

Whats the difference between Hashmap and Hashtable

Hastable is always synchronized.
Hashmap is by default - not synchronized- though it can be constructed as such

Hashtable doesn't allow null values. Hashmap does allow null values(Neither allows null keys)

How do you write threead safe programs

Thread safe program is one which will work well in an environment where there are multiple threads working in tandem.

Look out for global variables. These can be easily in the centre of a conflict between multiple threads
Its a common practise to declare static constants. Such constants should be declared as final whenever possible.
This will gaurantee that these do not get changed
If you have an intention of changingthese- then they shouldnt have been Static Variables probably

Thread safe program is achieved by taking care of the following
1) Write re-entrant code
This involves using variables created on stack (private variables) rather than variables created on heap (global)

2) Mutual Exclusion
Access to shared data is serialized- typically by using programming constructs like synchronized in Java.

3) Atomic operation
Using machine language instructions

4)Thread local storage
Not sure if Java provides this.

What is a Singleton Pattern

Singleton pattern is used to ensure there is one and only one instance of a class.

There are three parts to it

A. Ensure that we cant have more than one instance of the class
This is done by marking the constructor as private or protected
B. Provide a mechanism to access the singleton object. This is typically done by providing a static method to access the object. Something like getInstance ()method
C. Creation of the object.
This is by far the most tricky part.There are many ways to do so
1) Create the object using the static initializer or Construct the object at the time of declaration
This uses the classloader to create the object. You can run into issues in a J2EE environment where there can be multiple classloader
2) Use an inner static class. The singleton object is held in a static inner class. This will ensure that the object is not created until its really needed
3) Use double-checking mechanism. This means that we create the object in the getInsatnce() method- we check for NULL before creating the object. And the call to the creation of the object is enclosed withing synchronized block

Hibernate - a way of life

So I started reading this book- Hibernate in Action.
One of the things that hit me was- that Hibernate is not a persistence API alone
Its a way of life...
If you are simply planning to plug out your JDBC API and plug in instead Hibernate- you will not be able to get the full force out of it

( Of course in any re-factoring project- compromises are made to see what can be done and achieved within the boundaries of other constraints.)

What you really need to do is- move away from thinking in terms of tuples and data sets- and instead think more in terms of objects...

Given the fact most of the enterprise applications are coded in Object oriented languages- it shouldn't difficult

But the fact is that most designs are strongly dominated by the Database layer and user interface
These two ends are start- all and end-all for most workflows
It takes great effort and discipline to make sure that these concerns don't leak...

Anyway- its a nice book and am on to the fourth chapter tomorrow
Yay !!!

Putting the head where the patterns are...

So I needed to design an enhancement to the project I work on
I gleefully rubbed my hands and smirked- Now is the time when I put in all the patterns I learnt in the last 10 days or so- going through the Head First book

I decided to use Abstract Factory Pattern- keeping in mind the OOP principles I learnt
This pattern was a good fit.

Had I not read this book- I would have implemented this is a very different way
Its almost difficult to imagine how would I have done it....

But - it was not a easy exercise
Patterns are like guides
They show you the way- but then they offer you multiple paths
You get to choose what path to pick and how well you use it.

All said and done- I am pretty pleased with myself how it unfolded

InfoQ and eBay

yesterday I saw Randy Shoup's interview on InfoQ (http://www.infoq.com/presentations/shoup-ebay-architectural-principles)

Very intresting...
And I couldn't help compare our architeture with their's

And I started wondering could we incorporate some of their principals into our design?
We already have some- we too acknowledge the power of asynchronous processing
Though I feel we have not gone as far as we should\could have...

Our objects are too tightly coupled.

Another thing I liked what Randy said was about shorter transactions

I think there is great wisdom in that principle- it gives you lots of flexibility on how you can handle situations, faster performance,quicker response to all objects,fewer wait time all over

InfoQ seems to be a nice hangout- I intend to visit that place more often

Design Patterns:Template

So today I learnt the Template Design Pattern

Pretty neat pattern- or maybe its the guys at Head First who know how to get it into your head

So you have a bunch of algorithm to implement
Form a template method which outlines the generic algorithm
Put the common code in concrete methods in the abstract class- all variable code becomes abstract method- which are then overriden by the subclasses

and there you have a Template Design Pattern !!!