The SRP principle in OOD/DDP

Single principle of responsibility

SRP (the single Responsibility Principle): A class should have only one reason for the change. The change here refers to the change of duty.

The SRP is well understood, and its requirement is to have a class do only one type of responsibility, and this class needs to be decomposed when the class takes on other types of responsibility . It sounds simple, that is, a class means doing a thing. Here is not one thing.

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 inhibit the ability of other duties of this kind. This coupling leads to a fragile design that, when changed, is subjected to unexpected damage.

For example: the employees in the production line are in the job, each of them is very clear, only responsible for a certain link, only be arranged to do one thing. It feels like the SRP.

How to define Responsibilities

In SPR, we define responsibility as the cause of change. If we can think of a motive to change a class, then this class has a responsibility for one. Usually, however, we are more accustomed to thinking about responsibilities in a group form.

If the relational Database processing interface is shown below:

 Public Interfaceirdbmsstorage{idbconnection Connection (stringconnectionString); Ienumrable<T> query<t> (stringSQLQuery,Objectparam); T FirstOrDefault<T> (stringSQLQuery,Objectparam); intCount (stringSQLQuery,Objectparam); voidExecute (stringSqlCommand,Objectparam); voidExecuteScalar (stringSqlCommand,Objectparam);}

In this interface we see three responsibilities for database connections, data queries, and data processing.

Do we need to separate these three responsibilities? This depends on how the application changes. If the application changes affect the signature of the connection function (either the connection string or the name of the connection string in config), the design may be unreasonable. It is also possible that some areas of the code require only open query functionality.

On the other hand, if the application changes in a way that will always cause these three responsibilities to change simultaneously, then there is no need to separate them. In fact, separating them can lead to unnecessary complexity.

Separation of coupling responsibilities

How do you separate the responsibilities of coupling? We can decouple them by separating their interfaces. The multifunctional large interface is decomposed into multiple single-function small interfaces.

 Public Interfaceirdbmsstoragequery{ienumrable<T> query<t> (stringSQLQuery,Objectparam); T FirstOrDefault<T> (stringSQLQuery,Objectparam); intCount (stringSQLQuery,Objectparam);} Public Interfaceirdbmsstoragecommand{voidExecute (stringSqlCommand,Objectparam); voidExecuteScalar (stringSqlCommand,Objectparam);} Public Interfaceirdbmsstorage:irdbmsstoragequery, irdbmsstoragecommand{idbconnection Connection (stringconnectionString);}

In the above code we break into the irdbmsstoragequery query interface and the irdbmsstoragecommand command Interface (a bit of CQS flavor), and then irdbmsstorage interface is combined together. In some places we may only need to query the function, some places may use the execution function, but some places may need both.

Summarize

The SPR principle can be said to be one of the simplest principles in object-oriented principle, but it is one of the most difficult principles to grasp. A lot of the real work of software design is to discover responsibilities and separate those responsibilities from each other. When these responsibilities should be divided into responsibilities, the granularity of the division of how much, we need to understand.

The SRP principle in OOD/DDP