Design pattern six principles (i): Single Responsibility Principle (SRP)

Definition:

Single Responsibility Principle: For a class, there should be only one cause for it to change.

  Reason:    If a class takes on too much responsibility, it is tantamount to coupling these responsibilities, and a change in responsibility may weaken or inhibit the ability of the class to perform other duties. This coupling leads to fragile designs that can be subjected to unexpected damage when the changes occur. 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.
Example:    If we do not abide by the principle of single responsibility, what will happen? Can we accept the consequences?
    When we go to the mobile phone store, we can often find that there is a place in a corner to repair the phone, from which we can see that the store has two responsibilities (or function). One responsibility is to sell mobile phones, and one responsibility is to repair them. Then we make a hypothesis: the store sells A, B, c three brands of mobile phones, but also can repair a, B, c three brands of mobile phones. Use a class to represent the process:

#include <iostream>#include<string>#include<Set>using namespacestd;classphonestore{Set<string>Phonebrand; Public:    voidAddphonebrand (stringphonename); voidSalephonebrand (); voidRepairphonebrand ();};voidPhonestore::addphonebrand (stringphonename) {Phonebrand.insert (phonename);}voidPhonestore::salephonebrand () {Set<string>::iterator Set_it =Phonebrand.cbegin ();  while(Set_it! =Phonebrand.cend ()) {cout<<"our store has"<< *set_it <<"branded mobile phones for sale"<<Endl; Set_it++; }}voidPhonestore::repairphonebrand () {Set<string>::iterator Set_it =Phonebrand.cbegin ();  while(Set_it! =Phonebrand.cend ()) {cout<<"we can repair the store ."<< *set_it <<"Brand Mobile phone"<<Endl; Set_it++; }}intMain () {Phonestore xmx; //Create XMX mobile phone store//Add mobile phone stores for sale and repair of mobile phone brandsXmx. Addphonebrand ("A"); Xmx. Addphonebrand ("B"); Xmx. Addphonebrand ("C"); //Mobile phone brands sold on mobile phonesXmx.        Salephonebrand (); //Mobile phone stores can repair the brandXmx.    Repairphonebrand (); return 0;}

Output:

We have a brand of mobile phones sold in our store has a B brand of mobile phones sold in our store has a C brand mobile phone sales we can repair a brand mobile phone we can repair the B brand mobile phone We can repair the C brand mobile phone

OK, now we also have a mobile phone store category, and not only can sell A, B, c three brands of mobile phones, but also repair a, B, c three brands of mobile phones. Well, if one day, buy a new D-branded phone, but the repair department has not learned how to repair the D-brand phone, then if we add a D-branded phone, the output is as follows:

We have a brand of mobile phones sold in our store has a B brand of mobile phones sold in our store has a C brand mobile phone sale of our store has a D brand of mobile phones for sale We can repair a brand mobile phone we can repair the B brand mobile phone We can repair the C brand mobile phone we can repair the D brand mobile phone

But we're not going to fix the D-branded phone. Oops, that's the consequence of not following a single responsibility principle, I was just trying to change my job of selling my phone, and I didn't think the job of repairing the phone had changed. So say (put an afterthought), should follow the principle of single duty, or else will not appear this kind of pit problem, how to do? Change it! The modified class code is as follows:

#include <iostream>#include<string>#include<Set>using namespacestd;classphonestoresale{Set<string>Phonebrand; Public:    voidAddphonebrand (stringphonename); voidSalephonebrand ();};voidPhonestoresale::addphonebrand (stringphonename) {Phonebrand.insert (phonename);}voidPhonestoresale::salephonebrand () {Set<string>::iterator Set_it =Phonebrand.cbegin ();  while(Set_it! =Phonebrand.cend ()) {cout<<"our store has"<< *set_it <<"branded mobile phones for sale"<<Endl; Set_it++; }}classphonestorerepair{Set<string>Phonebrand; Public:    voidAddphonebrand (stringphonename); voidRepairphonebrand ();};voidPhonestorerepair::addphonebrand (stringphonename) {Phonebrand.insert (phonename);}voidPhonestorerepair::repairphonebrand () {Set<string>::iterator Set_it =Phonebrand.cbegin ();  while(Set_it! =Phonebrand.cend ()) {cout<<"we can repair the store ."<< *set_it <<"Brand Mobile phone"<<Endl; Set_it++; }}intMain () {//sale of mobile phone DepartmentPhonestoresale Sale; //add a brand to sell your phoneSale. Addphonebrand ("A"); Sale. Addphonebrand ("B"); Sale. Addphonebrand ("C"); Sale. Addphonebrand ("D"); //Mobile phone brands for SaleSale.    Salephonebrand (); //The department that repairs the cell phonePhonestorerepair Repair; //Add a brand that can repair your phoneRepair. Addphonebrand ("A"); Repair. Addphonebrand ("B"); Repair. Addphonebrand ("C"); //Mobile Phone Repair Department can repair the brand of mobile phonerepair.    Repairphonebrand (); return 0;}

Output:

We have a brand of mobile phones sold in our store has a B brand of mobile phones for sale We have a C brand mobile phone sale of our store has a D brand of mobile phones for sale We can repair a brand mobile phone we can repair the B brand mobile phone We can repair the C brand mobile phone

    Hey, did you see that? This is what we want to do, so say, or to follow a single principle of responsibility, a class, there should be only one reason for it to change, like the Phonestoresale class above, can cause it to change that only sale responsibility changes, this class changed. Do not allow a class to be multi-professional, which creates a great degree of coupling. Advantages:    1. Improve the readability of the class, easy to maintain;
    2. The complexity of classes is reduced, and a class is responsible for only one responsibility;    3. The risk of change is reduced, the change is essential, but it is a class is a responsibility, modifying a class is equivalent to modifying a class, and does not affect other classes. Reference books: "Big Talk design mode", "Agile development-Agile software Development"

Design pattern six principles (i): Single Responsibility Principle (SRP)