Context:
1. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
2.Similar to Factory Method, but in AF the task of object creation is delegated to a different object, rather than just to a subclass.
3.The delegated object (the Abstract Factory) may itself make use of the Factory Method pattern.
Problem: Modularization is a big issue in today's programming. Programmers all over the world are trying to avoid the idea of adding code to existing classes in order to make them support encapsulating more general information. Take the case of a information manager which manages phone number. Phone numbers have a particular rule on which they get generated depending on areas and countries. If at some point the application should be changed in order to support adding numbers form a new country, the code of the application would have to be changed and it would become more and more complicated.
Solution: In order to prevent it, the Abstract Factory design pattern is used. Using this pattern a framework is defined, which produces objects that follow a general pattern and at runtime this factory is paired with any concrete factory to produce objects that follow the pattern of a certain country. In other words, the Abstract Factory is a super-factory which creates other factories (Factory of factories).
Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes.
This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory.
STRUCTURE

The base component of the pattern are the abstract factory and the abstract products denoted by A and B in this case. To use the pattern a designer creates a concrete factory as a subclass of the abstract factory. In the fig two such classes have been designed concreteFactory1 and concreteFactory2. To accompany the new factory type, a concrete class is required for each product in the product suite. ConcreteFactory1 would thus be designed in tandem with product types Product A1,ProductB1 and so on for the other products.The different factories share a common interface, that designated by the AbstractFactory base.In the implementation of the operations the concrete factories create and make available their particular product types.client code references these product in terms of abstract product types only.
Example:Suppose we plan to manage address and telephone information in our application (Example Personal Informational manager) system. We will initially produce classes to represent Address and Telephone number data. Code these classes so that they store the relavent information and enforce business rules about their format.Ex: In few indian cities all telephone numbers are limited to 7 digits.Shortly we get another requirement to manage this application for another city/country.So we modify our logic in the Address and PhoneNumber to satisfy rules for another city/country and all of a sudden after managing for many countries sees our classes get bloated with code and difficult to manage. With every country added, we need to modify and recompile the classes to manage contact information.
It's better to flexibly add these paired classes to the system; to take the general rules that apply to address and phone number data,and allow any number of possible foreign variations to be "loaded" into a system.
The abstract factory solves this problem.Using this pattern,you define an AddressFactory- a generic framework for producing objects that follow the general pattern for an Address and PhoneNumber.At runtime,this factory is paired with any number of concrete factories for different countries,and each country has its own version of Address and PhoneNumber classes.
Instead of going through nightmare of adding functional logic to the classes,extend the Address to USAddress and PhoneNumber to USPhoneNumber for country US.Instances of both classes are created by USAddressFactory.This gives greater freedom to extend your code without having to make major structural modifications in the rest of the system.
USES:In Swing, the look and feel is established by installing an Abstract Factory.
1. To set the look and feel to match that of the native platform:
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
2. Java.awtToolkit is an Abstract Factory.
CONSEQUENCES:
Benefits• Isolates concrete classes
• Allows to change product family easily
• Promotes consistency among products
Drawback• Adding a new product requires extending the abstract interface which implies that all of its derived concrete classes also must change. The following changes needs to be taken care of:
o New abstract product class is added
o New product implementation is added
o Abstract factory interface is extended
o Derived concrete factories must implement the extensions
o Client has to be extended to use the new product
No comments:
Post a Comment