第一次接触设计模式大概在一年以前,当时了解到的都是一些零散的模式,是配合SSH框架一下看的,不久以后,得到张逸先生对我们设计模式的指导,感触颇深,遗憾的是,我们经验不足,不足以将其很好的用于我们自己的系统中,何况,对目前的我们来说,公司的项目,是不会拿给我们设计的。时间一长,也就忘了,最近感觉该再回过头去看看设计模式了,又恐时间长了,没来得及用,又被遗忘,故采纳了张逸先生给的建议,将其写下来......言归正传,先写写设计模式基础,即六大设计原则:
1.单一职责原则
详细定义:应该有且只有一个原因引起类的变更
我们在实际的项目中考虑到成本或者时间的问题,像如上代码比比皆是,而且我们也认为i我们应该这样做,但实际上它违背了单一职责原则。为什么呢?它含有两个职责:1.协议管理(拨通电话和挂电话) 2.数据传送(通话)
协议接通的变化会引起其实现类的变化,同时数据传送的变化也会引起实现类的变化,所以从理论上说,本例已经违背了单一职责原则,但是在实际项目开发中我们可以具体情况具体讨论,记住专家说那句话:这个有时候很难说。另外给出的建议是,接口一定要做到单一职责,类的设计尽量做到一个原因引起变化就行
2.里氏替换原则
详细定义:只要父类能出现的地方,子类就可以出现
主要包含四个部分:
子类必须完全实现父类的方法;
子类可以有自己的个性(因此里氏替换原则可以正着用,却不可以反过来用);
覆盖或实现父类的方法时输入参数可以被放大;
覆写或实现父类的方法时输出结果可以被缩小;
根据里氏替换原则,此时我们将Father f = new Father()换成Son f =new Son(),其运行结果不会改变。读者可以试试将父类和子类doSomething方法的参数类型换换再试试,就会知道出什么问题
3.依赖倒置原则
三层含义:高层模块不应依赖底层模块,两者都应该依赖于抽象;
抽象不应该依赖细节;
细节应该依赖抽象;
对于该原则,记住一点,面向接口编程。其中依赖的三种写法如下:
4.接口隔离原则
详细定义:客户端不应该依赖它不需要的接口;类间的依赖关系应该建立在最小的接口上。
需要注意的是,我们在根据接口隔离原则拆分接口时,必须首先满足单一职责原则。
另外再拆分时注意:接口尽量小,接口要高内聚,定制服务(一个模块一个服务),接口设计粒度要适度
5.迪米特法则
详细含义:一个类应该对自己需要耦合或调用的类知道得越少越好。
像诸如getA().getB().getC().getD()形式一定不要出现(JDK API除外)
同时一个类对外公布的接口越少越好
6.开闭原则
详细含义:对扩展开放,对修改关闭。
主要是为了不影响已有系统的稳定性。从以下几个方面来看:
抽象约束;
元数据控制模块行为(用配置文件管理);
制定项目章程;
封装变化;