重温面向对象——单一功能原则

工作一年多来，经过了大大小小几个项目的磨练，对于实现业务的各种工具的使用也越来越熟练，但或多或少产生了拿来主义的习惯，心安理得的使用别人写好的各种精工具，忽略了最基础的编程艺术。对于c或cpp各种算法大概会称为艺术，对于java更多的艺术感大概来自于面向对象的思想和对于设计模式的应用。

于是产生了重新理顺一下对面向对象知识的打算。

以后一系列文章将会结合实际的生活工作，从面向对象的角度来诠释我对于面向对象思想和设计模式的理解。

面向对象的经典原则（这里只说面向类的原则，面向包的原则貌似还没啥深刻的体会，以后再补上）
SRP单一功能原则
OCP开放封闭原则
LSP里氏替换原则
DIP依赖倒置原则
ISP接口隔离原则

1，单一功能原则(不要存在多于一个导致类变更的原因)
简而言之就是”每个类只担任一个职责＂。
回到定义上来看待这个问题，事物的变化是绝对的，在软件的生命周期里，每个类都存在着不同程度上变更的风险。如何将这些变化的影响范围控制到最合理，是程序程序设计上首要重视的问题。
比如我一开始要处理一个Excel报表，所以我写了一个ReportFormHandler类，这个类可能会有如下方法–read(),write(),analyze()。
但是，随着时间的推移，我又需要处理PDF报表了，这样我就不得不在这个类里面大展身手，发挥仅有的开发经验写入无数的if…else，终于要大功告 成的时候，会不会突然得到消息，又需要分析word报表？于是不知不觉间，一项优美的富有创造精神的活动，变成了搬砖一样的体力活动。
于是，就需要开始考虑是不是ReportFormHandler需要做的事太多了。于是我们需要将ReportFormHandler类的职责分离开。（如下图）

未分割职责

分割职责后

经过职责分割的设计，看起来多加了3个 接口，使得代码文件看起来更多了，但是，当需求有所改变的时候，只需要对相应改变的接口实现做出修改就可以了，而ReportFormHandler这个类则充当了中枢的角色，由它来集中调配实现报表处理的功能。
不过尽管这样的设计看起来使得ReportFormHandler的职责更加单一，但是这是建立在他包含的三个方法存在着较高的变化可能，如果变化的几率非常低，那么职责分离造成的后果就是产生较高的成本了。

在实际的项目中，贯彻“单一功能原则”需要把握好一个度，如果极端的把每一个方法都独立的定义成一个接口，那么项目的内聚性将会变得极低。同样违反了软件设计的“高内聚，低耦合”的原则。

在设计时贯彻“单一功能原则”的优点在于：
1，很大程度上降低的类的复杂度，使得代码的结构更加坚实。
2，降低的变更引起的风险，和测试的成本。
3，使代码更易于理解，读上层代码的时候不需要过多关注业务的具体实现，一定程度上节省了新人进入项目的成本。

“单一功能原则”在我经历的很多项目里并没有得到很好的落实，这使得不论是前期理解代码成本，还是后期测试的成本都有了不少的增加。并且由于不能完全理解原有机能的实现方法，而产生一些没必要的BUG。甚至发生由于时间紧迫不得不在上层逻辑里面打补丁这样危险的事情。

随着经验的不断扩充，让我意识到，好的基本设计往往决定了一个项目之后很长时间的消耗。所以，好的程序员应该做到尽量不给后人挖坑。
转载请注明出处原文地址：http://www.pgdaily.com/2013/08/04/srp/