Factory approach (Factory method)

Defined

The factory method is also known as the fictional creator (virtual constructor), which is useful when the code is running, when it is not possible to determine the type the object is creating and needs its subclasses to be determined. In the context of object-oriented programming, the general situation is equivalent to the use of polymorphic characteristics, call the base class interface to create objects, and the subclass has implemented its own method of creating interfaces, the class diagram structure is as follows:

If you put aside the factory method pattern, then when you need to create objects, directly in the need to use the specific product class to create objects, but the code's stickiness (coupling degree) is relatively high, not conducive to subsequent code maintenance. Factory methods by increasing the structure of the plant, the code used is no longer dependent on the product, but relies solely on the corresponding factory, which is the object of the interface type, with the interface-oriented programming style.

A more formal factory method definition is as follows:

The FACTORY METHOD pattern:define an interface for creating a object, but let subclasses decide which class to Instantia Te. Factory Method lets a class defer instantiation to subclasses. * * The original definition appeared in Design Patterns, by the ' Gang of Four ' (addison-wesley,1994).

As you can see, the main focus of the definition is to let the subclass decide how to create the object, what type of alignment to create, and the factory method to defer instantiation of an object into its subclasses. In other words, the created object is determined by the factory, and once the factory is set, the product it creates is fixed. Generally, the factory method patterneach product corresponds to a factory, so if you add a product, you need to add the corresponding factory (this is more cumbersome), and what needs to be created by the specified product type into the designated factory. The factory method applies to the following conditions:

• The exact type of the object cannot be determined during code compilation
• You need to let the subclass decide the type of object created

code example

Different themes are needed in many places, and this example is done using theme changes. Where the theme view is the product, the theme view controller is the factory, and the main file structure of the code is as follows:

Where Canvasview is the default product, Themegenerate is the base class for the factory and the class responsible for producing the default product, while Papercanvasview and Clothcanvasview are two custom products, The corresponding factory class is also constructed for the two products, and its class diagram is as follows:

Since the code is used directly with the factory, and the factory class has the same interface, so the product interface can be different, three product definitions are as follows:

#import "CanvasView.h" @implementation canvasview-(ID) init{    if (self = [super init])    {        //set Default color        Self.backgroundcolor = [Uicolor whitecolor];    }    return self;} @end

#import "ClothCanvasView.h" @implementation clothcanvasview-(ID) init{    if (self = [super init])    {        Self.backgroundcolor = [Uicolor colorwithpatternimage:[uiimage imagenamed:@ "cloth.jpg"];    }    return self;} @end

#import "PaperCanvasView.h" @implementation papercanvasview-(ID) init{    if (self = [super init])    {        Self.backgroundcolor = [Uicolor colorwithpatternimage:[uiimage imagenamed:@ "paper.jpg"];    }    return self;} @end

The above three classes create views of different color backgrounds, and now require their corresponding factory classes, with inheritance relationships between factory classes.

#import "ThemeGenerate.h" @implementation themegenerate-(Canvasview *) canvasview{    //Default factory method returns the default theme (product)    return [[Canvasview alloc] init];} @end

#import "ClothThemeGenarate.h" #import "ClothCanvasView.h"//Inherit from Themegenerate@implementation cloththemegenarate-( Canvasview *) canvasview{    //Create cloth theme Product    return [[Clothcanvasview alloc] init];} @end

#import "PaperThemeGenarate.h" #import "PaperCanvasView.h"//Inherit from Themegenerate@implementation paperthemegenarate-( Canvasview *) canvasview{    //Create paper Theme product    return [[Papercanvasview alloc] init];} @end

Not a job. The production of a product, while providing a unified interface to the external, so that the client can be required to obtain the entire product through the interface, where the call is as follows

-(Ibaction) Changetheme: (ID) sender{    [_theme Removefromsuperview];        themegenerate* newtheme = nil;    if (sender = = _cloththeme)    {        newtheme = [[Cloththemegenarate alloc] init];    }    else if (sender = = _papertheme)    {        newtheme = [[Paperthemegenarate alloc] init];    }    else    {        newtheme = [[Themegenerate alloc] init];    }    _theme = Newtheme.canvasview;    _theme.frame = Self.view.frame;    [Self.view insertsubview:_theme atindex:0];}

The client directly through the call interface Canvasview can get their own products, if you want to add a class of products, directly create a product and factory class, modify the code is small.

Summarize

Factory methods can make the code structure clear and effectively encapsulate changes. In programming, the instantiation of the product class is sometimes more complex and changeable, through the Factory mode, the product instantiation encapsulation, so that the caller does not have to care about the product instantiation process, just rely on the factory can get the products they want. If you use Factory mode, the caller only cares about the interface of the product, and as for the specific implementation, the caller doesn't have to care. Even if a specific implementation is changed, it has no effect on the caller.

Factory approach (Factory method)