软件理论设计总结:
1. 设计原则—SOLID:S:单一职责原则;O:开放关闭原则;L:里氏替换原则;I:接口分离原则;D:依赖倒置原则。
参考:
http://www.cnblogs.com/shanyou/archive/2009/09/21/1570716.html
单一职责原则:一个类只做一种类型责任,当这个类需要承当其他类型的责任的时候,就需要分解这个类。
例子:
1. 像user对象和role对象,user对象只能操作用户信息,role对象只能操作角色信息,不能越界。
2. 像BC层和DAO层的类,BC层的类只负责接收数据、进行业务逻辑处理、输出数据,DAO层的类只负责接收数据、持久化数据、返回持久化结果。
特例:
1. 如果做一件事,一定会改变两个实体(这两个实体无法分开),那只能做在一个类中。
什么时候单一职责会很容易被忽略:
1. 敏捷开发
2. 小型项目
开放关闭原则:软件实体应该是可扩展,而不可修改的。也就是说,对扩展是开放的,而对修改是封闭的。
描述:对类的改动是通过增加代码进行的,而不是改动现有的代码。也就是说,软件开发人员一旦写出了可以运行的代码,就不应该去改变它,而是要保证它能一直运行下去,如何才能做到这一点呢?这就需要借助抽象和多态,即把可能变化的内容抽象出来,从而使抽象的部分是相对稳定的,而具体的实现层则是可以改变和扩展的。(通常做法是用接口或抽象类将可变化内容抽象出来)
将可变化的内容抽象出来,使得抽象部分相对稳定?????
核心:“找到系统中的可变因素,将其封装起来”。要使用----EVP(封装可变性原则)
EVP的两个要点:
1. 一种可变性不应散落在代码的很多角落,而应封装到一个对象中。
2. 一种可变性与另一种可变性不应混合在一起。
里氏替换原则:当一个子类的实例应该能够替换任何其超类的实例时,它们之间才具有is-A关系
换一种说法:同一个继承体系中的对象应该有共同的行为特征。里氏替换原则关注的是怎样良好地使用继承,也就是说不要滥用继承,它是继承复用的基石。
接口分离原则:不能强迫用户去依赖那些他们不使用的接口。换句话说,使用多个专门的接口比使用单一的总接口总要好。
例子:一个接口有85个方法,这是多么巨大的一个接口,也许这个一个根据业务组合形成的接口,如果将接口拆分成多个独立的小接口,那么可以组合使用,也可以单独使用。
依赖倒置原则:
1. 高层模块不应该依赖于低层模块,二者都应该依赖于抽象
2. 抽象不应该依赖于细节,细节应该依赖于抽象
2. 设计原则:封装变化、多用组合少用继承、最少知识原则、好莱坞原则;
2. 其实优先使用组合而不是继承原则的意思就是:在复用对象的时候,要优先考虑使用组合,而不是继承,这是 因为在使用继承时,父类的任何改变都可能影响子类的行为,而在使用组合时,是通过获得对其他对象的引用而在运行时刻动态定义的,有助于保持每个类的单一职责原则。
所有的framework都是遵循好莱坞原则设计的,否则就不叫framework。framework使用IoC的目的:
1.对基于接口编程的支持
2.减少单件和抽象工厂的依赖
3.降低业务和框架的耦合
4.业务组件可复用,可插拔
在网络编程中,特别是server端编程时,我们可能会大量利用好莱坞原则。在 server端编程时,我们大多会利用OS提供的一些功能强大的时间分派机制,比如select/poll/epoll /WaitForMultipleObjects等,通过对这些机制的再次包装和抽象,牛人们提出了著名的reactor模式。在此模式中,我们使用者不 用关心以下事情:
1)socket什么时候建立连接
2)socket什么时候有数据带来
3)socket什么时候把数据发送
4)socket什么时候断开连接
我 们关心的是这些事件带来的时候,我们怎么处理?比如socket建立连接了,你是否要做一些log,以便以后查看。收到数据之后,你是否要做完整性验证 等。我们不用关心事件怎么来(HOW),什么时候来(WHEN),我们关心的唯一一件事是处理它(Do it)。在这里如果把reactor等抽象系统比喻成好莱坞的话,网络上的数据比喻成影片或剧本的话,我们可以把我们对数据的处理比喻成演员。这里,演员 不用去找剧本,好莱坞会带着剧本来找你,你只要乖乖着等在家里不要乱动,等剧本来了,你给我好好处理即可。