Chinaunix首页 | 论坛 | 博客
  • 博客访问: 531137
  • 博文数量: 196
  • 博客积分: 115
  • 博客等级: 民兵
  • 技术积分: 359
  • 用 户 组: 普通用户
  • 注册时间: 2010-05-13 23:19
文章分类

全部博文(196)

文章存档

2019年(5)

2018年(11)

2017年(16)

2016年(13)

2015年(46)

2014年(81)

2013年(22)

2012年(2)

分类: 架构设计与优化

2015-05-07 14:13:09


一、单一职责原则。                                                                        

    Single Responsibility Principle,应该有且仅有一个原因引起类的变更,实际中比较不好把握,因为职责的划分没有一个统一的标准。



二、里氏替换原则。                                                                       

    Liskov Substitution Principle,通俗点讲,只要父类能出现的地方子类就可以出现,而且替换为子类也不会产生任何错误或异常,使用者可能根本就不需要知道是父类还是子类。但是,反过来就不行了,有子类出现的地方,父类未必就能适应。



三、依赖倒置原则。                                                                       

    Dependence Inversion Principle,高层模块不应该依赖低层模块,两者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象;在Java语言中的表达就是,模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的;接口或抽象类不依赖于实现类;实现类依赖接口或抽象类。



四、接口隔离原则。                                                                       

    Interface Segregation Principle,建立单一接口,不要建立臃肿庞大的接口,接口尽量细化,同时接口中的方法尽量少。(单一职责要求的是类和接口职责单一,注重的是职责,这是业务逻辑上的划分,而接口隔离原则要求接口的方法尽量少。例如一个接口的职责可能包含10个方法,这10个方法都放在一个接口中,并且提供给多个模块访问,各个模块按照规定的权限来访问,在系统外通过文档约束“不使用的方法不要访问”,按照单一职责原则是允许的,按照接口隔离原则是不允许的,因为它要求“尽量使用多个专门的接口”。)



五、迪米特原则。                                                                           

    Law of Demeter,一个对象应该对其他对象有最少的了解。通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,你(被耦合或调用的类)的内部是如何复杂都和我没关系,那是你的事情,我就知道你提供的这么多public方法,我就调用这么多,其他的我一概不关心。



六、开闭原则。                                                                               

    Open Closed Principle,软件实体应该对扩展开放,对修改关闭,其含义是说一个软件实体应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化。



总结

    之所以有这么多的原则来指导我们进行程序的设计和开发,是因为我们的程序存在未知的改变。为了以最低的代价拥抱这种未知的变化,前辈们给我们总结了这么多原则,开闭原则应该是每一个大师的终极目标。在所有这些原则中,很重要的一环就是抽象类和接口的灵活运用。后面的23种具体的设计模式也是对“变化“的总结。


阅读(833) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~