My reasoning would be thus.... The Abstract Factory Pattern is used to create a family of related or dependent classes. Let me try to illustrate it with the classic non-software example: Let's say you went into a McDonalds... In our example, they sell combo meals, or individual items. Main Meal: Hamburgers or Chicken Sandwidth Side Order: Fries or Onion Rings Drink: Coke, Sprite Note that a combo is defined as a combination of three different product lines (one item from each). Situation 1: They have Pre-defined combos. Combo 1: HB, Fries, Coke Combo 2: CS, Onion Rings, Sprite In this example the combos are fixed...this is an ideal example for the Abstract Factory....i.e, the AF can only return you Combo 1 or Combo 2...it cannot make up arbitrary combos (even though the items are well defined), and each combo is a combination of related products (a main meal, a side order and a drink). Situation 2: Build your own Combo Combo 1: HB, Fries, Coke Combo 2: HB, Fries, Sprite Combo 3: HB, OR, Coke Combo 4: HB, OR, Sprite Combo 5: CS, Fries, Coke : : : : Combo 8: CS, OR, Sprite Here again, a combo is well defined (one main dish, one side order, and a drink)....however you have more flexibility to build your own combo meal...prime example for Builder! Situation 3: Individual Items Example: 3 Hamburgers, 2 Chicken Sandwidches...No set definitions, you buy everything Ala Carte. Beautiful scenario for Prototype. Of course you can also combine patterns...e.g., use 3 Combo Meals (get a combo meal by AF or Builder and then prototype it)... If you just wanted one item (HB or CS), you can go with Factory (remember AF is for a family of related objects...think of it as a factory of factories). If you had only one store, you could use a singleton to get a reference to it each time a customer or supplier wanted directions. That's pretty much your creational patterns... real easy and real cool. As you can see, Builder offers more flexibility over AF...choose Builder when the specific items in the family are not well defined and AF when they are. Whenever you do not understand patterns, go to non-software examples...the real world is also object oriented, and a hell of a lot easier to understand. Hope this helps.
Sanjay Raghavan<br />SCJP2, SCEA-J2EE<br />Moderator - <a href="http://groups.yahoo.com/group/scea_prep" target="_blank" rel="nofollow">SCEA PREP</a><br />Co-Author - <a href="http://www.whizlabs.com/scea/scea.html" target="_blank" rel="nofollow">SCEA@Whiz</a><br /><i>Where did you sip your Java Today?</i>
Joined: Dec 18, 2002
Thanks Sanjay, I think understanding design patterns would be much easier when we compare them with non IT related things, thanks once again !