This article is conducted in dialogue mode. To complete the dialogue, I have decided to split myself into two parts: “Wind Sea” and “gong”.

Wind hai: Causeway, I heard that your file manager project is going very well recently. Come on, show me where you are. Well, this button doesn’t feel cool enough. Here, add a fluorescent effect, stroke a border, and insert a small icon in the middle…

Gong: Go on, Windy man. Even if you want to change the buttons, you have to obey the basic law. Haven’t you seen that the whole product is “simple”?

The sea wind: emm… All right. But cool people like me don’t like your interface. Let’s talk about it. Let’s say I’m a product manager and I want your interface to be both simple and cool. What would you do?

Gong: Well, I’m a personal developer, so don’t worry about that. But if you’re the product manager of the company, THEN I have to do what I’m told. Indeed, for some products, skin change is very suitable for the needs of personalized people, such as QQ on PC.

Fenghai: Yeah, skin changes are so cool. QQ can do skin changes, and there are all kinds of MUSIC players on the PC side. Oh, there are input methods.

Gong: Well, every product has its own visual architecture. For example, QQ has a friend bar, a dialog box, a function button bar and so on. Music player has sound display area, button area. If you’re going to do a skin change, you need to define the visual architecture of the product and then do the abstraction.

Fenghai: I can’t seem to understand. Let me ask you, if you want to change the skin of this button, what should you do specifically? Oh, wait, your button is cool, but the title bar is still corny. No, let’s change it.

Gong: Look, look, just changing a button won’t solve the problem. You mentioned the title bar again, so it’s a complete design. I’m going to start with those two, you want the buttons and the title bar to be dynamic, right? Let me design a class that satisfies you:

class UI_AbstractFactory {
    func createButton(a) -> Button? { nil }
    func createTopBar(a) -> TopBar? { nil}}Copy the code

Windy: I see Factory. That means you need to use Factory mode. We’ve talked about this mode before.

Gong: You have a good memory. Yes, we’ve talked about the factory model, and this is the factory model, but we can talk about it because it’s a derivative of the factory model: the Abstract Factory model.

Fenghai: No wonder there is an Abstract in front of it. So what’s the difference between the abstract factory pattern and the regular factory pattern?

Gong: In normal factory mode, the factory is responsible for creating objects that the interface user needs, but the interface user doesn’t need to care about the specific object type, just the known return object type and interface.

For example, when I use a view factory, the factory can give me the necessary views that I need to display, and I don’t care whether it’s an image view or a video view.

The abstract factory pattern is also a factory pattern, but with the following differences:

  1. There is an abstract factory type that is an abstract type definition that defines a concrete production interface but is not responsible for a concrete production task.
  2. Specific production tasks are assigned to specific factory types, which clearly define the production interface and what type of production objects should be produced.

Windy: Oh, I see. That is to say, in your example UI_AbstractFactory is an abstract factory, I’ll call it “UI factory”. The UI factory is abstract, so the specific production task will be assigned to the specific factory, right?

Gong: Yeah, that’s a good name for your UI factory. I created a UI factory here that provides various UI interfaces, such as buttons and title bars. But how to implement these interfaces is left up to specific factories. For example, I’ve defined a “minimalist UI factory” right now.

class SimplifyUI_Factory: UI_AbstractFactory {
    func createButton(a) -> Button? {
        return SimplifyButton()}func createTopBar(a) -> TopBar? {
        return SimplifyTopBar()}}Copy the code

Windy: I see! You made the factory “abstract” so that you can flexibly configure the factory types. For example, if you implement a “minimalist UI factory”, you can implement a “cool UI factory” to meet my needs.

Gong: Well, it’s just to meet your needs, or I would write abstract factory patterns. After all, programmers don’t mess around with themselves. Design patterns are designed to solve requirements.

Windhai: No, you’re confusing me. You might as well write me a cool UI factory.

Gong: Ok.

class CoolUI_Factory: UI_AbstractFactory {
    func createButton(a) -> Button? {
        return CoolButton()}func createTopBar(a) -> TopBar? {
        return CoolTopBar()}}Copy the code

If you want to manufacture in a cool factory, here’s the code

var factory: UI_AbstractFactory?
.
factory = CoolUI_Factory(a).

let button = factory.createButton()
.
let topbar = factory.createTopBar()
.

Copy the code

Windy: Well, cool UI factory does make cool titles and top bars. The so-called dragon born dragon born chicken, different factories are responsible for the production of different props. They do their job, which is great, but the key thing is, if you want to switch, you can switch in batches instead of one by one.

Gong: Yes, that’s right, that’s the core value of the Abstract factory model.

Let’s look at the definition of the abstract factory pattern in Wikipedia.

Abstract Factory Pattern is a software development design pattern. The abstract factory pattern provides a way to encapsulate a set of separate factories with the same topic. In normal use, a client program creates a concrete implementation of an abstract factory, and then uses the abstract factory as an interface to create concrete objects for that topic. The client program does not need to know (or care) about the specific types of objects it obtains from these internal factory methods, because the client program only uses the generic interfaces of these objects. The Abstract factory pattern separates the implementation details of a set of objects from their general use.

Fenghai: Well, I see that there are three types of factory models on the Internet: simple factory model, ordinary factory model and abstract factory model. And we seem to be talking about two categories. Why is that?

Gong: Yes, we talked about the factory model example earlier. In fact, the difference between the simple factory mode and the ordinary factory mode is relatively small, which can be put together. The difference is that in the simple factory mode, the factory is directly responsible for the production of products, while in the ordinary factory mode, the factory is an abstract class, and the specific production behavior is entrusted to the specific factory. In the abstract factory pattern, the factory produces not just one object, but multiple objects.

Fenghai: In that case, abstract factory mode is really suitable for skin changing and switching between Mac and Win styles when making PC software.

Gong: Yes, as far as the need for “bulk interface replacement” is concerned. You can see if you need an abstract factory pattern.

Windy: Great. Today is Saturday. Let’s go and have a good meal. Have a great weekend.

Gong: Have a good weekend. Let’s go.