Detailed Explanation of Abstract Factory Pattern in Android Programming Design Patterns

This article describes the abstract factory pattern in Android programming design patterns. Share it with everyone for reference, as follows:

One, Introduction

Abstract Factory Pattern (Abstract Factory Pattern) is also one of the creational design patterns. In the previous section, we have learned about the Factory Method Pattern. Then, what is this abstract factory? Let's associate it with real-life factories, which are definitely specific, that is, each factory will produce a certain type of specific product. Then, the abstract factory means that the products produced are uncertain, which is quite strange, isn't it? The abstract factory pattern originated from the graphical solutions for different operating systems in the past, such as the different implementations and display effects of buttons and text box controls in different operating systems. For each operating system, it itself constitutes a product category, and buttons and text box controls also constitute a product category. There are two product categories with two variations, each with its own characteristics, such as Button and TextView in Android, Button and TextView in iOS, and Button and TextView in Window Phone, etc.

Two, Definition

Provide an interface for creating a group of related or interdependent objects without specifying their specific classes.

Three, Application Scenarios

When a group of objects have the same constraints, the abstract factory pattern can be used. Does it sound abstract? Let me give you an example. Under Android, iOS, and Window Phone, there are messaging software and dialing software, both of which belong to the category of Software. However, they are on different operating system platforms, and even if the software is produced by the same company, the implementation logic of the code is different. In this case, it is considered to use the abstract factory method pattern to generate messaging software and dialing software for Android, iOS, and Window Phone.

Four, UML Class Diagram of Abstract Factory Pattern

UML Class Diagram:

Although there are many types of abstract factory method patterns, they are mainly divided into4Class:

AbstractFactory: An abstract factory role that declares a set of methods for creating a type of product, each method corresponding to a product.

ConcreteFactory: A specific factory role that implements the creation method of products defined in the abstract factory, generating a set of specific products that constitute a product category, each product located in a certain product hierarchy.

AbstractProduct：抽象产品角色，它为每种产品声明接口。

AbstractProduct: The abstract product role declares interfaces for each product.

ConcreteProduct: The concrete product role defines the specific product object produced by the specific factory, and implements the business methods declared in the abstract product interface.

5. Simple Implementation

For example, in the case of a car factory producing car parts, A and B car factories produce different tires, engines, and braking systems. Although the parts produced and models are different, fundamentally, there are common constraints, namely tires, engines, and braking systems.

public interface ITire {
  /**
   * Tire 
   */
  void tire();
}
public class NormalTire implements ITire{
  @Override
  public void tire() {
    System.out.println("Normal Tire");
  }
}
public class SUVTire implements ITire{
  @Override
  public void tire() {
    System.out.println("SUV Tire");
  }
}

Engine Related Classes:

public interface IEngine {
  /**
   *Engine 
   */
  void engine();
}
public class DomesticEngine implements IEngine{
  @Override
  public void engine() {
    System.out.println("Domestic Engine");
  }
}
public class ImportEngine implements IEngine{
  @Override
  public void engine() {
    System.out.println("Imported Engine");
  }
}

Braking System Related Classes:

public interface IBrake {
  /**
   *Braking System 
   */
  void brake();
}
public class NormalBrake implements IBrake{
  @Override
  public void brake() {
    System.out.println("Normal Braking");
  }
}
public class SeniorBrake implements IBrake{
  @Override
  public void brake() {
    System.out.println("Advanced Braking");
  }
}

Abstract Car Factory Class:

public abstract class CarFactory {
  /**
   * Manufacture Tire
   * 
   * @return Tire
   * */
  public abstract ITire createTire();
  /**
   * Manufacture Engine
   * 
   * @return Engine
   * */
  public abstract IEngine createEngine();
  /**
   * Produce Braking System
   * 
   * @return Braking System
   * */
  public abstract IBrake createBrake();
}

A Car Factory:

public class AFactory extends CarFactory{
  @Override
  public ITire createTire() {
    return new NormalTire();
  }
  @Override
  public IEngine createEngine() {
    return new DomesticEngine();
  }
  @Override
  public IBrake createBrake() {
    return new NormalBrake();
  }
}

B Car Factory:

public class BFactory extends CarFactory{
  @Override
  public ITire createTire() {
    return new SUVTire();
  }
  @Override
  public IEngine createEngine() {
    return new ImportEngine();
  }
  @Override
  public IBrake createBrake() {
    return new SeniorBrake();
  }
}

Client Class:

public class Client {
  public static void main(String[] args) {
    //A Car Factory
    CarFactory factoryA = new AFactory();
    factoryA.createTire().tire();
    factoryA.createEngine().engine();
    factoryA.createBrake().brake();
    System.out.println("---------------");
    //B Car Factory
    CarFactory factoryB = new BFactory();
    factoryB.createTire().tire();
    factoryB.createEngine().engine();
    factoryB.createBrake().brake();
  }
}

Result:

Normal Tire
Domestic Engine
Normal Braking
------------------
Off-road Tire
Imported Engine
Advanced Braking

It can be seen that the above simulation involves two car factories. If there are Factory C and Factory D, and the models and types of parts produced by each manufacturer are different, then the number of class files we create will double. This is also a drawback of the Abstract Factory pattern, so it needs to be weighed and used in actual development.

The Difference from the Factory Method Pattern

The factory method pattern was introduced in the previous section. So what is the difference between them? The abstract factory pattern is an upgraded version of the factory method pattern. The comparison is as follows:

Factory Method Pattern	Abstract Factory Pattern
There is only one abstract product class	There are multiple abstract product classes
The concrete factory class can only create an instance of a specific product class	The abstract factory class can create instances of multiple concrete product classes

7. Implementation in Source Code

The abstract factory pattern is used less in the Android source code because it is rare to have multiple product categories. Most of the time, the factory method pattern can solve the problem.

MediaPlayer

The MediaPlayer Factory will generate4Different MediaPlayer base classes: StagefrightPlayer, NuPlayerDriver, MidiFile, and TestPlayerStub, all of which inherit from MediaPlayerBase.

8. Summary

Advantages:

Separate the interface from the implementation, the client uses the abstract factory to create the required objects, and the client does not know the specific implementation, the client just programs the interface of the product, which makes it decouple from the specific product implementation, and at the same time, based on the separation of interface and implementation, makes the abstract factory method pattern more flexible and easier to switch product categories.

Disadvantages:

Firstly, there is an explosive increase in class files.

Secondly, it is not easy to expand new product categories.

Readers who are interested in more content related to Android can check the special topics on this site: 'Android Development入门与进阶教程', 'Android Debugging Skills and Common Problem Solving Methods Summary', 'Summary of Android Basic Component Usage', 'Summary of Android View View Skills', 'Summary of Android Layout Layout Skills', and 'Summary of Android Control Usage'.

I hope the content described in this article will be helpful to everyone in Android program design.

Declaration: The content of this article is from the Internet, and the copyright belongs to the original author. The content is contributed and uploaded by Internet users spontaneously. This website does not own the copyright, has not been manually edited, and does not assume any relevant legal liability. If you find any content suspected of copyright infringement, please send an email to: notice#w3Please replace '#' with '@' when sending an email for reporting. Provide relevant evidence, and once verified, this site will immediately delete the content suspected of infringement.