面向对象类设计的五大原则（一）单一职责原则Single Responsibility Principle

　　引言

　　面向对象类设计，或者说是面向对象设计，有五大原则:

• 　　Single Responsibility Principle 　　　　单一职责原则
• 　　Open Closed Principle　　　　　　　　开闭原则
• 　　Liskov Substitution Principle　　　　　里氏替换原则
• 　　Dependency Inversion Principle　　　 依赖反转原则
• 　　Interface Segregation Principle　　　　接口隔离原则

　　简介

　　今天我们要接触的是SRP，单一职责原则。

　　我觉得这些原则的目的就是要实现类的高内聚、低耦合。高内聚high cohision和低耦合low couple在很多时候都是我们的目标，不管我们引入设计模式，进行架构分析、设计、提高复用性，解耦decouple是我们共同的目标。

　　There should never be more than one reason for a class to change.

　　类的改变不应该由一个以上的原因导致，也就是说不应该有一个以上的原因可以导致类的改变。

　　如果类的职责超过一个，这些职责之间就会产生耦合。改变一个职责，可能会影响和妨碍类为其他人服务的功能。这种类型的耦合将会导致脆弱的设计，在修改的时候可能会引入未逾期的问题。

　　

　　如上图所示，Rectangle类有两个方法：一个是在屏幕上画矩形，一个是计算矩形的面积。两个不同的应用会使用Rectangle类，一个应用使用Rectangle来帮助计算面积，它从来不会在屏幕画矩形。另外一个是图形界面的应用，也可能会计算面积，但是肯定会在屏幕画矩形。

　　当前的设计就违反了SRP原则，Rectangle类有两个职责，一个是为数学模型提供几何的矩形，计算面积；另外一个职责是为图形用户界面提供矩形的显示。

　　这个违反SRP原则的设计会导致很多严重的问题。首先，在计算几何应用中必须包含GUI。因为计算几何应用可能就是一个控制台程序，不需要用户界面，但是由于需要使用这个违反SRP原则的类，就必须要包含GUI的类库，在编译的时候要同时编译，在部署的时候还增加了部署的内容，而且这些内容可能永远都不会被用到。

　　其次，如果图形应用的变化，需要修改Rectangle类的话。我们的计算几何应用也必须要重新编译和部署，因为它也引用了相同的Rectangle类，如果不那么做的话，可能会发生意外的错误（因为Rectangle类被修改了，不知道有没有什么影响）。

　　好一点的做法是将Rectangle分解为两个类，如下图所示

　　

　　将计算面积部分从Rectangle类中分离出来，产生一个GeometricRectangle类，专门用来计算面积。这样的话，对于画矩形方法的修改就不会影响到计算几何应用了。也不用在部署多余的内容。

　　什么是职责？

　　在上文中，我们将单一职责定义为“一个改变的原因”。如果你想出超过一个改变类的动机，就说明类具有多个职责。这很难以发现。我们习惯于按照组来思考职责。例如，考虑下面的Modem接口。

　　

interface IModem
    {
        public void Dial(string no);
        public void Hangup();
        public void Send(char c);
        public char Reveive();
    }

 

　　我们中的大多数人认为上面的接口已经设计的不错了，四个功能也都是modem的功能。

　　但是，这里其实是两个职责。一个职责是连接管理，另外一个是数据通信。Dial和Hangup方法管理moden的链接，Send和Receive管理modem的数据通信。

　　这两个职责是否应该分开呢？毫无疑问是应该的。这两个职责是没有关系的。他们改变的原因不尽相同。而且，他们会被应用的不同部分调用，这两个部分也会因为不同的原因变化。

　　

　　上图的做法可能更好，将接口分为两个。然后有一个类来实现这两个接口，代表一个modem。

　　结论

　　SRP原则是最简单的原则之一，也是最难做好的原则之一。我们会很自然的将职责连接在一起。找到并且分离这些职责是软件设计需要达到的目的。