Shulou(Shulou.com)06/03 Report--

If this is the second time to see my article, you are welcome to scan the code at the end of the article to subscribe to my personal official account (cross-border architect).

The length of this article is 3012 words. It is recommended to read for 8 minutes.

Insist on originality, each article is written by heart ~

The following scene may seem familiar to you (Brother Z, I'm going to act again.

):

Brother Z: @ All brothers and sisters, this time I have a need to add a review to the "goods on the shelves", which will affect the interface between you and me. Let's take the time to change it and update the version tomorrow.

Little Y: brother, I am very busy these days. I just cooperated with Lao Wang to change the promotion yesterday!

Little X: OK ~ when everything has become a habit.

As an informed person, if a similar incident happens in your real work, I believe that even if you don't say it, you will still have a lot of thoughts and complaints in your heart: "md, if you have changed, I will also publish it." .

The root cause of this problem is that there is too much coupling between multiple projects.

The larger the project, the easier it is to fall into this Zhaotan.

The way to solve the problem is to carry out more reasonable layering, and continue to ensure the rationality of layering.

When it comes to layering, there must be six words "high cohesion" and "low coupling".

What is high cohesion and low coupling has been mentioned many times in previous articles that the essence of distributed systems is "divide and conquer" and "redundancy".

Among them, divide and conquer is the trilogy of "decompose-> govern-> merge". The concepts of "high cohesion" and "low coupling" come from this.

It is important to note that when you are doing the "decomposition" operation, be sure to pay attention to whether each "decomposition" meets one of the most important conditions: sub-problems on different branches can not be dependent on each other, but need to be independent.

Because once the dependency is included, the child problem and the parent problem lose the meaning that can be "merged".

For example, a "problem Z" is divided into two sub-problems, "sub-problem A" and "sub-problem B". However, the solution to question A depends on the answer to question B, and the solution to question B depends on the answer to question A. Doesn't this mean that there is no decomposition?

Digression: the idea of "how to break down the problem more reasonably" here can also be applied to any problem in your life and work.

So, when you are doing "decomposition", you need to have some good points to cut in.

This focus is the aforementioned "degree of coupling" and "degree of cohesion", which is a relationship between the growth and decline of the other.

The more you meet the standard of high cohesion and low coupling, the lower the maintenance cost of the program. Why? Because the smaller the dependence, the less the impact of their respective changes on other related parties.

Therefore, "high cohesion" and "low coupling" are the goals that we should continue to pursue.

Digression: the degree of coupling refers to the degree of interdependence between software modules. For example, if method B needs to be called synchronously after each call to method A, the coupling between method An and B is high.

Cohesion refers to the degree of similarity that elements in a module have in common. For example, if multiple methods in a class have a lot in common, they all do payment-related processing, then the cohesion of this class is high.

How to do well high cohesion and low coupling

To do a good job of high cohesion and low coupling, the idea is also very simple: define responsibilities, classify, and draw boundaries.

First of all, responsibility is to define the responsibilities of each subsystem, every module, and even every class and every function.

For example, this can be done at the subsystem or module level.

For example, this can be done at the class or function level.

I think everyone will do this consciously.

After the responsibility definition is done, the cohesion will be greatly improved, and the degree of code / program reuse will be improved at the same time.

At this point, we can talk about the application of the design principle of "single responsibility (SRP)".

Secondly, do the classification. Sort out the dependencies between different modules.

Case 1 like the one mentioned above can be classified as three layers:

Basic layer: commodity basic service, member basic service, promotion basic service

Aggregation layer: shopping cart service, commodity details service, login service

Access layer: flash store API, integrated mall API

Case 2 can also be classified as three tiers:

Data access layer: access membership table data, access membership score table data, access member rating table data

Business logic layer: member login logic, member use points logic, member upgrade logic

Application layer: receive the account password entered by the user, receive the usage product score entered by the user, and receive the payment information of the user

Finally, the boundary is drawn. It is not easy to sort out clearly, in order to avoid being easily destroyed again, so it is necessary to set up a reasonable and clear boundary.

Otherwise, you think it's so neat.

It's going to turn into such a mess.

So how to draw the boundary?

Class and function levels. This level can be done through codereview or static code testing tools, such as:

Some class calls must be done through interface instead of implement

Function that accesses commodity data cannot exist in class that accesses membership table data.

Module level. You can choose the following scenarios:

Assign a different project to each type of class and package it into its own dll (jar)

Every time the code push comes up, check whether the dependency in it exceeds the specified dependency. For example, there is no reverse dependency (to detect whether dal contains bll) and no aggregation business at the basic layer (dll (jar) to detect whether commodity basic services contain other basic services).

System level. To timely identify whether the calls between subsystems are as expected, you can analyze whether the request link is legitimate by accessing a call chain tracking system (such as zipkin).

Best practices that make boundaries clearer and more stable often different modules or subsystems are assigned to different groups, so Brother Z shares a few best practices with you. It can make the communication between systems more stable.

First of all: the interface part of the module exposed to the outside, the choice of data types as far as possible to achieve wide in and strict out. For example, use long instead of data types such as byte; use weak types instead of strong types, and so on.

Take an example of "lenient entry and strict exit":

/ / use long instead of data types such as byte.

Void Add (long param1, long param2) {

If (param1

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.