directory

MVP stuff (1)… Speak with the scene

MVP stuff (2)… A Preliminary study on MVC Architecture

MVP stuff (3)… Using MVC in Android (Part 1)

MVP stuff (4)… Using MVC in Android (Part 2)

MVP stuff (5)… The relationship between the mediator model and MVP

MVP stuff (6)… MVC turned into MVP

MVP stuff (7)… Repository Design analysis

Quickly review

MVP stuff (4)… Using MVC in Android (Part 2)

MVC characters through the surveillance mechanism have to accomplish, and became a conveyor belt, let it flow among them, perhaps in the future, we can in this ribbon on the key link to multiple processing method of events, and exposed them for users to customize their specific function, make it to be extensible features.Each of them in this pictureDotted line dotExtensibility is a key feature to consider when designing a framework.

preface

The MVC framework has been introduced and built in a lot of detail in order to smooth the transition to MVP. Before starting, if you still have a vague understanding of the CONCEPT of MVC architecture, you can go back to the previous chapter. This chapter focuses on the differences between MVC and MVP. I won’t talk too much about what they have in common. For those of you who have read this chapter, it will be relatively easy to understand and grasp the essence of MVP.

Is there anything more specific?

To better understand the difference between MVC and MVP, talk about them concretely and avoid being abstract. MVP is made up for the inadequacy of the MVC one, must be regarded as a kind of ascension, and that the process of ascension is also thought of ascension, all to the design idea, and fled out of the public thought, when we deal with some problems, will encounter some obstacles, people accumulated some experience, when dealing with these problems in order to later can little detours, These experiences are handed down and summarized into a book, there are 36 ancient Sun Tzu’s art of war, and now there are 23 GoF design modes, all of which are the optimal strategies formulated to solve some scene problems. So, in the process of upgrading MVC to MVP, will there be some design ideas left by predecessors worth learning from? When I focused on MVP, I found that the intermediary design mode was in great agreement with the core idea of MVP. Both of them had the characteristics of “isolation and scheduling”. Compared with the abstract architecture, the design mode was more specific in learning and understanding, and could play a role in smoothing the transition. In particular, I want to talk about the essential difference between MVC and MVP from the perspective of the intermediary model. The main purpose is to extend the abstract architecture through a concrete example, so that people can deepen their understanding, grasp the essence and use it flexibly.

Mediator Mode

Starting with a more abstract definition, the mediator pattern emerged to solve complex reference relationships between objects, known as “scheduling.” To quickly understand the core values of the mediator pattern, let’s introduce a scenario that more concretely examines this definition,

Scene description

To start shooting a movie, you are actors in the cast, you have a lot of colleagues, such as fellow actors small yan, lighting: light, martial arts guidance: small arms, field control, executive director, management, service colleagues, etc., regardless of the group or organization, everyone must be avoid in the process of work is communication.

Colleague

First of all, from the view of you as a starting point, your colleagues (actor, lighting, martial arts instruction, executive director, the suit) unified class called colleague, secondly, from the perspective of other colleagues, you in the eyes of other colleagues and their colleagues class, you are the kind of person, can be called a colleague class, this is colleague class definition.

A ‘class’ is loosely defined as having at least one or more behaviors in common, and in this case everyone is part of the crew.

Make the job a little harder

1. Due to the early stage planning, the chief director did not arrive at his post.

2, the construction period varies, and the construction is forced.

With no one in charge of process management, communication becomes chaotic.

Below, a GIF is used to illustrate the “chaotic” communication scene.

Think much step: if we are going to the above scenario design into code, will find that each colleague class will depend on other colleagues class object, this is obviously not reasonable, with the increase of colleagues class, such dependencies will also increase, it is not hard to imagine that such a code is difficult to maintain and expand, it is easy to understand, right?

4. When the whole cast was in “chaos”, thankfully, the chief director finally arrived and decided to solve the chaos. If you want to trouble people, please bother me alone. Colleagues class all communication to report to the director, and then let the director to make a decision and forward orders to the appropriate colleague, banned direct communication between colleagues and his colleagues, such as martial arts instruction put forward a new idea, have to transfer to the director, is determined by the director again, really need those colleagues to participate in this new idea. In this way, the martial arts director can only rely on the chief director, and other colleagues can also rely on the chief director to communicate with other colleagues. I can see whether the chief director’s decision here is like a mediator.

Think one more step: At work, we often by WeChat group as a medium of communication, and the group is the existence of a mediator, everyone can throw the information to this group, although the “group” will not be this information voluntarily or tell the related colleagues to this information, but in this group of people to register and to monitor the group, Once you find information relevant to you (condition true), you can process that information. Therefore, it can be summarized as follows: members of a group only have a unique dependency relationship with the “group”, and they can work together without directly communicating with other members, which is also the only principle for the establishment of the intermediary mode.

The role of an intermediary

Through the above scenario description, we gradually understand in what scenario need mediator involved, as well as the responsibilities, the role of broker and broker mode established the principle of here, the director assumes the role of mediator, relative to his colleagues is mediator class class, the mediator design pattern involves only two characters, colleagues and broker.

The role of the mediator is to keep colleagues from ever seeing each other — separate. And responsible for collecting and transferring the events between colleagues and doing some process control during this period.

The responsibilities of the colleague class

Coworkers are common behaviors, such as going to work, leaving work, and eating lunch. The colleague class can also be completely devoid of common behavior. For example, there may be a group of colleagues who only act, and there may be a group of colleagues who only order food, and the actor who does not order food, and the caterer who does not act.

