Java/android Design Patterns Learning notes (4)---abstract Factory mode

Introduce the abstract Factory mode (abstact Factory pattern), is also one of the creation mode, the previous blog mainly introduces the factory method mode. The abstract factory pattern differs slightly from the factory method pattern. Factory Model factory production products are specific, that is, each factory will produce a specific product, but if the factory class produced in a variety of products, factory method mode is no longer applicable, it is necessary to use the abstract factory model.
The origin of the abstract factory pattern or the earliest application, is the different operating systems of the graphical solution, such as the different operating system buttons and text box different processing, the display effect is not the same, for each operating system, itself constitutes a factory class, and button and text box control form a product class, There are two variations of the two product classes, each with its own features, such as Button and Text under Windows,unix and Mac OS. So we can initially build the framework:
　　
Then the Windowsbutton and Windowstext product class objects need to be generated for Windows systems, and the other two systems need the corresponding objects as well. In order to achieve the loosely coupled principle of "providing an interface to create a set of related or interdependent objects without specifying their specific class", the abstract factory pattern is very well suited.
PS: The technology is interested in the same shoe plus group 5,446,459,721 Exchange.

Total catalog of design patterns

Java/android design mode Learning Notes directory

features

Abstract Factory mode (Abstact Factory pattern) provides an interface for creating a family of related or dependent objects without explicitly specifying a specific class.
Like the factory method model, the abstract factory pattern still conforms to the principle of "abstract programming, not specific class programming", decoupling clients from specific classes, increasing extensibility, and matching the dependency inversion principle and the Richter substitution principle in design patterns.

UML class Diagram

Here is a graphical solution for the different operating systems above to draw a UML class diagram (it seems that the image width is fixed dead, in the new tab to open the image),
　　
Although the abstract factory pattern has a wide variety of classes, it is mainly divided into 4 categories:

• Abstractfactory: Abstract Factory role (corresponding to Ifactory interface), which declares a set of methods for creating different products, each of which corresponds to a product in which the Ifactory interface has Createbutton and CreateText methods for creating IButton objects and IText objects.
• Concretefactory: Specific factory roles (corresponding to Windowfactory,unixfactory and Macosfactory classes), which implements the method of creating a product defined in an abstract factory, producing a specific set of products that form a product category, Each product is located in a product hierarchy.
• Abstractproduct: Abstract product roles (corresponding to IButton and IText interfaces), he defines the basic behavior of several products.
• Concreteproduct: Specific product roles (corresponding to 6 implementation classes, such as Windowsbutton and Windowstext), which define specific product objects produced by a specific factory and implement the business methods declared in the abstract product interface.

Here is an example of a UML class diagram, corresponding to the abstract factory schema of the UML class diagram as long as the role of a name can be changed, is the same.

Example and source code

We directly construct four roles based on the UML class diagram above:

Product Related Categories

The product class is mainly the IButton interface and its implementation subclass, the IText interface and its implementation subclass. IButton interface and its subclasses:
Ibutton.class

publicinterface IButton {    void show();}

Windowsbutton.class

publicclass WindowsButton implements IButton {    @Override    publicvoidshow() {        Log.e("show""this is a Windows button");    }}

Unixbutton.class

publicclass UnixButton implements IButton{    @Override    publicvoidshow() {        Log.e("show""this is a Unix button");    }}

Macosbutton.class

publicclass MacOSButton implements IButton{    @Override    publicvoidshow() {        Log.e("show""this is a MacOS button");    }}

IText interface and its implementation subclasses:
Itext.class

publicinterface IText {    void show();}

Windowstext.class

publicclass WindowsText implements IText{    @Override    publicvoidshow() {        Log.e("show""this is a Windows text");    }}

Unixtext.class

publicclass UnixText implements IText{    @Override    publicvoidshow() {        Log.e("show""this is a Unix text");    }}

Macostext.class

publicclass MacOSText implements IText{    @Override    publicvoidshow() {        Log.e("show""this is a MacOS text");    }}

Factory related Classes

Define the relevant class of the factory after defining the related class of the product, the function of the factory class is to create the object of the corresponding two product categories:
Ifactory.class

publicinterface IFactory {    /**     * 生成对应按钮     */    IButton createButton();    /**     * 生成对应文字     */    IText createText();}

Windowsfactory.class

publicclass WindowsFactory implements IFactory {    @Override    publiccreateButton() {        returnnew WindowsButton();    }    @Override    publiccreateText() {        returnnew WindowsText();    }}

Unixfactory.class

publicclass UnixFactory implements IFactory{    @Override    publiccreateButton() {        returnnew UnixButton();    }    @Override    publiccreateText() {        returnnew UnixText();    }}

Macosfactory.class

publicclass MacOSFactory implements IFactory{    @Override    publiccreateButton() {        returnnew MacOSButton();    }    @Override    publiccreateText() {        returnnew MacOSText();    }}

Test

The final test procedure is also simple:

@Overridepublic void OnClick (View v) {switch (v. GetId()) {case R. ID. BTN_windows:windowsfactory windowsfactory = new Windowsfactory ();Windowsfactory. Createbutton(). Show();Windowsfactory. CreateText(). Show();             Break;Case R. ID. BTN_unix:unixfactory unixfactory = new Unixfactory ();Unixfactory. Createbutton(). Show();Unixfactory. CreateText(). Show();             Break;Case R. ID. BTN_macos:macosfactory macosfactory = new Macosfactory ();Macosfactory. Createbutton(). Show();Macosfactory. CreateText(). Show();             Break;}}

The log of the object can also be successfully printed:

Summary

Abstract Factory mode in the Android source of the implementation is relatively small, one of the more exact example is the Android bottom of the MediaPlayer, the specific class diagram is as follows (open the picture in a new tab):

The four mediaplayerfactory produce different MediaPlayer base classes: Stagefrightplayer, Nuplayerdriver, Midfile, and Testplayerstub, All four inherit from Mediaplayerbase.
There are many advantages of the abstract factory, a significant advantage is the separation of interfaces and implementations, the client uses the abstract factory to create the required objects, it does not know the specific implementation is who, the client is only for product-oriented interface programming, so that it is decoupled from the specific product implementation, and based on the separation of interface and implementation, Makes the abstract Factory mode more flexible and easy to switch between product classes.
Of course, the shortcomings are also obvious, the first and most obvious is the large increase in class files, the second is to expand the new product class, you need to modify the abstract factory class of the lowest interface, which will cause all the specific factory class will be modified.

comparison between abstract factory model and factory method model

In fact, comparing the UML diagram of the two modes, we can find that the factory method pattern is latent in the abstract Factory mode, and each method in the abstract factory can be extracted separately as a factory method. The task of an abstract factory is to define an interface that is responsible for creating a set of products, each of which is responsible for creating a specific product, while we provide these specific practices by implementing subclasses of the abstract factory, so it is quite natural to use factory methods to implement production methods in an abstract factory. In contrast, one of the advantages of an abstract factory model over a factory model is that it can assemble a group of related products.
In contrast, the usage scenario is clear: Use the abstract factory pattern when you need to create a product family and the related products that you want to make, and use the factory method pattern when you just want to decouple the customer code from the specific class that needs to be instantiated, or if you are not sure which specific classes you want to instantiate in the future.

Source Download

Https://github.com/zhaozepeng/Design-Patterns/tree/master/AbstactFactoryPattern

References

http://blog.csdn.net/jason0539/article/details/44976775
Https://en.wikipedia.org/wiki/Abstract_factory_pattern

Java/android Design Patterns Learning notes (4)---abstract Factory mode