我对设计的基本原则的理解
来源:互联网 发布:日本殖民地知乎 编辑:程序博客网 时间:2024/06/05 05:21
1、单一职权原则
“对应一个类而言,应该仅有一个引起它变化的原因”,也就是一个类的职权(提供)的功能要单一,别在一个类里把所有的事干了。我认为就是所谓的封装,所谓的高内聚。
2、依赖反转原则
高层模版不应该依赖与底层模版,他们不应该依赖与具体的实现,而是应该依赖于抽象。抽象不应该依赖于细节。通俗的说,也就是你在一个类中,别依赖于具体的类,应该依赖于接口。至于怎么样实例化具体的类,答案是依赖注入,具体的实现是通过注入,实例化到高层模版的。创建该底层模版不是,高层模版的责任,而交给了框架,如spring。
3、开闭原则
程序应该对修改关闭,对扩展开放,这原则好理解,就是别为了增加功能改以前的旧代码(不改不错嘛),你可以扩展。
4、里氏替换原则
子类应该可以替换父类,这个我认为也好理解,只要你的程序符合原则2,也就是依赖于接口。你现在new的是猫,将来new的是狗。程序是不会受影响的(当然功能是变化了),因为他们暴漏的接口是一样的。
5、接口隔离原则
我认为这个原则和原则1有点像。但描述的对象是接口(抽象)。譬如你对一个人的描述,runable、sleepable等等,会比run&sleepable强。当你需要跑的时候实现runable就行了。需要睡实现sleepable。神马?你需要边睡边跑?梦游?那你就实现两接口嘛。
为神马要这样?俺认为就是为了复用,为了扩展。想象一下,一个人都比你拆成七零八落了。有一天你需要去银行办事。你可以是一个知道神马是银行的,会跑的人去做这事,也就是(跑去银行)。也可以是,一个知道银行的,会开车的人(开车去银行)。"知道银行"这部分代码就可以重用了。
6、迪米特原则
迪米特原则也叫做“最少知识原则”。强调应该降低类和类之间的耦合,低耦合可以使得修改影响面降低到最低。譬如,你电话费扣错了,你只需要打10086,你依赖于10086,10086要找谁,这是你不需要关心的(你不需要懂,最少知识原则)。这样移动内部的变化,你就不需要管了,他们里面的流程变化神马变化都跟你没关系。
再想想我们找我们的公仆办事,办个小屁事,跑十几个部门。。。你依赖于10几个部门,蛋疼不疼,疼就记住这个原则吧。
- 我对设计的基本原则的理解
- 我对设计模式的理解(一)
- 我对设计模式的理解(二)
- 我对一些设计模式的理解
- 我对UI设计的理解
- 我对设计模式的理解
- 我对设计模式的理解
- wap 设计的基本原则
- 设计模式的基本原则
- 设计模式的基本原则
- UI设计的基本原则
- 设计的四大基本原则
- 架构设计的基本原则
- 设计模式的基本原则
- 架构设计的基本原则
- 数据库设计的基本原则
- 设计模式的基本原则
- 设计模式的基本原则
- WMI012-WMI学习笔记(十二)——Win32_ApplicationService
- 小波变换网文精粹:小波变换和motion信号处理(六)
- 静态初始化块
- Java 图形用户界面-向JApplet添加组件
- oracle 日期函数的使用
- 我对设计的基本原则的理解
- C语言文件操作
- AlphaBlend StretchBlt BitBlt
- 孙鑫教程第三章小测试程序
- SVN中检出(check out) 和 导出(export) 的区别
- 对角论证法
- Openwrt下WHR G300NV2 创建虚拟网卡失败可能原因
- Top 150 Questions - 1.4
- Python:pygame游戏编程之旅二(自由移动的小球)