面向对象设计的10条建议(包子分享)

一个优秀的设计,虽然在最初的时候耗费了较多的时间,但是却极大地增加了系统的扩展性,可维护性甚至是性能。在需求变更迅速的时代,始终坚持一些比较好的OO设计原则可以极大地省下维护的成本。作者在本文中给出了10条 OO 设计的最佳实践。这些建议大多是经验之谈,希望能成为读者系统学习OO设计后的一个补充。此10条设计原则也不乏有偏激之处,望广大读者取其精华,弃其糟粕。

1. 使用含义精确的描述性标题

一般用一个描述性的单词加一个后缀(可选)来命名一个类会比较好。描述性的单词往往应该是非常简短的名词,比如 wheel,  engine 等等。当你发现名字里有多重组合时,比如 WheelWithEngine 你就要考虑是不是你的对象划分有问题了。而后缀单词往往可以用一些约定俗成的词语。比如对于工程对象,我们常用Factory, 对于代理对象,我们就会用Proxy。

2. 避免使用过多的 if-else 或者是 switch 选择语句

所有人都知道,太多的分支语句会严重影响程序的清晰度,降低程序的可维护性。一个面向对象设计的重要好处也正是可以通过多态来消灭过多的分支语句,所以你何不试试呢?下面给出了一个具体的例子。

// 分支风格
Switch (weather) {
    case sunny:
    // do blabla
    case raining:
    // do blaba
    case cloudy:
    // do blaba
}
// 扩展风格
interface Weather {void do();}
class Sunny implements Weather { void do() {}}
class Raining implements Weather { void do() {}}
class Cloudy implements Weather { void do() {}}

void doAction(Weather w) { w.do();}

3. 去扩展而不是总是去修改程序

我想所有开发者都更喜欢写自己的代码,而不是去维护修改别人的逻辑。维护人员一般很难对一段古老代码的原始逻辑保持非常清晰头脑,加之反复修改的代码千疮百孔,往往一不小心不仅不能实现新的功能,反倒引入了regression。所以我们的典型做法就是使用上一条建议,通过引入接口来实现可扩展的代码。用户在增加新功能的时候,可以通过增加一个新的接口实例来实现。

4. 尽量避免使用全局状态,因为他们会导对象行为不确定

函数或者类行为的不确定性往往是导致很多软件BUG的根源。在这里的行为不确定性指的是某个对象或者某个函数被多次调用的时候,虽然给定的参数相同,却给出不同的行为。这种现象的产生往往是源自于对象或函数根据全局状态改变了其行为。避免使用全局状态可以有效改善这种事情的发生。

5. 尽量避免静态类,产生非实例函数等

类的贫血模型和充血模型是很多人一直争论不休的话题。在这里,作者认为静态的类函数等辅助函数会有很大概率引入全局的状态(因为他们本身不存储状态)。还有一些更糟糕的情况就是由于他们可以被到处直接使用而不通过参数传入,这种隐式的依赖关系会带来非常多的困扰。

6. 把业务逻辑和对象创建分离

在面向对象的程序设计中,为了能够实现正确的抽象,以及对象行为的多态,我们必须把对象的创建给单独抽象出来。就比如说一个统计函数需要使用一个XMLParser 的时候,instead of 创建一个XMLParser 对象,更好的做法往往是 使用一个IXMLParser 接口,然后增加一个这个接口的参数,让调用者传入创建好的Parser 对象。这个统计函数里面只管使用实现了IXMLParser接口的对象,而不要去关心那个对象是如何被创建出来的。这样,这个对象就可以随时被替换掉而不影响业务逻辑。

7. 不要把业务逻辑放在构造函数里面

这一条是为了实现上一条而特别添加的。如果把业务逻辑混入了构造函数,那我们在创建对象的时候就不可避免地接触到了业务逻辑,也就不可能将业务逻辑和对象创建分离了。

8. 对象者函数对其他对象的依赖应该最小化

这是一个非常拗口的概念。让我们通过一个现实生活中的例子来解释。圣诞节时你要给你老妈寄礼物,而当你去邮局的时候只是给他们一个包装好的盒子以及一个你老妈的地址。你不会把你盒子里面装的是送给你老妈的礼物以及收件人是你老妈这些事情都告诉邮递员。而邮局也可通过最少的信息-- 邮递盒子以及目的地址把他们的任务完成。在软件开发中,我们往往也要限制对象间交互的信息,这样就可以减少不必要的依赖。

9. 降低代码复杂度

这个就是老生常谈的话题了,我们就不再展开赘述。

10. 不要用长方法

原作者要求函数应该不超过一屏幕的大小,不过这个的确是一个仁者见仁智者见智的事情了。

请进入 http://www.codeproject.com/Articles/768052/Golden-Rules-Of-Good-OOP  查看原文。

博客推送