近期,公司项目成功上线,进入维护更新阶段。比较清闲,对于期间需求和BUG处理时候,真的很头疼。让我萌生并坚定了要开始接触学习设计模式和应用到编码中的想法。好评了,废话不多说了。首先,我们为什么要学习设计模式?
实际上我们在工作学习中已经接触到了这些模式,只是可能我们没有一个具体的概念化。这些设计模式简而言之,就是前人总结的能够提高我们代码的健壮性、稳定性和可扩展性。在面向对象语言中,我们都需要遵循下面的原则。
面向对象的六大原则:
1,单一原则很简单,就是将一组相关性很高的函数、数据封装到一个类中。换句话说,一个类应该有职责单一。
2,开闭原则:开闭原则理解起来也不复杂,就是一个类应该对于扩展是开放的,但是对于修改是封闭的。我们知道,在开放的app或者是系统中,经常需要升级、维护等,这就要对原来的代码进行修改,可是修改时容易破坏原有的系统,甚至带来一些新的难以发现的BUG。因此,我们在一开始编写代码时,就应该注意尽量通过扩展的方式实现新的功能,而不是通过修改已有的代码实现。
3,里氏替换原则:里氏替换原则的定义为:所有引用基类的地方必须能透明地使用其子类对象。定义看起来很抽象,其实,很容易理解,本质上就是说,要好好利用继承和多态。简单地说,就是以父类的形式声明的变量(或形参),赋值为任何继承于这个父类的子类后不影响程序的执行。看一组代码你就明白这个原则了:
<span style="font-size:18px;">//窗口类
public class Window(){
public void show(View child){
child.draw();
}
}
public abstract class View(){
public abstract void draw();
public void measure(int widht,int height){
//测量视图大小
}
}
public class Button extends View{
public void draw(){
//绘制按钮
}
}
public class TextView extends View{
public void draw(){
//绘制文本
}
}</span>
Window 类中show函数需要传入View,并且调用View对象的draw函数。而每个继承于View的子对象都有draw的实现,不存在继承于View但是却没实现draw函数的子类(abstract方法必须实现)。我们在抽象类设计之时就运用到了里氏替换原则。
4,依赖导致原则
依赖倒置主要是实现解耦,使得高层次的模块不依赖于低层次模块的具体实现细节。怎么去理解它呢,我们需要知道几个关键点:
(1)高层模块不应该依赖底层模块(具体实现),二者都应该依赖其抽象(抽象类或接口)
(2)抽象不应该依赖细节(废话,抽象类跟接口肯定不依赖具体的实现了)
(3)细节应该依赖于抽象(同样废话,具体实现类肯定要依赖其继承的抽象类或接口)
其实,在我们用的Java语言中,抽象就是指接口或者抽象类,二者都是不能直接被实例化;细节就是实现类,实现接口或者继承抽象类而产生的类,就是细节。使用Java语言描述就简单了:就是各个模块之间相互传递的参数声明为抽象类型,而不是声明为具体的实现类;
5,接口隔离原则
接口隔离原则定义:类之间的依赖关系应该建立在最小的接口上。其原则是将非常庞大的、臃肿的接口拆分成更小的更具体的接口。
6,迪米特原则
描述的原则:一个对象应该对其他的对象有最少的了解。什么意思呢?就是说一个类应该对自己调用的类知道的最少。还是不懂?其实简单来说:假设类A实现了某个功能,类B需要调用类A的去执行这个功能,那么类A应该只暴露一个函数给类B,这个函数表示是实现这个功能的函数,而不是让类A把实现这个功能的所有细分的函数暴露给B。