御龙在天马跃檀溪,担忧中国或从海上攻击 美加速建潜艇,男子偷袭老虎 下幕哭笑不得
单一原则： 程序设计时功能模块独立，功能单一更有助于维护和复用。
例如：个人计算机功能很多，如果想从中只拿出一个功能来制造一个新的东西是困难的。同时如果你的计算机开不机，同时你的计算器功能也不能用了。
在编程中如果一个类封装了太多功能和上面的结果是类似的。
单一职责原则
例1：
大家应该能看出来这个类图中的接口设计是有问题的，用户的属性和用户的行为没有分开。我们根据用户的属性和行为拆开这个接口。
重新拆分成两个接口，iuserbo 负责用户的属性，iuserbiz负责用户的行为。当我们实例化除userinfo这个对象后，我们可以把userinfo当做iuserbo实现类使用也可以将它当做iuserbiz的实现类使用，这就要看我们用在什么地方了。如果是获取用户信息，就把userinfo 当做iuserboss的实现类，如果是维护用户信息，就当做是iuserbiz的实现类。在实际应用中我们更倾向于把一个接口拆分成两个，一个是iuserbo一个是iuserbiz。类图如下。
这样做以后，我们就把一个接口拆成了两个，这样就符合了单一职责原则，那么什么是单一职责原则呢？
单一职责原则，核心思想是：一个类，最好只做一件事，只有一个引起它变化的原因。
单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，可能引起变化的原因就越多，这将是导致职责依赖，相互之间就产生影响，从而极大的损伤其内聚性和耦合度。单一职责通常意味着单一的功能，因此不要为类实现过多的功能点，以保证实体只有一个引起它变化的原因。例2：
rectangle拥有两个方法，一个方法是draw,用来画图形，另一个方法是area用来计算面积。rectangle违背了单一职责原则，因为它具有两个职责：计算面积与绘制矩形。绘制图形会与用户界面有关，但是计算图形面积却未必与界面有关，如果把这两个职责写到一个类中，那么如果只需要使用area（）方法这一职责来计算面积，那就不得不把draw()方法一同编译，但是却可能也用不到它。如果其中一个职责需要修改，就不得不重新编译和部署另外一个。如果类的职责超过一个，这些职责之间就会产生耦合。改变一个职责，可能会影响和妨碍类为其它类服务的功能。把两个职责分开会好一些。
两个职责分离，这样耦合度就会降低。srp原则的核心就是要求对类的改变只能是一个，对于违反这一原则的类应该进行重构，例如以façade模式或proxy模式分离职责，通过基本的方法extract interface、extract class和extract method进行梳理。
例3：看一下下面的接口
public interface phone
{
//拨通电话
public void dial(string phonenumber);
//通话
public void chat(object o);
//回应
public void answer(object o);
//通话完毕
public void huangup();
}
这个接口有问题吗？还真有问题。单一职责要求一个接口或者类只有一个原因引起变化，也就是一个接口或者类只有一个职责，它负责一件事情。phone这个接口不是一个职责，它是有两个职责：一个是协议管理，一个是数据传输。diag()和huangup()这两个方法实现的是协议管理，拨号和挂断。chat()和answer()是数据传输。协议改变和数据传输都会引起类的变化，那么我们就不能说它是符合单一职责原则。由于这两个职责变化不互相影响，那么就考虑拆成两个接口。
这个类图已经符合单一职责原则，但是却复杂多了，组合是一种强耦合关系，两者都有共同的生命期，这种强耦合增加了类的复杂性，我们修改一下。
这样设计才完美，一个手机实现两个接口，把两个职责融合一个类中，虽然你会觉得这个phone类有两个原因引起变化，但是我们是面向接口编程，对外公布的是接口，而不是实现类。如果非要使得类符合单一职责原则，那么就要使用上一个类图了，但是这样的话类的耦合性就增加了.
单一职责原则的好处：类的复杂性降低可读性提高可维护性提高变更引起的风险降低
如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！ 点击进行留言回复
Blazor server side 自家的一些开源的, 实用型项目的进度之 CEF客户端
.NET IoC模式依赖反转(DIP)、控制反转(Ioc)、依赖注入(DI)
vue+.netcore可支持业务代码扩展的开发框架 VOL.Vue 2.0版本发布
我要评论
网友评论