There are six principles of design patterns

Single Responsibility Principle (SRP)

Definition: “A class should have only one reason why it changes”

Suppose you have a class N that is responsible for two responsibilities, Z1 and Z2. If responsibility Z1 changes, class N needs to be modified, and changing class N may cause Z2 to not work properly

The more responsibilities a class has in a system, the less likely it is to be reused. The more responsibilities you have, the easier it is to couple them together, and if one responsibility changes, it may affect the normal operation of others. Therefore, different responsibilities can be separated and encapsulated into different classes

The single responsibility principle can be said to be a guideline for achieving “high cohesion, low coupling”. show me code

<? php
class BaiLi
{
    public functionThe flash () / / flash {  echo "Flash!.PHP_EOL;  }   public functionPushVision () / / eyes {  echo "I poked my eye in.".PHP_EOL;  }   public functionThe sniper () / / sniper {  echo "I took a shot.".PHP_EOL;  }   public functionBackToCity () / / back {  echo "Out of shape, back to town.".PHP_EOL;  } } Copy the code

Wrote a hundred miles of class, class design seems to be no problem, class is the hero’s various skills and operations. The single responsibility principle requires that a class change for only one reason, that it should only be responsible for one thing. In this case, it does two things, or three things: flash and return are “public skills”, and piercing and sniping are “unique skills” of the hero. If the hero needs to be retooled and needs to change the specific abilities of the hundred miles, the public abilities may be affected. “Public skills should not actually be affected by any hero changes,” so these two responsibilities should be split into two classes and packaged separately

Maybe it’s not a good example, but it’s something like this. Suppose there is a Login class (Login), which has the function of processing form data (dealForm), form data checkForm (checkForm), Login (Login), get user information (getUserInfo) and so on

In fact, this class does not follow the single responsibility principle, using the single responsibility principle to reconstruct, should be processed Form data (dealForm), Form data checkForm (Form) encapsulated in a Form processing class (Form), getUserInfo (User) in a User class

Open and Closed Principle (OCP)

Definition: “Objects (classes, modules, functions, etc.) in software should be open to extension, but closed to modification”

By being open to extension, we mean that we can add any new functionality we want without making any changes to the existing functionality. That is, objects in software should be extended as far as possible without modifying the original code

We actually spend most of our time at work maintaining code, either because requirements change or because of upgrades. If we make changes to the old code, we may have an impact on the old code. Over time, we had to refactor the system and retest the original code. So if there is a requirement change or a system upgrade, we implement the new requirement by extension without affecting the historical logic and code

So when we design code, we should think about, “How can we be open to extension and closed to change?”

The usual approach is to abstract an interface or abstract class and define common methods for easy extension. Or we can inherit an interface or abstract class for extension purposes. Anyway, the core is abstraction.

Abstract design is necessary to satisfy the open and close principle. Abstraction is the key of the open and close principle. In the programming language of face object such as Java and C++, it is usually “to define a relatively stable abstraction layer for the system, and move the different implementation behavior to the concrete implementation layer”. When changing the behavior of the system, there is no need to change the abstraction layer, just add new concrete classes to implement new business functions. In order to achieve without modifying the existing code on the basis of the expansion of the system function, to achieve the open and closed principle requirements

Suppose I follow the following logic to implement king of Glory’s archer hero

<? php
class Shooter
{
    public function firstSkill($hero)
 {  if ($hero= ='baiLi') {  $obj = new Baili();  $obj->firstSkill();  } elseif ($hero= ='mengYa') {  $obj = new Mengya();  $obj->firstSkill();  }  }   public function SecondSkill($hero)  {  if ($hero= ='baiLi') {  $obj = new Baili();  $obj->SecondSkill();  } elseif ($hero= ='mengYa') {  $obj = new Mengya();  $obj->SecondSkill();  }  }   public function ThirdSkill($hero)  { . } }  class Baili {  public function firstSkill(a) {  echo "One skill in a hundred miles.";  }   public function SecondSkill($hero)  {  echo "Two skills of a hundred miles.";  }   public function ThirdSkill($hero)  {  echo "Three skills for a hundred miles.";  } }  class Mengya {  public function firstSkill(a) {  echo "Yasuo's skill";  }   public function SecondSkill($hero)  {  echo "Yasuo's Second skill";  }   public function ThirdSkill($hero)  {  echo "Tier three skills of Montchallenger";  } } Copy the code

In this way, if I add a hero now, I need to modify the three methods of the Shooter class and add new judgment logic, which violates the open and closed principle (because I need to modify the original code).

Now abstract out the archer class

<? php
abstract class Shooter
{
    abstract function firstSkill();
  abstract function SecondSkill();   abstract function ThirdSkill(); }  class OperateShooter {  private $shooter;  public function setShooter(Shooter $shooter)  {  $this->shooter = $shooter;  }   public function firstSkill(a) {  $this->shooter->firstSkill();  } }  class Baili extends Shooter {  public function firstSkill(a) {  echo "One skill in a hundred miles.";  }   public function SecondSkill(a) {  echo "Two skills of a hundred miles.";  }   public function ThirdSkill(a) {  echo "Three skills for a hundred miles.";  } }  class Mengya extends Shooter {  public function firstSkill(a) {  echo "Yasuo's skill";  }   public function SecondSkill(a) {  echo "Yasuo's Second skill";  }   public function ThirdSkill(a) {  echo "Tier three skills of Montchallenger";  } } $obj = new OperateShooter(); $obj->setShooter(new Baili()); $obj->firstSkill();  Output:A skill of a hundred milesCopy the code

After refactoring, it encapsulates an abstract class (Shooter), and OperateShooter operates on this abstract class. SetShooter () allows the user to set and instantiate a specific Shooter hero object. OperateShooter’s firstSkill() method is used to call the passed object’s firstSkill() method. If a new Shooter hero is added, add the Shooter hero to the OperateShooter class, and then directly inject the new hero’s object into the OperateShooter class