《面向对象的设计原则二资料》由会员分享，可在线阅读，更多相关《面向对象的设计原则二资料（5页珍藏版）》请在金锄头文库上搜索。
1、面向对象的设计原则二- 单一职责原则动机在本文中职责是指引起变化的原因。 该原则表明，如果你有多个原因去改变一个类，那么应该把这些引起变化的原因分离开， 把这个类分成多个类， 每个类只 负责处理一种改变。 当你做出某种改变时， 只需要修改负责处理该改变的类。 当我们去改变一个具有多个职责的类时可能会影响该类的其他功能。单一职责原则一个类应该只受一种变化的影响。单一职责原则简单而直观，但是在实际实现中可能是很困难的。实例假设我们需要一个对象保存email 信息，在下面的例子中我们将使用IEMAIL 接口。初看起来，一切都很好。但是仔细分析我们会发现我们的 IEMAIL 接口和 Email 类具有
2、两个职责 ( 两种引起改变的原因 ) 。一个是在一些类似 pop3 和 imap的 email 协议下使用该类，如果需要支持其他的协议，需要以其他的方式格式化内容字段，并且需要添加新的代码来支持新的协议。另一个是Content 字段，尽管 content 字段是字符串类型，或许 我们将来要支持其他的格式，例如 HTML 格式。如果我们只用一个类，一个职责的改变可能会影响另一个：添加新的协议需要添加新的代码解析和格式化内容字段。添加新的内容类型 ( 例如 HTML)需要为每种已实现的协议添加代码。Java 代码1./singleresponsibilityprinciple-bad exampl
3、e2.interfaceIEmail3.publicvoidsetSender(Stringsender);4.publicvoidsetReceiver(Stringreceiver);5.publicvoidsetContent(Stringcontent);6.7.8.classEmailimplementsIEmail9.publicvoidsetSender(Stringsender) 10./setsender;11.12.13.publicvoidsetReceiver(Stringreceiver)14./setreceiver;15.16.17.publicvoidsetCo
4、ntent(Stringcontent)18./setcontent;19.20.我们可以创建一个新的 IContent 接口和一个新的 Content 类来分离职责。让每一个类只承担一个职责可以给我们的设计带来更多的灵活性：添加新的协议时只需要修改Email 类。添加新的内容类型时只需要修改Content 类。Java 代码1./singleresponsibilityprinciple-good example2.3.interfaceIEmail4.publicvoidsetSender(Stringsender);5.publicvoidsetReceiver(Stringreceiv
5、er);6.publicvoidsetContent(IContentcontent);7.8.9.interfaceIContent10.publicStringgetAsString();/usedfor serialization11.12.13.classEmailimplements IEmail14.publicvoidsetSender(Stringsender)15./setsender;16.17.18.publicvoidsetReceiver(Stringreceiver)19./setreceiver;20.21.22.publicvoidsetContent(ICon
6、tentcontent)23./setcontent;24.25.总结单一职责原则代表了设计应用程序时一种很好的识别类的方式， 并且它提醒你思考一个类的所有演化方式。 只有对应用程序的工作方式有了很好的理解， 才能 很好的分离职责。/我们知道，在面向对象设计中要做到高内聚低耦合。而 单一职责原则 就 是实现高内聚低耦合的最好办法。面向对象设计中 单一职责原则 是 指：一个类只负责一个功能领域中的相应职责。如果一个类承担的职责过多，就等于把这些职责耦合在了一起。当其中一个职责变化时，可能影响其他职责的运作。下面我们用 C+的例子来具体说明。比如我们有如下的设计：classCShapepublic
7、 :virtualCShape();virtualvoidDraw()=0;virtualdoubleGetArea()=0;classCSquare:publicCShapepublic :voidDraw();doubleGetArea();voidSetWidth( doubledWidth);doubleGetWidth();private:doublem_dWidth;现在有两个不同的应用程序用到了类 CSquare，一个是有关几何计算方面的，另一个是有关图形方面的。对于前者而说，程序从来不需要绘制图形；而对于后 者来说，程序也从来不需要计算图形的面积。在上面这种情况下，我们的设计就
8、违反了单一职责原则 。它即提供了几何计算方面的功能，又提供了图形绘制方面的功能。这样，在 有关几何计算方面的应用程序中就要链接图形显示方面的库文件； 而在有关图形方面的应用程序中却链接了数学计算方面的库文件。而这些多余的链接其实是不必要 的。它们不但会使编译、 链接的时间变长， 而且会使应用程序占用的内存增加。 如果我们对图形的显示代码做了修改， 那么有关几何计算方面的应用程序就要重新链 接。我们为什么要为自己不需要的功能重新链接自己的程序呢？因此， 上面的设计是不正确的。下面是一个符合 单一职责原则 的设计。在这个设计中，把原来的类CShape分为两个 类： CGeometricShape
9、和 CGraphicalShape ，来分别承担几何和图形两方面的职责。同样，分别派生出 GGeometricSquare 和 CGraphicalSquare 。classCGeometricShapepublic :virtualCGeometricShape();virtualdoubleGetArea()=0;classGGeometricSquare:publicCGeometricShapepublic :doubleGetArea();voidSetWidth( doubledWidth);doubleGetWidth();private:doublem_dWidth;classCGraphicalShapepublic:virtualCGraphicalShape();virtualvoidDraw()=0;classCGraphicalSquare: publicCGraphicalShapepublic:voidDraw();voidSetWidth( doubledWidth);doubleGetWidth();private:doublem_dWidth;这样，有关几何计算方面的应用程序和有关图形方面的应用程序之间就没有一点儿耦合了。 不仅应用程序中不会链接多余的代码，而且对其中的任意一个类进行修改都不会影响到另外一个应用程序。
