设计模式——单一职责原则
? ? 单一职责原则的英文名称是Single Responsibility Principle，简称是SRP，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); ???????? ?Hangup(); ???????? ?Send( char ?c); ???????? ?Reveive(); ????} ? 我们中的大多数人认为上面的接口已经设计的不错了，四个功能也都是modem的功能。
但是，这里其实是两个职责。一个职责是连接管理，另外一个是数据通信。Dial和Hangup方法管理moden的链接，Send和Receive管理modem的数据通信。
这两个职责是否应该分开呢？毫无疑问是应该的。这两个职责是没有关系的。他们改变的原因不尽相同。而且，他们会被应用的不同部分调用，这两个部分也会因为不同的原因变化。
上图的做法可能更好，将接口分为两个。然后有一个类来实现这两个接口，代表一个modem。
（编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
