面向对象设计原则：不要STUPID，坚持GRASP和SOLID

不要STUPID，坚持GRASP和SOLID

听过SOLID编码吗？有人可能会说：这是描述设计原则的一个专业术语，由我们可爱的代码整洁之道传教者鲍勃（罗伯特C. 马丁）大叔提出，是一组用于指导我们如何写出“好代码”的原则。

在编程界充满了这样由单词首字母组成的缩略词。其它类似的例子还有DRY（Don’t Repeat Yourself! 不要重复你自己！）和KISS（Keep It Simple, Stupid! 让事情简单化，傻瓜化）。但是，这些条条框框好像有点多，太多，超级多……

所以，可不可以换个角度来解决这些问题呢？看看是什么原因导致我们写出“坏代码”。

抱歉，你的代码就是那么的STUPID

没有人喜欢听到别人评价他的代码很愚蠢。而且这样做也很容易冒犯别人。所以不要说出来。但平心而论：全世界中大部分代码都是不可维护的，因为它们都是乱糟糟一团的。

那些烂代码又有什么特点呢？是什么把代码变得如此STUPID？

• Singleton - 单态
• Tightcoupling - 紧密耦合
• Untestability - 不可测试
• Premature Optimization - 过早优化
• Indescriptive Naming - 胡乱命名
• Duplication - 重复代码

你同意上面的列表吗？是？好极。不？OK，我会在下面的内容中逐一解释每项观点，这样你就可以更好地明白为什么我会选用这些模式。

单态

<?php
class DB {
    private static $instance;
 
    public static function getInstance() {
        if (!isset(self::$instance)) {
            self::$instance = new self;
        }
 
        return self::$instance;
    }
 
    final private function __construct() { /* something */ }
    final private function __clone() { }
 
    /* actual methods here */
}

上面的代码是一段典型的数据库访问实现，你可以从很多PHP教程中找到这样的代码。实际上，不久之前我也在使用与此风格类似的代码。

你可能会感到奇怪：这段代码怎么了？不论在哪，利用DB::getInstance()都可以很容易地访问DB啊，并且它还保证一次只有一个数据库连接。到底坏哪儿了？

嗯，很好，我之前也是这样想滴^^。“我只需要一个连接”。当应用程序规模变得稍微大一些的时候，实事会证明我还需要另一个数据库的连接。这就是混乱的开始。我把单态稍加修改，增加了一个->getSecondInstance()方法，这样，单态就变成了——“双单态”了。其实我本就应该意识到数据库连接不是一个简单的单态结构，压根就不该用它来作为实现方案。同样的单态用法你还可以找到很多。请求对象的确是单态！但听过子请求吗？日志就是！难道你不需要换个方式记录点别的什么？

上面描述的只是问题之一。还有一个重大的问题就是在代码中使用DB::getInstance()会把代码与类名DB强行绑定。也就是说，你无法对类DB进行扩展。假设我需要把查询性能数据以日志的形式写到APC（Alternative PHP Cache）中。但由于类名紧密耦合，根本无法实现这项功能。如果当初程序是采用依赖注入的方式实现的，我可以很轻松地对类型DB进行扩展，然后传入新的实例对象。但单态已经不允许我这样做了。现在我能做的就是用下面这种粗制的手段实现我的想法：

<?php
// original DB class
class _DB { /* ... */ }
 
// extending class
class DB extends _DB { /* ... */ }

一个字儿：丑。或许还有人会加入一些别的形容词，骇客、不可维护、大米共，或STUPID。

最后还有一点要考虑：还记得我之前说过的那句，“不论在哪，利用DB::getInstance()都可以很容易地访问DB”。不得不承认，其实这也是件糟糕的事情。一看到“无论在哪”，我们自然可以联想到“全局”，也可以理解为“单态就是一个具有特别命名的全局变量”。在你学习PHP的时候，你可能早就被告知使用关键字global是一个很坏的习惯。但殊不知使用单态和使用全局变量的影响是一样的：它们都创建了全局状态对象。这种方法创建的是非显式依赖，结果就是会让程序变得难以重用与测试。

紧密耦合

通过上面对单态问题的认识，你可能已经学会举一反三，把问题推向使用更为广泛的static方法和属性。不管在什么时候，只要编写Foo::bar()这样的代码，就是把代码和Foo类耦合在一起。这种耦合使得对Foo类的功能扩展几乎变得不可能，进而导致代码很难被重用和测试。

类似的情况还有包括普通类名的使用，它们也同样会带来代码臭味。其中包括new操作符的使用：

<?php
class House {
    public function __construct() {
        $this->door   = new Door;
        $this->window = new Window;
    }
}

在上面的代码，你怎么替换房子中的门和窗呢？答案很简单：不可以。作为一个技法娴熟的开发者，你可能一眼就会看出怎么用些下流的骇客手法来替换门或窗。但是，或许下面的方式更为简单一些：

<?php
class House {
    public function __construct(Door $door, Window $window) { // Door, Window are interfaces
        $this->door   = $door;
        $this->window = $window;
    }
}

采用这种方法可以很方便地把不同的门和窗加到房子里。另外，这份代码同时还具有良好的扩展性、重用性和可测试性。你还有什么可以奢求的吗？

上面的代码概括起来说就是使用了“依赖注入（DI=DependencyInjection）”。而一讲到DI，许多人就会把它和Symfony（一款PHP开发框架）这样的DIC（Dependency Injection Container=依赖注入容器）联系起来，而实际上DI的概念是非常简单的。

不可测试

