Single responsibility in software development (go to INFOQ)

Recently, in the process of practicing microservices, the principle of "single responsibility" has been deeply realized. Then only microservices can be a single duty, can decouple it? The answer is in the negative.

The single responsibility principle is defined in this way: single function, and fully encapsulated.

We do back-end Java development, should be most familiar with the standard 3-tier architecture, especially the use of Spring.io system: Controller, Service, Dao/repository. Why layering? is to ensure that a single responsibility, data model of the matter to the controller, business logic to the service, and data dealing with the matter to dao/repository. Sometimes or some people will be graded more, 4 layers, 5 layers, I have done so, and plainly is to ensure a single duty, 3 can not meet a single duty, the coupling degree is high, on the points.

We all know that a webapp after a certain period of development, it is miserable, even if there is a standard layering, page or template file a large pile, the original very clear 3-layer standard architecture is also stale, controller,service,dao/repository between the layers, Service, dao/repository between each other, mess. This time without changing a line of code is possible a mouse killed a pot of soup, the bug is like an ant hole.

These problems eventually result in:

• Poor scalability flexibility, performance issues
• Business change and development difficulties, high maintenance costs, long delivery times
• A lot of regression testing.
• ...

In order to solve these problems, it is necessary to remember the " single duty " at all times, and a single responsibility can be used anywhere in software development.

It should be said that segregation of duties is the most commonly used and most efficient architectural approach, which simplifies everything.

The following is a single responsibility from small to large in terms of software development, design, architecture, and refactoring/Evolution/Evolution:

class method/function

This should be the smallest program unit that can represent a single function . The most familiar of the most typical is the Helper/utils class method, but the characteristics of this kind of method is very obvious, it is easy to follow a single responsibility, more than 99% of developers can do. But not only is such a class method to follow a single responsibility principle, each class method should follow a single responsibility principle, especially some class methods dealing with business logic should follow a single responsibility principle, the class method of handling business usually should cooperate with the single responsibility principle of class, Discussed in the next section.

Therefore, this is also why many team leader require the class method code line number to keep at about 20 rows, in fact, in order to ensure a single duty, 20 rows or so is a rough number of experience , of course, 10 rows or 30 lines to complete the class method is also possible. Most of the single-duty class methods use around 20 lines of code, and if more than 20 lines are considered to guarantee a single duty. We should consider splitting such a class method to guarantee a single responsibility in the iterative refactoring process.

The single duty of the class method is the simplest, very specific, without any additional information, only concerned with input, output, and responsibility; it is important to define the responsibility of the class method explicitly, to ensure that the iteration is not extended in error and is not used incorrectly by the caller.

Class/function file

To define a class with an object-oriented design approach, a single responsibility principle . Developers must have a good understanding of the "single responsibility Principle", with object-oriented abstract thinking ability.

When a class is too large or fast expanding in an iteration, which means that there is already a bad taste, it is time to consider refactoring and redefining the class with a single responsibility principle or object-oriented analysis method, usually to abstract and split the classification, otherwise it will become a method container in the future.

The class is likened to a person, her duty is to complete their duties within the scope of things, if she is all things, call nosy, can imagine her meddling in the consequences, will stir jiquanbuning. Similarly, classes, if they are nosy, can make the whole application unstable, flawed, and difficult to fix. So define a class, and be clear about the responsibilities of this class. Using object-oriented analysis and design methods, you can define a class's scope of responsibility well, usually using encapsulation, inheritance, polymorphism, and abstraction, and other design methods.

Package Structure/Folder

Layering is one of the most commonly used architectural methods, and layering is embodied in subcontracting and classification, which is the meaning of categorization. As the saying goes, birds of a feather flock together.

Package structure in a single responsibility is in principle a complement to the class, and the scope of responsibility is further expanded. If a class is called a person, then the package is the smallest unit of the team, the responsibility is to be responsible for a particular kind of things.
How to subcontract it? That will use the knowledge of taxonomy, what characteristics to be divided, may not only have a feature, for example, the first use of the company domain name to do the basic package name, here is called a class package name, and then a specific meaningful identity as a level two sub-package name; then by layering (Web,dao, Service, and so on) method to do three-level package name, you can also first according to business and then layered. For example:

Domain Name: Tietang.wang There is a project called: Social so I can score: Wang.tietang    -Social        -web        -service        -DAO        - Commons can also do this: Wang.tietang    -Commons    -user        -web        -service        -DAO    -Relation        -web        -Service        -DAO           

Multi-engineering/module

Typically, multiple MAVEN module or gradle multiple module forms exist to guarantee a single duty.

When the volume of business has not yet reached the heat of service splitting, it is often necessary to standardize and organize the project structure when an app grows too large or in the early stages of construction. This time requires multiple projects to be isolated from the file system and integrated through module dependencies. It should be noted that such a structure or split is not arbitrary, to be split with a single principle of responsibility, more specifically, according to the business, technical framework functions and other features to split.

For example, by splitting a technical component, there are usually some technical components that can be put into the Commons module, and if there are multiple types of technical components, they are split into Commons module sub-modules, or they can be split directly into separate projects, exist in the independent GIT/SVN warehouse, independent management, personal responsibility, and other module needs to rely on her. Each of those split technical components should follow a single principle of responsibility, such as the framework for data fragmentation, the NIO basic network framework, and so on.

For example, split by business, such as users, orders, goods, payments, then split into sub-module according to these services, each sub-module only responsible for their own business logic, but also to follow a single responsibility.

The scope of responsibility of each module is larger than class and package, this time the responsibility is also more ambiguous, sometimes difficult to grasp, for the technical components may be relatively clear, and the business module will be familiar with the business, clear business boundaries.

After the multi-module split is also for the future service to bury the foreshadowing, at the same time in the physical file system is relatively clear, that in the dependency management should also grasp to maintain a clear reliance on logic, grasp the principle of single responsibility.

MicroServices/deployable Units

MicroServices, isolated from the runtime, but the volume of business developed to a certain time, from the monomer or multi-module engineering to split or evolve, can be individually packaged independently deployed and composite single principle of the application, of course, the value of micro-services is not only isolated and independent deployment, There are many references to the advantages and disadvantages of monomer application and micro-service. The value of a single responsibility in microservices is the most important, including the app level and the team level for developing apps, and most of the benefits of microservices can be built around a single responsibility.

Team

First quote "Han Fei zi Yang right" in a paragraph of the text:

The husband has the appropriate, the material has the application, everywhere its appropriate, therefore up and down inaction.
The night of the chicken, the raccoon, the rats, all use their energy, but nothing.
There is a director, the matter is not square.
RTHK and good can, under the bully: The argument, the next because of the material.
Easy to use, ancient capital died.

Have the proper and proper duties. Therefore, the team should also follow a single responsibility principle, so as to manage the team members ' time and improve the efficiency well. A person's focus on doing something is far more efficient than focusing on multiple things at the same time. It is also much more efficient for a person to manage and maintain the same code more efficiently than many people maintain multiple copies of the code at the same time. Each person has his own personality, he has his own good, let everyone focus on their own good things, that certainly more effective, the whole team performance is definitely also very prominent.

In short, the quote of ancient prose illustrates all:

• Birds of a feather, flock together.
• The things of the world, divided and alternating, divided long will be together, a long time will be divided!
• The night of the chicken, the raccoon, the rats, all use their energy, but nothing.

Reference

• http://www.jianshu.com/p/f9d15827465d
• https://zh.wikipedia.org/wiki/Single Function principle

Single responsibility in software development (go to INFOQ)