PHP代码简洁之道——SOLID原则

简介:

PHP代码简洁之道——SOLID原则

SOLID 是Michael Feathers推荐的便于记忆的首字母简写,它代表了Robert Martin命名的最重要的五个面对对象编码设计原则:

  • S: 单一职责原则 (SRP)
  • O: 开闭原则 (OCP)
  • L: 里氏替换原则 (LSP)
  • I: 接口隔离原则 (ISP)
  • D: 依赖反转原则 (DIP)

单一职责原则 Single Responsibility Principle (SRP)

"修改一个类应该只为一个理由"。人们总是易于用一堆方法塞满一个类,如同我们在飞机上只能携带一个行李箱(把所有的东西都塞到箱子里)。这样做的问题是:从概念上这样的类不是高内聚的,并且留下了很多理由去修改它。将你需要修改类的次数降低到最小很重要。这是因为,当有很多方法在类中时,修改其中一处,你很难知晓在代码库中哪些依赖的模块会被影响到。

Bad:


  
  
  1. class UserSettings{     
  2.     private $user;     
  3.     public function __construct($user
  4.     {         
  5.         $this->user = $user
  6.     }     
  7.     public function changeSettings($settings) 
  8.     {         
  9.         if ($this->verifyCredentials()) {            
  10.          // ... 
  11.         } 
  12.     }     
  13.     private function verifyCredentials() 
  14.     {         
  15.     // ... 
  16.     } 
  17.  

Good:


  
  
  1. class UserAuth {     
  2. private $user;     
  3. public function __construct($user){         
  4.     $this->user = $user
  5. }     
  6. public function verifyCredentials(){         
  7.     // ... 
  8.  
  9. class UserSettings {     
  10. private $user;     
  11. private $auth;     
  12. public function __construct($user) {         
  13.   $this->user = $user;         
  14.   $this->auth = new UserAuth($user); 
  15. }     
  16. public function changeSettings($settings){         
  17.     if ($this->auth->verifyCredentials()) {             
  18.     // ... 
  19.         } 
  20.     } 
  21.  

开闭原则 Open/Closed Principle (OCP)

正如Bertrand Meyer所述,"软件的实体(类, 模块, 函数,等)应该对扩展开放,对修改关闭。"这个原则是在说明应该允许用户在不改变已有代码的情况下增加新的功能。

Bad:


  
  
  1. abstract class Adapter{     
  2. protected $name;     
  3. public function getName(){         
  4.     return $this->name
  5. class AjaxAdapter extends Adapter{     
  6. public function __construct(){      
  7.       parent::__construct();         
  8.       $this->name = 'ajaxAdapter'
  9.  } 
  10. class NodeAdapter extends Adapter{     
  11.     public function __construct(){    
  12.         parent::__construct();         
  13.         $this->name = 'nodeAdapter'
  14.     } 
  15.     class HttpRequester{     
  16.     private $adapter;     
  17.     public function __construct($adapter) 
  18.     {         
  19.         $this->adapter = $adapter; 
  20.     }     
  21.     public function fetch($url) 
  22.     { 
  23.         $adapterName = $this->adapter->getName();         
  24.     if ($adapterName === 'ajaxAdapter') {             
  25.         return $this->makeAjaxCall($url); 
  26.         }  
  27.     elseif ($adapterName === 'httpNodeAdapter') {             
  28.         return $this->makeHttpCall($url); 
  29.         } 
  30.     }     
  31.     private function makeAjaxCall($url) 
  32.     {        // request and return promise 
  33.     }     
  34.     private function makeHttpCall($url) 
  35.     {        // request and return promise 
  36.     } 
  37.  

在上面的代码中,对于HttpRequester类中的fetch方法,如果我新增了一个新的xxxAdapter类并且要在fetch方法中用到的话,就需要在HttpRequester类中去修改类(如加上一个elseif 判断),而通过下面的代码,就可很好的解决这个问题。下面代码很好的说明了如何在不改变原有代码的情况下增加新功能。

Good:


  
  
  1. interface Adapter{     
  2.     public function request($url); 
  3.     class AjaxAdapter implements Adapter{     
  4.     public function request($url) 
  5.     {        // request and return promise 
  6.     } 
  7. class NodeAdapter implements Adapter{     
  8.     public function request($url) 
  9.     {        // request and return promise 
  10.     } 
  11.     class HttpRequester{     
  12.     private $adapter;     
  13.     public function __construct(Adapter $adapter) 
  14.     {        $this->adapter = $adapter; 
  15.     }     
  16.     public function fetch($url) 
  17.     {        return $this->adapter->request($url); 
  18.     } 
  19.  

里氏替换原则 Liskov Substitution Principle (LSP)

对这个概念最好的解释是:如果你有一个父类和一个子类,在不改变原有结果正确性的前提下父类和子类可以互换。这个听起来让人有些迷惑,所以让我们来看一个经典的正方形-长方形的例子。从数学上讲,正方形是一种长方形,但是当你的模型通过继承使用了"is-a"的关系时,就不对了。

Bad:


  
  
  1. class Rectangle{     
  2.     protected $width = 0;     
  3.     protected $height = 0;     
  4.     public function render($area) 
  5.     {        // ... 
  6.     }     
  7.     public function setWidth($width) 
  8.     {        $this->width = $width; 
  9.     }     
  10.     public function setHeight($height) 
  11.     {        $this->height = $height; 
  12.     }     
  13.     public function getArea() 
  14.     {        return $this->width * $this->height; 
  15.     } 
  16. class Square extends Rectangle{     
  17.     public function setWidth($width) 
  18.     {         
  19.         $this->width = $this->height = $width; 
  20.     }     
  21.     public function setHeight(height) 
  22.     {        $this->width = $this->height = $height; 
  23.     } 
  24. function renderLargeRectangles($rectangles){     
  25.     foreach ($rectangles as $rectangle) { 
  26.         $rectangle->setWidth(4); 
  27.         $rectangle->setHeight(5); 
  28.         $area = $rectangle->getArea(); // BAD: Will return 25 for Square. Should be 20. 
  29.         $rectangle->render($area); 
  30.     } 
  31.  
  32. $rectangles =  
  33. [new Rectangle(), new Rectangle(), new Square()]; 
  34. renderLargeRectangles($rectangles);  

Good:


  
  
  1. abstract class Shape{     
  2.     protected $width = 0;     
  3.     protected $height = 0;     
  4.     abstract public function getArea();     
  5.     public function render($area)    {        // ... 
  6.     } 
  7. class Rectangle extends Shape{     
  8.     public function setWidth($width) 
  9.     {        $this->width = $width; 
  10.     }     
  11.     public function setHeight($height) 
  12.     {        $this->height = $height; 
  13.     }     
  14.     public function getArea() 
  15.     {        return $this->width * $this->height; 
  16.     } 
  17. class Square extends Shape{     
  18.     private $length = 0;     
  19.     public function setLength($length) 
  20.     {        $this->length = $length; 
  21.     }     
  22.     public function getArea() 
  23.     {        return pow($this->length, 2); 
  24.     } 
  25. function renderLargeRectangles($rectangles){     
  26. foreach ($rectangles as $rectangle) {         
  27. if ($rectangle instanceof Square) { 
  28.             $rectangle->setLength(5); 
  29.         } elseif ($rectangle instanceof Rectangle) { 
  30.             $rectangle->setWidth(4); 
  31.             $rectangle->setHeight(5); 
  32.         } 
  33.  
  34.         $area = $rectangle->getArea();  
  35.         $rectangle->render($area); 
  36.     } 
  37.  
  38. $shapes = [new Rectangle(), new Rectangle(), new Square()]; 
  39. renderLargeRectangles($shapes);  

接口隔离原则

接口隔离原则:"客户端不应该被强制去实现于它不需要的接口"。

有一个清晰的例子来说明示范这条原则。当一个类需要一个大量的设置项,为了方便不会要求客户端去设置大量的选项,因为在通常他们不需要所有的设置项。使设置项可选有助于我们避免产生"胖接口"

Bad:


  
  
  1. interface Employee{     
  2.     public function work();     
  3.     public function eat(); 
  4. class Human implements Employee{     
  5.     public function work() 
  6.     {        // ....working 
  7.     }     
  8.     public function eat() 
  9.     {        // ...... eating in lunch break 
  10.     } 
  11. }class Robot implements Employee{     
  12.     public function work() 
  13.     {        //.... working much more 
  14.     }     
  15.     public function eat() 
  16.     {        //.... robot can't eat, but it must implement this method 
  17.     } 
  18.  

上面的代码中,Robot类并不需要eat()这个方法,但是实现了Emplyee接口,于是只能实现所有的方法了,这使得Robot实现了它并不需要的方法。所以在这里应该对Emplyee接口进行拆分,正确的代码如下:

Good:


  
  
  1. interface Workable{     
  2.     public function work(); 
  3. interface Feedable{     
  4.     public function eat(); 
  5. interface Employee extends Feedable, Workable{ 
  6. class Human implements Employee{     
  7.     public function work() 
  8.     {        // ....working 
  9.     }     
  10.     public function eat() 
  11.     {        //.... eating in lunch break 
  12.     } 
  13. }// robot can only work 
  14.  
  15. class Robot implements Workable{     
  16.     public function work() 
  17.     {        // ....working 
  18.     } 
  19.  

依赖反转原则 Dependency Inversion Principle (DIP)

这条原则说明两个基本的要点:

  • 高阶的模块不应该依赖低阶的模块,它们都应该依赖于抽象
  • 抽象不应该依赖于实现,实现应该依赖于抽象

这条起初看起来有点晦涩难懂,但是如果你使用过php框架(例如 Symfony),你应该见过依赖注入(DI)对这个概念的实现。虽然它们不是完全相通的概念,依赖倒置原则使高阶模块与低阶模块的实现细节和创建分离。可以使用依赖注入(DI)这种方式来实现它。更多的好处是它使模块之间解耦。耦合会导致你难于重构,它是一种非常糟糕的的开发模式。

Bad:


  
  
  1. class Employee{     
  2.     public function work() 
  3.     {        // ....working 
  4.     } 
  5. class Robot extends Employee{     
  6.     public function work()    {        //.... working much more 
  7.     } 
  8. class Manager{     
  9.     private $employee;    
  10.     public function __construct(Employee $employee) 
  11.     {        $this->employee = $employee; 
  12.     }    public function manage() 
  13.     {        $this->employee->work(); 
  14.     } 
  15.  

Good:


  
  
  1. interface Employee{    
  2.  public function work(); 
  3.  class Human implements Employee{    
  4. public function work() 
  5.     {        // ....working 
  6.     } 
  7. class Robot implements Employee{     
  8. public function work() 
  9.     {        //.... working much more 
  10.     } 
  11. class Manager{     
  12. private $employee;     
  13. public function __construct(Employee $employee) 
  14.     {        $this->employee = $employee; 
  15.     }    public function manage() 
  16.     {        $this->employee->work(); 
  17.     } 
  18.  

别写重复代码 (DRY)

这条原则大家应该都是比较熟悉了。

尽你最大的努力去避免复制代码,它是一种非常糟糕的行为,复制代码通常意味着当你需要变更一些逻辑时,你需要修改不止一处。

Bad:


  
  
  1. function showDeveloperList($developers){     
  2. foreach ($developers as $developer) { 
  3.         $expectedSalary =  
  4. $developer->calculateExpectedSalary(); 
  5.         $experience = $developer->getExperience(); 
  6.         $githubLink = $developer->getGithubLink(); 
  7.         $data = [ 
  8.             $expectedSalary, 
  9.             $experience, 
  10.             $githubLink 
  11.         ]; 
  12.  
  13.         render($data); 
  14.     } 
  15. function showManagerList($managers){     
  16. foreach ($managers as $manager) { 
  17.         $expectedSalary =  
  18. $manager->calculateExpectedSalary(); 
  19.         $experience = $manager->getExperience(); 
  20.         $githubLink = $manager->getGithubLink(); 
  21.         $data = [ 
  22.             $expectedSalary, 
  23.             $experience, 
  24.             $githubLink 
  25.         ]; 
  26.  
  27.         render($data); 
  28.     } 
  29.  

Good:


  
  
  1. function showList($employees){     
  2. foreach ($employees as $employee) { 
  3.         $expectedSalary =  
  4. $employee->calculateExpectedSalary(); 
  5.         $experience = $employee->getExperience(); 
  6.         $githubLink = $employee->getGithubLink(); 
  7.         $data = [ 
  8.             $expectedSalary, 
  9.             $experience, 
  10.             $githubLink 
  11.         ]; 
  12.  
  13.         render($data); 
  14.     } 
  15.  

Very good:


  
  
  1. function showList($employees){    foreach ($employees as $employee) { 
  2.         render([ 
  3.             $employee->calculateExpectedSalary(), 
  4.             $employee->getExperience(), 
  5.             $employee->getGithubLink() 
  6.         ]); 
  7.     } 
  8.  

后记:虽然OOP设计需要遵守如上原则,不过实际的代码设计一定要简单、简单、简单。在实际编码中要根据情况进行取舍,一味遵守原则,而不注重实际情况的话,可能会让你的代码变的难以理解! 


原文发布时间为:2017-10-24

本文作者:佚名

本文来自云栖社区合作伙伴“51CTO”,了解相关信息可以关注。

相关文章
|
1月前
|
IDE PHP 开发工具
PHP中的类型提示与严格模式:提高代码可维护性
随着PHP语言的发展,开发者对代码的可读性、可维护性和可靠性有了更高的要求。PHP中的类型提示(Type Hinting)和严格模式(Strict Mode)为开发者提供了更强的类型检查机制,有助于提升代码质量和减少潜在的错误,尤其是在大型项目中。
|
2月前
|
安全 程序员 PHP
PHP中的异常处理:提升代码的健壮性
【10月更文挑战第8天】在编程的世界中,错误和异常是不可避免的。它们就像路上的坑洼,可能会让我们的程序“跌倒”。但是,如果我们能够正确地处理这些异常,就可以让我们的程序更加稳健,就像我们学会了如何在坑洼的路上稳稳地行走一样。本文将介绍PHP中的异常处理机制,以及如何使用它来提升我们的代码质量。
|
3月前
|
设计模式 数据库连接 PHP
PHP中的设计模式:提升代码的可维护性与扩展性在软件开发过程中,设计模式是开发者们经常用到的工具之一。它们提供了经过验证的解决方案,可以帮助我们解决常见的软件设计问题。本文将介绍PHP中常用的设计模式,以及如何利用这些模式来提高代码的可维护性和扩展性。我们将从基础的设计模式入手,逐步深入到更复杂的应用场景。通过实际案例分析,读者可以更好地理解如何在PHP开发中应用这些设计模式,从而写出更加高效、灵活和易于维护的代码。
本文探讨了PHP中常用的设计模式及其在实际项目中的应用。内容涵盖设计模式的基本概念、分类和具体使用场景,重点介绍了单例模式、工厂模式和观察者模式等常见模式。通过具体的代码示例,展示了如何在PHP项目中有效利用设计模式来提升代码的可维护性和扩展性。文章还讨论了设计模式的选择原则和注意事项,帮助开发者在不同情境下做出最佳决策。
|
21天前
|
PHP 开发者
PHP中的异常处理:提升代码的健壮性
【10月更文挑战第40天】在PHP编程中,异常处理是确保应用稳定性的关键。本文将引导你理解异常处理的重要性,掌握如何在PHP中捕获和处理异常,以及如何通过自定义异常类来增强代码的错误管理能力。我们将一起探索如何利用PHP的异常处理机制,打造一个更加健壮和可靠的应用程序。
|
2月前
|
设计模式 算法 数据库连接
PHP中的设计模式:提高代码的可维护性和扩展性
【10月更文挑战第13天】 本文将探讨PHP中常见的设计模式及其在实际项目中的应用。通过对比传统编程方式,我们将展示设计模式如何有效地提高代码的可维护性和扩展性。无论是单例模式确保类的单一实例,还是观察者模式实现对象间的松耦合,每一种设计模式都为开发者提供了解决特定问题的最佳实践。阅读本文后,读者将能更好地理解和应用这些设计模式,从而提升PHP编程的效率和质量。
|
2月前
|
设计模式 SQL 安全
PHP中的设计模式:单例模式的深入探索与实践在PHP开发领域,设计模式是解决常见问题的高效方案集合。它们不是具体的代码,而是一种编码和设计经验的总结。单例模式作为设计模式中的一种,确保了一个类仅有一个实例,并提供一个全局访问点。本文将深入探讨单例模式的基本概念、实现方式及其在PHP中的应用。
单例模式在PHP中的应用广泛,尤其在处理数据库连接、日志记录等场景时,能显著提高资源利用率和执行效率。本文从单例模式的定义出发,详细解释了其在PHP中的不同实现方法,并探讨了使用单例模式的优势与注意事项。通过对示例代码的分析,读者将能够理解如何在PHP项目中有效应用单例模式。
|
2月前
|
程序员 数据库连接 PHP
PHP中的异常处理:提升代码的健壮性
【9月更文挑战第30天】在编程的世界里,错误和异常是不可避免的。本文将深入探索PHP中异常处理的机制,揭示如何通过有效的异常管理来增强代码的健壮性和可靠性。我们将从基础概念出发,逐步深入到高级应用,最后通过实际代码示例来巩固理论知识。无论你是初学者还是有经验的开发者,这篇文章都将为你提供宝贵的指导和启示。
49 6
|
3月前
|
设计模式 算法 PHP
PHP中的设计模式:提升代码的灵活性与可维护性
在本文中,我们将深入探讨PHP编程语言中的一种重要概念——设计模式。设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它代表了最佳的实践,被有经验的面向对象的软件开发人员所采用。本文将通过具体的实例,展示如何在PHP项目中应用设计模式,以提高代码的灵活性和可维护性。无论你是PHP初学者还是经验丰富的开发者,都能从中获得有价值的见解。
|
3月前
|
设计模式 存储 数据库连接
探索PHP中的设计模式:提高代码的可维护性与扩展性
本文将深入探讨PHP中常用的设计模式,包括单例模式、工厂模式和观察者模式。通过具体的代码示例,展示如何在实际项目中应用这些设计模式,以提高代码的可维护性与扩展性。无论你是PHP初学者还是有一定经验的开发者,都可以通过本文的学习,提升你的编程技巧和项目架构能力。
|
2月前
|
PHP 开发者 UED
PHP中的异常处理:提升代码的健壮性
【10月更文挑战第8天】在编程世界中,错误和异常是不可避免的。它们如同路上的绊脚石,让我们的程序跌倒。但如果我们学会了如何处理这些异常,就能像学会走路的孩子一样,即使跌倒也能爬起来继续前进。本文将引导你如何在PHP中捕获并处理异常,让你的代码更加健壮,能够优雅地面对各种挑战。