Think a little further: why emphasize common behaviors? In design or coding, we tend to sink common behaviors, and we might abstract out a “super colleague class” to describe the behavior of the colleague class. Sinking behavior implies that the behavior is extensible.

After understanding the application scenarios of the intermediary mode, we explain how the cast with the intermediary (chief director) communicates through the movement diagram:

Use a mediator

All objects only interact with the mediator, who is responsible for processing logic and forwarding events, or the colleague class actively listens to all events received by the mediator, and it is up to each colleague class to decide whether to process events or not (wechat group example).

Think one more step: Can the mediator be fat? Will it become bloated as it takes on most of the responsibilities? There are two ways to avoid this problem: first, the colleague class handles the necessary work as much as possible within its scope. 2. In practical use, intermediaries can divide their work according to specific scenes and deal with the work in a decentralized manner, because intermediaries are also a kind of role, and there will be many of them.

So what does the mediator model have to do with MVP architecture? Let’s simplify the above two diagrams. Remember how we introduced the MVC architecture diagram earlier? That’s right, turning the concrete into the abstract.

abstract

Let’s first change the number of colleague classes from 5 to 3:

By reducing the colleague class, we generate a comparison diagram of the scenario without a mediator on the left and the scenario with a mediator on the right. Does this look familiar to you on the left? If you read my previous articles or if you know anything about MVC, doesn’t it look like an architecture diagram of MVC? Does the picture on the right look like MVP? Some may doubt, like like, but one is a model, is used to solve practical problems, and the other one is the architecture, can not compare, of course I also in the previous article on this problem, design patterns and architecture is not a concept, to explain, said no broker mode is the MVP architecture, but refer to some ideas of the mediator pattern, At least in terms of numbers, there is no upper limit to the number of intermediary colleague classes, while MVP only has two colleagues, M and V, referring to the same class of colleagues, not all instantiated colleagues.When we pull representational business scenarios upwards until they become abstractFinally, we found that peer classes in the mediator pattern are just like the three layers in MVC. They are colleagues of each other, and point to point communication regardless of the cost of coupling.The Controller does not isolate colleaguesIn MVP, M and V are isolated and all communication is carried out through P. This is similar to the idea of the intermediary mode, but the intermediary is more inclined to the actual scene and more concrete.

Many want to step

There can’t be just one actor, or martial arts director, or even a director (the characters we’re talking about here are all pre-generic, i.e. interfaces). For example, in the process of filming somehow changed a director again, no matter how to change his core duty is broker, or another actor, he might be his unique character, but the core or a colleague will act, in reality, the personnel to mobilize will exist, if everyone is a point-to-point communication, so coupling is unavoidable, Assume that a martial arts director role relies on at least four other colleagues, and when the martial arts director is no longer available or needs to be replaced, the behavior between them disappears and becomes unusable. But with the intermediary, the communication between colleagues does not need to know who is the recipient, all this is to worry about the intermediary. The peer class also doesn’t need to know who the intermediary class is, because they are completely transparent. Maybe the next day, the message you receive in your INSTANT messaging software is from another director. This is called “encapsulation/isolation”, which is the essence of the interface.

Intricate relationships between objects

In the section on the Mediator pattern, we learned that the core value of the pattern is to solve complex relationships between objects, but beyond that, it has a very cool extensibility capability that is most important for MVP — reusability and extensibility. Reusability and extensibility are key to using MVP well

MVP scalability

We continue to illustrate the expansibility of MVP through the previous scenario. At the beginning of the project, only IOS software was developed. At that time, the company decided to add Andoird platform. Because IOS and Android programmers have a common ability, is the interface understanding, and understanding of design and the demand is consistent, but they use the platform is different, so the generalization of programmers, we as long as this can be an open platform, the UI is the same, they are using tools and design draft, But the size of the cut diagram is different, and the product manager, project manager, test engineer and background engineer can be directly reused, without the need to set up another team, which is a very cost saving thing for the company, and at the same time, the ability of the programmer group and UI group has been expanded. To take another example, in the process of project development, due to catch up with the schedule, the project manager needs to work overtime. However, the project manager cannot work overtime on Saturday and Sunday, so the company assigns an overtime project manager. He only works on Saturday and Sunday. Since he works overtime, the overtime project manager decides to change the working time from 7:00 to 5:00. In this way, when the project is in overtime, the staff will leave at 5:00, and our project manager can decide the working time, which is open. Very unfortunately, our product manager also need to work overtime a product manager, this work overtime work overtime product manager, he didn’t know the difference between the project manager and project manager, he always thought that work time is five o ‘clock, but in fact he don’t need to care about, the same, work overtime project managers don’t know if this is work overtime is a product manager, product manager, he also need not care about this, They are always transparent with each other. (Look at this image carefully and feel it.)

conclusion

We seem to be talking about broker, in fact only deals with the advantages of MVP architecture through broker, mediator pattern is in order to solve the fault in the complex relationships between objects, in the absence of mediator, all objects to know each other, a broker, it contains the control logic of the whole system, the broker in addition to decoupling and increasing object reuse, There are also several benefits

Centralized control logic and clear responsibility make the module more convenient to maintain

MVP is designed to solve the problem of strong coupling between MVC layers and inflexible expansion. So in MVP, P can be designed as an interface, and M and V can be designed as an interface to maximize the value of MVP.

When using MVP, it is not necessary to interface. It is necessary to design according to the actual situation. If there is only one instance that appears to use the MVP architecture for design, but only in appearance. Is the project at a point where reusability and extensibility need to be considered? Still, it’s better to write them as a blob, with fewer unnecessary classes that are easier to read and maintain.