不要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] view plain copy
  1. class DB {  
  2.     private static $instance;  
  3.    
  4.     public static function getInstance() {  
  5.         if (!isset(self::$instance)) {  
  6.             self::$instance = new self;  
  7.         }  
  8.    
  9.         return self::$instance;  
  10.     }  
  11.    
  12.     final private function __construct() { /* something */ }  
  13.     final private function __clone() { }  
  14.    
  15.     /* actual methods here */  
  16. }  

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

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

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

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

[php] view plain copy
  1. // original DB class  
  2. class _DB { /* ... */ }  
  3.    
  4. // extending class  
  5. class DB extends _DB { /* ... */ }  

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

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

紧密耦合

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

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

[php] view plain copy
  1. class House {  
  2.     public function __construct() {  
  3.         $this->door   = new Door;  
  4.         $this->window = new Window;  
  5.     }  
  6. }  

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

[php] view plain copy
  1. class House {  
  2.     public function __construct(Door $door, Window $window) { // Door, Window are interfaces  
  3.         $this->door   = $door;  
  4.         $this->window = $window;  
  5.     }  
  6. }  

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

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

不可测试

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

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

过早优化

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

[php] view plain copy
  1. if (isset($frm['title_german'][strcspn($frm['title_german'], '<>')])) {  
  2.     // ...  
  3. }  

猜一下它是干什么用的!

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

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

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

[php] view plain copy
  1.   
  2. if (strlen($frm['title_german']) == strcspn($frm['title_german'], '<>'))) {  
  3.     // ...  
  4. }  
因为之前我曾读到过isset要比strlen快许多……但这样写会使代码看起来很隐晦,因为它需要程序员必须精确了解函数strcspn语义(而大多数PHP程序员可能不是特别了解)。所以为什么不改写成:
[php] view plain copy
  1.   
  2. if (preg_match('(<|>)'$frm['title_german'])) {  
  3.     // ...  
  4. }  

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

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


3楼 evencoming 4小时前发表 [回复]
不如说 滥用设计模式 让代码愚蠢
2楼 csfreebird 前天 23:12发表 [回复]
Singleton将代码变得stupid? 这里例子证明了不能用Singleton封装一个数据库连接,可视如果封装一个连接池呢?封装一个工厂类呢?用来表示全局的Application对象呢?
错误的运用任何经验总计的方法和模式都会引来stupid的嘲笑,但是嘲笑的只应该是错误的运用,而不能针对模式,方法本身。没有说这是万能灵药。
Re: rcom10002 昨天 18:41发表 [回复]
回复sheismylife:个人认为作者Singleton例子不是要从狭隘的角度来说明Singleton封装DB不好,而是要让人们慎用Singleton设计模式,不能滥用,否则这样的设计会为整个架构带来什么样的副作用。从设计角度说,封装一个连接和封装一个连接池没有什么区分,重点要看设计实现是否能够满足抽象,不依赖于具体,依赖要反转。
Re: csfreebird 昨天 20:49发表 [回复]
回复rcom10002:你的观点我赞同,但是文中似乎没有看到这种观点。我也没有细看。
1楼 zjwdmlmx 前天 22:29发表 [回复]
大标题写的很好,就是标题下的例子,不能马上让人懂

  • 面向对象设计原则:不要STUPID,坚持GRASP和SOLID

    evencoming:不如说 滥用设计模式 让代码愚蠢

  • 面向对象设计原则:不要STUPID,坚持GRASP和SOLID

    csfreebird:@rcom10002:你的观点我赞同,但是文中似乎没有看到这种观点。我也没有细看。

  • 面向对象设计原则:不要STUPID,坚持GRASP和SOLID

    rcom10002:@sheismylife:个人认为作者Singleton例子不是要从狭隘的角度来说明Singleto...

  • 面向对象设计原则:不要STUPID,坚持GRASP和SOLID

    csfreebird:Singleton将代码变得stupid? 这里例子证明了不能用Singleton封装一个数据库连接...

  • 面向对象设计原则:不要STUPID,坚持GRASP和SOLID

    zjwdmlmx:大标题写的很好,就是标题下的例子,不能马上让人懂

  • Struts源码粗略分析一:准备开发环境

    lxb_champagne:楼主好人。

  • 禁用Ubuntu Desktop的图形界面,只启动文本模式的命令行

    amanonly12:这篇文章很好。只能修改启动方式,而不能直接禁用/etc/X11/default-display-ma...

  • RTF转HTML,HTML转TXT(Java版)之威力加强版

    fanrenmaomaochong:厉害啊,不过太难找到你这个文章了!

  • 动态装载外部JavaScript脚本文件

    z2482193:谁说我不记得你了?早说是你呀,我就不紧张了!

  • 禁用Ubuntu Desktop的图形界面,只启动文本模式的命令行

    ruyizi:今天我也犯了一个同样的错误,我通过ubuntu挂载ubuntu把问题解决了,谢谢你的文章。


你可能感兴趣的:(C++)