以前做项目,只知道实现功能,没有什么思考和优化。今年要找工作,看了一些书,对代码的理解和追求有以下变化:
“代码无错就是优”(实现功能)—>“代码效率”(数据结构和算法)—>“代码的易维护、易扩展、易重用”(面向对象和设计模式)下面介绍一下学习的几个设计模式:
1.简单工厂模式
解决对象的创建问题。
服务端:一个抽象父类(抽象方法),多个子类(重写抽象方法),工厂类中定义public静态方法传入不同参数,实例化不同子类,以父类的身份return。
客户端:使用工厂类的public static方法,传入不同参数,生产不同的对象,调用父类的抽象方法(多态)。
2.策略模式——商场促销
封装算法(策略)的变化,策略可以相互替换。
服务端:和工厂模式一样,定义父类和子类;定义Context类维护对策略对象的引用
Class Context{
Strategy strategy; //策略抽象父类
public Context(Strategy strategy){
this.strtegy = strategy;
}
//上下文接口
public void contextInterface(){
strategy.algorithm();
}
}
客户端:new Context(instance).contextInterface();
**跟简单工厂模式的异同:
(1)两者的父类和子类定义相同
(2)工厂类中生产工厂的函数传入的参数是生产不同对象的标识,而策略模式中Context类构造函数传入的是某个子类的实例
(3)策略模式Context类中封装了对抽象父类方法的调用(contextInterface()),而在工厂模式中需要在客户端调用父类的抽象方法
**策略模式可以和工厂模式结合:在Context构造方法中实现类似工厂生产对象的方法,传入标识,而不是对象实例。这样客户端只需要认识Context类,而不需要像工厂模式中那样,客户端需要认识Factory和抽象父类。
3.单一职责原则
就一个类而言,应该仅有一个引起它变化的原因。
发现职责并把那些职责相互分离。
4.开放-封闭原则
软件实体(类、模块、函数等)应该可以扩展,但是不可以修改,对扩展开放,对更改封闭。
在我们最初编写代码时,假设变化不会发生。当变化发生时,我们就创建抽象来隔离以后发生的同类变化。
比如:编写一个加法的运算,以后增加减法的运算,就可以把原来加法的运算扩展成一个抽象运算父类,加法和减法都成为子类,这样以后要增加乘法除法时,只需增加两个新类继承抽象父类,而不用更改其他代码。
对程序中呈现频繁变化的那些部分做出抽象。