I. Introduction
1.1 use scenario
The abstract factory pattern can be used in the following situations:
1) A system should not depend on the details of how product class instances are created, combined, and expressed, which is important for all types of factory patterns. Users do not need to create relational objects, and decouple the creation and use of objects.
2) There are product families for one in the system, and only one product family is used at a time. Users can change product families dynamically through configuration files and other ways, and can easily add new product families.
3) Products belonging to the same product family will be used together, which must be reflected in the design of the system. Products in the same product family can have no relation objects, but they all have some common constraints, such as buttons and text boxes under the same operating system. There is no direct relationship between buttons and text, but they all belong to a certain operating system. At this time, they have a common constraint: the type of operating system.
4) The system provides a product class library, all products appear with the same interface, so that the client does not depend on the specific implementation. For these products, users only need to know what specific business methods they provide, rather than the creation process of these objects. In the client code, specific classes are written to the configuration file for abstract programming.
1.2 advantages
1) Abstract factory pattern isolates the generation of concrete classes, so that the client does not need to know what is created. Because of this isolation, it is relatively easy to replace a specific plant. All concrete factories implement those common interfaces defined in abstract factories, so only changing the instances of concrete factories can change the behavior of the whole software system to some extent. In addition, the application of abstract factory pattern can achieve the design purpose of high cohesion and low coupling, so abstract factory pattern has been widely used.
2) When multiple objects in a product family are designed to work together, it can ensure that clients always use only objects in the same product family. This is a very practical design pattern for some software systems that need to determine their behavior according to the current environment.
3) It is very convenient to add new specific factories and product families. It does not need to modify the existing system and conforms to the "opening and closing principle".
1.3 disadvantages
When adding new product objects, it is difficult to expand the abstract factory to produce new kinds of products. This is because all product collections that may be created are specified in the abstract factory role. To support new kinds of products means to expand the loan, which will involve the modification of the abstract factory role and its subclasses, which will obviously bring great inconvenience.
Two, example
2.0 structure diagram
2.1 abstract product class Television
public interface Television { public void play(); }
2.2 Haier television
public class HaierTelevision implements Television{ @Override public void play() { System.out.println("Haier TV broadcasting....."); } }
2.3 specific product category TCLTelevision
public class TCLTelevision implements Television{ @Override public void play() { System.out.println("TCL On TV....."); } }
2.4 air condition of abstract product class
public interface AirConditioner { public void changeTemperature(); }
2.5 specific product tclaircondition
public class TCLAirConditioner implements AirConditioner{ @Override public void changeTemperature() { System.out.println("TCL Air conditioning changing temperature...."); } }
2.6 hairaircondition of specific product category
public class HairAirConditioner implements AirConditioner{ @Override public void changeTemperature() { System.out.println("Haier air conditioning temperature changing..."); } }
2.7 Abstract Factory
public interface EFactory { public Television produceTelevision(); public AirConditioner produceAirConditioner(); }
2.8 specific factory class HaierFactory
public class HaierFactory implements EFactory{ @Override public Television produceTelevision() { return new HaierTelevision(); } @Override public AirConditioner produceAirConditioner() { return new HairAirConditioner(); } }
2.9 factory specific TCLFactory
public class TCLFactory implements EFactory{ @Override public Television produceTelevision() { return new TCLTelevision(); } @Override public AirConditioner produceAirConditioner() { return new TCLAirConditioner(); } }
