This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
The objects can be related in any way. Maybe they need to work together, or perhaps they have similar responsibilities.
Take a look at the BorderFactory class in the standard API. It serves as a factory for all sorts of different Borders. As you can see, the objects are related in that they fulfill the same purpose.
Joined: Jul 17, 2008
Stephan van Hulst wrote:The objects can be related in any way. Maybe they need to work together, or perhaps they have similar responsibilities.
Thanks this makes sense, the example shown by you have one scenario where they have similar responsibilities. I'm sure there would be real world scenarios where it won't be really family of related objects.
But if think like this, since ProductA1 & ProducA2 have common super class AbstractProductA so they are family of related products. This may not hold true for AbstractProductA & AbstractProductB.
It would have been best if the stated INTENT had broader meaning. Example-
Abstract Factory offers the interface for creating multiple independent objects, without explicitly specifying their classes.
The family is actually Product A1 and Product B1; the other family is Product A2 and B2.
Like Stephan wrote, within a family, the classes can be related any way. They are logically related, rathern than through inheritance.
A good example is a set of classes that implements a look & feel: the Motif look and feel family will contain classes for buttons, text fields, etc.; the Windows look and feel will also contain classes for buttons, text fields etc.. The Windows button class is no family of the Motif button class, although they do share the same abstract parent. When switching look and feel, the Abstract Factory can provide you with a set of classes that supports this look and feel.