昨天我们单位的答辩过去了,同事们针对各组提问的问题,归根到底,都围绕着设计原则,所以小笨鸟下来就查了,什么是设计原则撒,要怎么运用到我们的实际项目开发中呢?下面是我总结的前辈的经验,结合自己的理解,同样与君共勉~
一、开闭原则
昨天答辩的时候这个原则是我们小组提出来的,导师给我简单的说了一句:对扩展开放,对修改关闭!小笨鸟觉得不懂啊,后来仔细查查才知道,开闭原则说的也就是:在不修改原(指原来)代码的情况下进行扩展。哦哦,这样的话可能就好理解一些了!而且在阅读的过程中看到一句话:开闭原则是理想模式,是面向对象设计的终极目标!这句话其实也对应了一句话:开闭原则像是其他五个原则的平均分,如果其他五个原则遵循的好,那么平均分就高,开闭原则遵循的也就越好!
二、单一职责原则
定义:不要存在多于一个导致类变更的原因!(不理解~) 通俗点说,就是一个类负责一项职责!这是一个程序员的基本常识。但是往往在实际开发的过程中出现违背这一原则的现象,这个也是允许的,要以具体情况而定!
三、里氏代换原则
我们在实际设计的时候,比如一个类B继承了类A,A具有P1功能,B具有P2功能,B在继承A的时候,应该具有P1和P2的功能,尽量不重载或者重写A的功能。这其实也就是遵循了里氏代换原则。
定义:子类可以扩展父类的功能,但是不能改变父类的原有功能!
四、依赖倒置原则
定义:高层模块不应该依赖底层模块,二者都应该依赖其抽象。抽象不应该依赖细节,细节依赖抽象。
其实这句话看起来有些难懂,但是解释一下“抽象”的含义,可能就更好理解了。抽象在java中指的是接口或者抽象类
依赖倒置原则的核心思想是面向接口编程(最大的有点:解耦合)。
五、接口隔离原则
定义:客户端不应该依赖它不需要的接口,一个类对另外一个类的依赖应该建立在最小的接口上。
六:迪米特法则(最小知识原则)
定义:一个对象应该对其他对象有尽可能少的了解。
通俗来讲,就是一个类对自己依赖的类知道的越少越好,也就是说,对于被依赖的类,无论内部的逻辑多么复杂,都尽量的封装在类的内部,除了对外的public方法,不对外泄露任何逻辑信息。
以上六个原则应该合理使用,这样才能设计出优雅的代码。