(1) Single Responsibility Principle "sole responsibility Principle"

Single principle of responsibility

Srp:single Responsibility Principle

"Overview" single responsibility principle, also known as single function principle, five basic principles of object-oriented(SOLID)one. It stipulates that a class should have only one reason for change. The principle by Robert •C• Martin(Robert c. Martin)in the Agile Software development:the principles, patterns and practices of the book. Martin says the principle is based on Tom Dimark(Tom DeMarco)and theMeilir Page-jonesThe principles of cohesion in the work of the author.

The so-called duty refers to the reason of class change. If a class has more than one motive to be changed, then the class has more than one responsibility. The single principle of responsibility refers to the reason that a class or module should have and only one change.

"Definition" does not have more than one cause for class changes. In layman's terms, a class is responsible for only one responsibility.

Principle

If a class takes on too much responsibility, it is tantamount to coupling those responsibilities together. A change in one's responsibilities may weaken or have been the ability of this class to perform other duties. This coupling leads to a fragile design that, when changed, is subjected to unexpected damage. If you want to avoid this phenomenon, we should observe the principle of single responsibility as much as possible. The core of this principle is decoupling and enhancement of cohesion.

"Problem origin" classTresponsible for two different responsibilities: responsibilitiesP1, ResponsibilityP2. When due to dutyP1Changes in requirements require modification of classesTmay lead to a normal functionP2function has failed.

"Cause"

No program designer should be able to write high-cohesion low-coupling programs, but many of the coupling often occurs inadvertently, the reason is:

Responsibility diffusion: For some reason, a duty is divided into more granular responsibilities.

the "solution" follows a single responsibility principle. Encapsulate different responsibilities into different classes or modules. Set up two classes respectivelyT1,T2, so thatT1Complete DutiesP1function,T2Complete DutiesP2function. This way, when you modify the classT1does not make the dutyP2the risk of failure and, similarly, when modifyingT2, nor does it make the dutyP1A failure risk occurs.

Although a single responsibility principle is so simple and considered common sense, even the program written by an experienced programmer can have code that violates this principle. Why is this happening? because there is responsibility to spread. The so-called responsibility spread, is for some reason, the responsibility P is divided into finer granularity of responsibility P1 and P2.

For example: ClassTonly responsible for one dutyP, so that the design is in line with the principle of single responsibility. Later for some reason, perhaps the need to change, perhaps the process of the designer realm has improved, the need to take responsibilityPsubdivided into finer-grained responsibilitiesP1,P2, if you want the program to follow a single responsibility principle, you need toTalso decomposed into two classesT1and theT2, respectively responsible forP1,P2two responsibilities. But when the program has been written, it's too time-consuming. So, simply modify the classT, it is a good choice to take charge of two responsibilities, although this is contrary to the principle of single responsibility. (The risk lies in the uncertainty of the spread of responsibility, because we do not think of this responsibilityP, in the future it may spread intoP1,P2,P3,P4...Pn. So remember to refactor the code immediately before it spreads to the point where we can't control it. )

Principles

Only logic is simple enough to violate the principle of single responsibility at the code level, and only if the number of methods in the class is small enough to violate the principle of single responsibility at the method level;

Advantages

Can reduce the complexity of the class, a class is responsible for only one responsibility, its logic is certainly more than the responsibility of more than the responsibility of more simple;

Improve the readability of the class, improve the maintainability of the system;

The risk of change is reduced, the change is inevitable, if a single responsibility principle is well adhered to, when a function is modified, it can significantly reduce the impact on other functions.

One thing that needs to be explained is that the single responsibility principle is not only specific to object-oriented programming, so long as it is a modular program design, it applies a single responsibility principle.

"Practical Application"

Single responsibility principle is one of the simplest principles in software design, and one of the most difficult principles to be used correctly. People will naturally combine their duties. In many cases software design really needs to do a lot of work to formally discover responsibilities and separate responsibilities from each other. Here are some common practical ways to introduce some of the single-responsibility principles.

Identifying responsibilities

The functions in each system represent a responsibility that can be mapped to a software module (class), and should be as far as possible to ensure that there is no functional duplication between the modules. The design should focus on only one responsibility at a time. But this is not to say that other responsibilities are left behind, but that when you decide to use a module to accomplish a certain duty, you only have to concentrate on that responsibility. From the point of view of this module, other duties are irrelevant.

Information hiding

The module (class) has its own exposed interface, can communicate with other modules, and the module also contains a lot of internal information for its own use. Only members exposed by the interface in the module can be used by other modules. Internal data is not completely hidden and should be filtered before it can be exposed to the outside. In this way, each module can still communicate using a fixed interface without being affected by the modification of the specific implementation.

Persistence of

separate long-lasting, stable data functions from frequently changing business rules. This way of persistence does not change frequently due to changes in the business layer. The most common application of this idea is the three-tier architecture and the MVC architecture.

"Related knowledge"

The single responsibility principle is not an isolated object-oriented design principle, it is the object-oriented design of five basic principles ( SOLID ) one. These principles are: Single duty principle, open and close principle, Richter replacement principle and dependency inversion principle. These principles can be used together to make a software system easier to maintain and extend. These principles are typically used in test-driven development, and are an important part of the guiding ideology of Agile Development and adaptive software development.

"History of development"

the single responsibility principle is the object-oriented five basic principles (SOLID) in theS. But he is not limited to programming languages, design methods, or even beyond the realm of pure programming, but also applies to many aspects of software architecture. and its development from1974year Ezra ·W• Dicos Beecher(Edsgerwybedijkstra) in the paper "In the Role of Scientificthoughtthe principle of separation of concerns and Tom Dimark.(Tomdemarco)in the paper "structed analsis Andsystem specificationthe cohesion principle proposed in the ". However, these two principles are not initially applied to object-oriented design, but rather support procedural programming (Procedural Programming) concept. In procedural programming, the principle of single responsibility is dependent on function and process implementation.

with object-oriented programming ( OOP language, people begin to use classes to separate concerns. Thus by Robert · C • Martin ( Robertc.martin ) summarizes the principle of single responsibility.

"Inventor profile"

Robert · C • Martin ( Robertc.martin ) Industry Person Bob uncle, world-class software development master, famous software company Object Mentor founder and president of the company. has served as editor of C + + report for many years and is also one of the main advocates of the design model and agile development Movement.

This article is from the "warm know new @ share" blog, please be sure to keep this source http://dehybris.blog.51cto.com/10617992/1685138

(1) Single Responsibility Principle "sole responsibility Principle"