单元测试很重用。如果你没有对你的代码进行过测试，你也就登上驶往破坏代码的战船。但即使是这样，还是有很多人没有很好地完成他们的测试。为什么？大多数原因可以归结于难以测试的代码。那又是什么原因使得代码难以测试呢？主要是列表中前一点内容：紧密耦合。单元测试——看似清晰明了——就是测试一个代码单元（通常是各种类）。但如果类与类之间紧密结合，又怎么可能针对每一个类进行测试呢？这时你可能会使用更多的骇客技术。但是，通常情况下大多数人都不会在此花费这么多力气，代码仍旧保持在原先无法测试的状态，并任它慢慢腐败。

每当你决定不编写测试用例时，多时会把原因归结于“没有时间”，而真正导致这个结果的原因，其实是你的代码里有太多垃圾。如果代码结构组织良好，测试不会花费你多少时间的。只有在代码杂乱无章的时候，单元测试才会成为负担。

过早优化

下面的代码片段源自于我之前编写的一个网站：

<?php
if (isset($frm['title_german'][strcspn($frm['title_german'], '<>')])) {
    // ...
}

猜一下它是干什么用的！

其实它只是检查德语标题中是否包含字符“<”或“>”，可以说下你用了多久才看明白的吗？你完全看明白了吗？

我来做一下解释：如果“<”和“>”都没有的话，strcspn会返回字符串的本身长度。所以这段代码可以简单地看成isset($str[strlen($str)])。由于字符串所允许的最大偏移量为字符串本身的长度减一，所以上面代码的结果就永远为false。假如目标字符串中包含前面所述的两个字符中的任何一个，函数就会返回一个小于字符串长度的数字，这样一来，整个表达式的结果就为true。

我为什么要写这么一段难以理解的代码呢？为什么不改用下面的方式呢：

<?php

if (strlen($frm['title_german']) == strcspn($frm['title_german'], '<>'))) {
    // ...
}

因为之前我曾读到过isset要比strlen快许多……但这样写会使代码看起来很隐晦，因为它需要程序员必须精确了解函数strcspn语义（而大多数PHP程序员可能不是特别了解）。所以为什么不改写成：

<?php

if (preg_match('(<|>)', $frm['title_german'])) {
    // ...
}

因为我曾听说使用正则表达式有点慢……（这样说可能有谎话的嫌疑：实际上正则表达式要比我们想象的快得多。）

看看，除了令人费解的代码外，这些所谓的“优化”给我们带来的还有什么呢？一无是处。即便是现在，这个网站每月已经达到四千万左右的访问量（当然，在我刚写下上面代码的时候还远远没有达到这个数字），这个细小的优化基本上是微不足道的。因为这块根本就不是程序的瓶颈。而实际的瓶颈是访问最为频繁的控制器中的三重JOIN（你的程序可能也会有这样的瓶颈）。

从互联网上你可以找到很多这样的微优化（micro-optimization）。如“使用单引号，因为它们比较快一些”。别信这个。这样的建议中大部分都是错误的，即使没错，它也不会让你的代码运行速度有质的飞跃，反而只会浪费你的宝贵时间。

胡乱命名

还有一件事情需要提一下，你知道PHP的strpbrk函数是干什么的吗？不知道？你甚至没听过有这个函数？好吧，也没什么可奇怪的。没有人会去为了搜索字符串中的字符列表而去专门查找一个名为strpbrk的函数。那这个名字究竟从哪里来？其实它是继承于C语言，它的名字代表“string pointer break”。耶，真是太好了，我们在不支持指针的语言中找到指针了（我意思是PHP没有指针，不是指C）。

对了，在读前一节的代码时，你能一下子反应出函数strcspn是干什么的吗？不能？好吧，还是没有什么奇怪的。它是“stringcomplement span”的缩略形式，这样写是防止你搞不清楚它的含义。

到这里为止我们得到的教训就是：劳您大驾，在对类、方法、变量命名的时候，请多斟酌一下，尽量让别人知道您真正的意图。对$i这样的变量我不想争论什么，因为它们太短了，其中的含义不言而喻。真正的问题是出现在像上面那样命名的函数中。像函数strpbrk和变量$yysstk对于作者本人来讲可能很直观，但也就仅限于他本人了。

重复代码

我相信每个人都同意一种说法，短小精炼且直奔主题的代码都可以称为上等佳作（提一下，我说的不是语法风格像Perl/Ruby那样的“精简”）。换个角度来讲，冗长繁琐的代码自然就是丑陋不堪了。其实这也就是前面提到的DRY（不要重复你自己）和KISS（让事情简单化，傻瓜化）原则所教授我们的。

那么，重复代码从何而来？程序员们都是懒散的动物，所以少敲代码是它们的天性。这也就是为什么反复重复的代码至今还在盛行。

我个人认为，产生重复代码最常见的原因就是STUPID原则中的第二条：紧密耦合。如果你的代码彼此之间耦合的很紧，你就不可能重用它们。这就会导致重复性代码的出现。

不要STUPID，坚持GRASP和SOLID

那如何避免编写STUPID代码呢？简单，坚持GRASP和SOLID原则。

SOLID的解释为：

• Single responsibility principle
• Open/closed principle
• Liskov substitution principle
• Interface segregation principle
• Dependency inversion principle

GRASP代表GeneralResponsibility Assignment Software Principles（通用职责分配软件原则），它包括以下内容：

• Information Expert
• Creator
• Controller
• Low Coupling
• High Cohesion
• Polymorphism
• Pure Fabrication
• Indirection
• Protected Variations

编码快乐，新年快乐！

PS：如果你要问STUPID的出处：我可以告诉你，这些想法产自于StackOverflow的PHP聊天室，文章的每个组成部分都是由edorian、James和我搞出来的。而标题是由Gordon想出的。

译注： 原文连接：http://nikic.github.io/2011/12/27/Dont-be-STUPID-GRASP-SOLID.html GRASP：UML和模式应用 SOLID：http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod