网站设计素养,做百度网站要多少钱,怎么建立自己网站,ui培训班哪里有文章目录1. 设计模式1.1 说一说设计模式的六大原则1.2 说一下六大原则中的开闭原则1.3 手写一个单例模式1.4 手写一个线程安全的单例模式1.5 说一说你对工厂模式的理解1.6 简单工厂模式和抽象工厂模式有什么区别#xff1f;1.7 如何实现工厂模式#xff1f;1.8 说一说你策略模…
文章目录1. 设计模式1.1 说一说设计模式的六大原则1.2 说一下六大原则中的开闭原则1.3 手写一个单例模式1.4 手写一个线程安全的单例模式1.5 说一说你对工厂模式的理解1.6 简单工厂模式和抽象工厂模式有什么区别1.7 如何实现工厂模式1.8 说一说你策略模式的理解1.9 说一说你对观察者模式的了解1.10 说一说你对责任链模式的了解1.11 说一说装饰器模式和适配器模式的区别1.12 Spring框架中用到了哪些设计模式1. 设计模式
1.1 说一说设计模式的六大原则
参考答案
单一职责原则
一个类应当只有一个引起它变化的原因即一个类应该只有一个职责。
就一个类而言应该只专注于做一件事和仅有一个引起变化的原因这就是所谓的单一职责原则。该原则提出了对对象职责的一种理想期望对象不应该承担太多职责正如人不应该一心分为二用。唯有专注才能保证对象的高内聚唯有单一才能保证对象的细粒度。对象的高内聚与细粒度有利于对象的重用。一个庞大的对象承担了太多的职责当客户端需要该对象的某一个职责时就不得不将所有的职责都包含进来从而造成冗余代码。
里氏替换原则
在面向对象的语言中继承是必不可少的、优秀的语言机制它主要有以下几个优点
代码共享减少创建类的工作量每个子类都拥有父类的方法和属性提高代码的可重用性提高代码的可扩展性提高产品或项目的开放性。
相应的继承也存在缺点主要体现在以下几个方面
继承是入侵式的。只要继承就必须拥有父类的所有属性和方法降低代码的灵活性。子类必须拥有父类的属性和方法使子类受到限制增强了耦合性。当父类的常量、变量和方法修改时必须考虑子类的修改这种修改可能造成大片的代码需要重构。
从整体上看继承的“利”大于“弊”然而如何让继承中“利”的因素发挥最大作用同时减少“弊”所带来的麻烦这就需要引入“里氏替换原则”。里氏替换原则的定义有以下两种
如果对一个类型为S的对象o1都有类型为T的对象o2使得以S定义的所有程序P在所有的对象o1都代换成o2时程序P的行为没有发生变化那么类型T是类型S的子类型。所有引用基类的地方必须能透明地使用其子类对象。清晰明确地说明只要父类能出现的地方子类就可以出现而且替换为子类也不会产生任何错误或异常使用者可能根本就不需要知道父类还是子类但是反过来则不可以有子类的地方父类未必就能适应。
依赖倒置原则
依赖倒置原则包括三种含义
高层模块不应该依赖低层模块两者都依赖其抽象抽象不依赖细节细节应该依赖于抽象。
传统的过程性系统的设计办法倾向于高层次的模块依赖于低层次的模块抽象层次依赖于具体层次。“倒置”原则将这个错误的依赖关系倒置了过来如下图所示由此命名为“依赖倒置原则”。 在Java语言中抽象就是指接口或抽象类两者都是不能直接被实例化的细节就是具体的实现类实现类实现了接口或继承了抽象类其特点是可以直接被实例化。依赖倒置原则在Java语言中的表现是
模块间的依赖通过抽象发生实现类之间不发生直接的依赖关系其依赖关系是通过接口或抽象类产生接口或抽象类不依赖于实现类实现类依赖于接口或抽象类。
依赖倒置原则更加精确的定义就是“面向接口编程”——OODObject-Oriented Design的精髓之一。依赖倒置原则可以减少类间的耦合性提高系统的稳定性降低并行开发引起的风险提高代码的可读性和可维护性。依赖倒置原则是JavaBean、EJB和COM等组件设计模型背后的基本原则。
接口隔离原则
接口隔离原则有如下两种定义
客户端不应该依赖它不需要的接口。类间的依赖关系应该建立在最小的接口上。
接口隔离原则的具体含义如下
一个类对另外一个类的依赖性应当是建立在最小的接口上的。一个接口代表一个角色不应当将不同的角色都交给一个接口。没有关系的接口合并在一起形成一个臃肿的大接口这是对角色和接口的污染。因此使用多个专门的接口比使用单一的总接口要好。不应该强迫客户依赖于它们不用的方法。接口属于客户不属于它所在的类层次结构即不要强迫客户使用它们不用的方法否则这些客户就会面临由于这些不使用的方法的改变所带来的改变。
迪米特法则
迪米特法则又叫最少知识原则意思是一个对象应当对其他对象尽可能少的了解。迪米特法则不同于其他的OO设计原则它具有很多种表述方式其中具有代表性的是以下几种表述
只与你直接的朋友们通信不要跟“陌生人”说话每一个软件单位对其他的单位都只有最少的了解这些了解仅局限于那些与本单位密切相关的软件单位。
按照迪米特法则如果两个类不必彼此直接通信那么这两个类就不应当发生直接的相互作用如果一个类需要调用另一个类的某一个方法可以通过第三者转发这个调用。
开闭原则
开闭原则的定义是一个软件实体应当对扩展开放对修改关闭。这个原则说的是在设计一个模块的时候应当使这个模块可以在不被修改的前提下被扩展即应当可以在不必修改源代码的情况下改变这个模块的行为。
在面向对象的编程中开闭原则是最基础的原则起到总的指导作用其他原则单一职责、里氏替换、依赖倒置、接口隔离、迪米特法则都是开闭原则的具体形态即其他原则都是开闭原则的手段和工具。开闭原则的重要性可以通过以下几个方面来体现。
开闭原则提高复用性。在面向对象的设计中所有的逻辑都是从原子逻辑组合而来的而不是在一个类中独立实现一个业务逻辑代码粒度越小被复用的可能性就越大避免相同的逻辑重复增加。开闭原则的设计保证系统是一个在高层次上实现了复用的系统。开闭原则提高可维护性。一个软件投产后维护人员的工作不仅仅是对数据进行维护还可能对程序进行扩展就是扩展一个类而不是修改一个类。开闭原则对已有软件模块特别是最重要的抽象层模块要求不能再修改这就使变化中的软件系统有一定的稳定性和延续性便于系统的维护。开闭原则提高灵活性。所有的软件系统都有一个共同的性质即对系统的需求都会随时间的推移而发生变化。在软件系统面临新的需求时系统的设计必须是稳定的。开闭原则可以通过扩展已有的软件系统提供新的行为能快速应对变化以满足对软件新的需求使变化中的软件系统有一定的适应性和灵活性。开闭原则易于测试。测试是软件开发过程中必不可少的一个环节。测试代码不仅要保证逻辑的正确性还要保证苛刻条件高压力、异常、错误下不产生“有毒代码”Poisonous Code因此当有变化提出时原有健壮的代码要尽量不修改而是通过扩展来实现。否则就需要把原有的测试过程回笼一遍需要进行单元测试、功能测试、集成测试甚至是验收测试。开闭原则的使用保证软件是通过扩展来实现业务逻辑的变化而不是修改。因此对于新增加的类只需新增相应的测试类编写对应的测试方法只要保证新增的类是正确的就可以了。
1.2 说一下六大原则中的开闭原则
参考答案
开闭原则的定义是一个软件实体应当对扩展开放对修改关闭。这个原则说的是在设计一个模块的时候应当使这个模块可以在不被修改的前提下被扩展即应当可以在不必修改源代码的情况下改变这个模块的行为。
在面向对象的编程中开闭原则是最基础的原则起到总的指导作用其他原则单一职责、里氏替换、依赖倒置、接口隔离、迪米特法则都是开闭原则的具体形态即其他原则都是开闭原则的手段和工具。开闭原则的重要性可以通过以下几个方面来体现。
开闭原则提高复用性。在面向对象的设计中所有的逻辑都是从原子逻辑组合而来的而不是在一个类中独立实现一个业务逻辑代码粒度越小被复用的可能性就越大避免相同的逻辑重复增加。开闭原则的设计保证系统是一个在高层次上实现了复用的系统。开闭原则提高可维护性。一个软件投产后维护人员的工作不仅仅是对数据进行维护还可能对程序进行扩展就是扩展一个类而不是修改一个类。开闭原则对已有软件模块特别是最重要的抽象层模块要求不能再修改这就使变化中的软件系统有一定的稳定性和延续性便于系统的维护。开闭原则提高灵活性。所有的软件系统都有一个共同的性质即对系统的需求都会随时间的推移而发生变化。在软件系统面临新的需求时系统的设计必须是稳定的。开闭原则可以通过扩展已有的软件系统提供新的行为能快速应对变化以满足对软件新的需求使变化中的软件系统有一定的适应性和灵活性。开闭原则易于测试。测试是软件开发过程中必不可少的一个环节。测试代码不仅要保证逻辑的正确性还要保证苛刻条件高压力、异常、错误下不产生“有毒代码”Poisonous Code因此当有变化提出时原有健壮的代码要尽量不修改而是通过扩展来实现。否则就需要把原有的测试过程回笼一遍需要进行单元测试、功能测试、集成测试甚至是验收测试。开闭原则的使用保证软件是通过扩展来实现业务逻辑的变化而不是修改。因此对于新增加的类只需新增相应的测试类编写对应的测试方法只要保证新增的类是正确的就可以了。
1.3 手写一个单例模式
参考答案
饿汉式单例模式
public class Singleton {private static Singleton instance new Singleton();// 私有构造方法保证外界无法直接实例化。private Singleton() {}// 通过公有的静态方法获取对象实例public static Singleton getInstace() {return instance;}
}懒汉式单例模式
public class Singleton {private static Singleton instance null;// 私有构造方法保证外界无法直接实例化。private Singleton() {}// 通过公有的静态方法获取对象实例public static Singleton getInstace() {if (instance null) {instance new Singleton();}return instance;}
}1.4 手写一个线程安全的单例模式
参考答案
在懒汉式单例模式基础上实现线程同步
public class Singleton {private static Singleton instance null;// 私有构造方法保证外界无法直接实例化。private Singleton() {}// 通过公有的静态方法获取对象实例synchronized public static Singleton getInstace() {if (instance null) {instance new Singleton();}return instance;}
}上述代码对静态方法 getInstance()进行同步以确保多线程环境下只创建一个实例。如果getInstance()方法未被同步并且线程A和线程B同时调用此方法则执行if (instance null)语句时都为真那么线程A和线程B都会创建一个对象在内存中就会出现两个对象这样就违反了单例模式。而使用synchronized关键字进行同步后则不会出现此种情况。
1.5 说一说你对工厂模式的理解
参考答案
工厂模式的用意是定义一个创建产品对象的工厂接口将实际创建性工作推迟到子类中。工厂模式可分为简单工厂、工厂方法和抽象工厂模式。注意我们常说的23种经典设计模式包含了工程方法模式和抽象工厂模式而并未包含简单工厂模式。另外我们平时说的工厂模式一般默认是指工厂方法模式。
简单工厂
简单工厂模式其实并不算是一种设计模式更多的时候是一种编程习惯。简单工厂的实现思路是定义一个工厂类根据传入的参数不同返回不同的实例被创建的实例具有共同的父类或接口。简单工厂的适用场景是
需要创建的对象较少。客户端不关心对象的创建过程。
示例
创建一个可以绘制不同形状的绘图工具可以绘制圆形正方形三角形每个图形都会有一个draw()方法用于绘图不看代码先考虑一下如何通过该模式设计完成此功能。
由题可知圆形正方形三角形都属于一种图形并且都具有draw方法所以首先可以定义一个接口或者抽象类作为这三个图像的公共父类并在其中声明一个公共的draw方法
public interface Shape {void draw();
}下面就是编写具体的图形每种图形都实现Shape接口
// 圆形
class CircleShape implements Shape {public CircleShape() {System.out.println(CircleShape: created);}Overridepublic void draw() {System.out.println(draw: CircleShape);}
}
// 正方形
class RectShape implements Shape {public RectShape() {System.out.println(RectShape: created);}Overridepublic void draw() {System.out.println(draw: RectShape);}}
// 三角形
public class TriangleShape implements Shape {public TriangleShape() {System.out.println(TriangleShape: created);}Overridepublic void draw() {System.out.println(draw: TriangleShape);}
}下面是工厂类的具体实现 class ShapeFactory {public static Shape getShape(String type) {Shape shape null;if (type.equalsIgnoreCase(circle)) {shape new CircleShape();} else if (type.equalsIgnoreCase(rect)) {shape new RectShape();} else if (type.equalsIgnoreCase(triangle)) {shape new TriangleShape();}return shape;}}为工厂类传入不同的type可以new不同的形状返回结果为Shape 类型这个就是简单工厂核心的地方了。
工厂方法
工厂方法模式是简单工厂的仅一步深化 在工厂方法模式中我们不再提供一个统一的工厂类来创建所有的对象而是针对不同的对象提供不同的工厂。也就是说每个对象都有一个与之对应的工厂。
工厂方法的实现思路是定义一个用于创建对象的接口让子类决定将哪一个类实例化。工厂方法模式让一个类的实例化延迟到其子类。
示例
现在需要设计一个这样的图片加载类它具有多个图片加载器用来加载jpgpnggif格式的图片每个加载器都有一个read()方法用于读取图片。下面我们完成这个图片加载类。
首先完成图片加载器的设计编写一个加载器的公共接口
public interface Reader {void read();
}然后完成各个图片加载器的代码
// jpg图片加载器
class JpgReader implements Reader {Overridepublic void read() {System.out.print(read jpg);}
}
// png图片加载器
class PngReader implements Reader {Overridepublic void read() {System.out.print(read png);}
}
// gif图片加载器
class GifReader implements Reader {Overridepublic void read() {System.out.print(read gif);}
}现在我们按照定义所说定义一个抽象的工厂接口ReaderFactory
interface ReaderFactory {Reader getReader();
}里面有一个getReader()方法返回我们的Reader 类接下来我们把上面定义好的每个图片加载器都提供一个工厂类这些工厂类实现了ReaderFactory 。
// jpg加载器工厂
class JpgReaderFactory implements ReaderFactory {Overridepublic Reader getReader() {return new JpgReader();}
}
// png加载器工厂
class PngReaderFactory implements ReaderFactory {Overridepublic Reader getReader() {return new PngReader();}
}
// gif加载器工厂
class GifReaderFactory implements ReaderFactory {Overridepublic Reader getReader() {return new GifReader();}
}在每个工厂类中我们都通过重写的getReader()方法返回各自的图片加载器对象。
和简单工厂对比一下最根本的区别在于简单工厂只有一个统一的工厂类而工厂方法是针对每个要创建的对象都会提供一个工厂类这些工厂类都实现了一个工厂基类。
下面总结一下工厂方法的适用场景
客户端不需要知道它所创建的对象的类。客户端可以通过子类来指定创建对应的对象。
抽象工厂
这个模式最不好理解而且在实际应用中局限性也蛮大的因为这个模式并不符合开闭原则。实际开发还需要做好权衡。抽象工厂模式是工厂方法的仅一步深化在这个模式中的工厂类不单单可以创建一个对象而是可以创建一组对象。这是和工厂方法最大的不同点。
抽象工厂的实现思路是提供一个创建一系列相关或相互依赖对象的接口而无须指定它们具体的类。抽象工厂和工厂方法一样可以划分为4大部分
AbstractFactory抽象工厂声明了一组用于创建对象的方法注意是一组。ConcreteFactory具体工厂它实现了在抽象工厂中声明的创建对象的方法生成一组具体对象。AbstractProduct抽象产品它为每种对象声明接口在其中声明了对象所具有的业务方法。ConcreteProduct具体产品它定义具体工厂生产的具体对象。
示例
现在需要做一款跨平台的游戏需要兼容AndroidIosWp三个移动操作系统该游戏针对每个系统都设计了一套操作控制器OperationController和界面控制器UIController下面通过抽闲工厂方式完成这款游戏的架构设计。
由题可知游戏里边的各个平台的UIController和OperationController应该是我们最终生产的具体产品。所以新建两个抽象产品接口。
抽象操作控制器
interface OperationController {void control();
}抽象界面控制器
interface UIController {void display();
}然后完成各个系统平台的具体操作控制器和界面控制器。
Android
class AndroidOperationController implements OperationController {Overridepublic void control() {System.out.println(AndroidOperationController);}
}
class AndroidUIController implements UIController {Overridepublic void display() {System.out.println(AndroidInterfaceController);}
}IOS
class IosOperationController implements OperationController {Overridepublic void control() {System.out.println(IosOperationController);}
}
class IosUIController implements UIController {Overridepublic void display() {System.out.println(IosInterfaceController);}
}WP
class WpOperationController implements OperationController {Overridepublic void control() {System.out.println(WpOperationController);}
}
class WpUIController implements UIController {Overridepublic void display() {System.out.println(WpInterfaceController);}
}下面定义一个抽闲工厂该工厂需要可以创建OperationController和UIController。
public interface SystemFactory {public OperationController createOperationController();public UIController createInterfaceController();
}在各平台具体的工厂类中完成操作控制器和界面控制器的创建过程。
Android
public class AndroidFactory implements SystemFactory {Overridepublic OperationController createOperationController() {return new AndroidOperationController();}Overridepublic UIController createInterfaceController() {return new AndroidUIController();}
}IOS
public class IosFactory implements SystemFactory {Overridepublic OperationController createOperationController() {return new IosOperationController();}Overridepublic UIController createInterfaceController() {return new IosUIController();}
}WP
public class WpFactory implements SystemFactory {Overridepublic OperationController createOperationController() {return new WpOperationController();}Overridepublic UIController createInterfaceController() {return new WpUIController();}
}下面总结一下抽象工厂的适用场景
和工厂方法一样客户端不需要知道它所创建的对象的类。需要一组对象共同完成某种功能时。并且可能存在多组对象完成不同功能的情况。系统结构稳定不会频繁的增加对象。
1.6 简单工厂模式和抽象工厂模式有什么区别
参考答案
简单工厂模式其实并不算是一种设计模式更多的时候是一种编程习惯。简单工厂的实现思路是定义一个工厂类根据传入的参数不同返回不同的实例被创建的实例具有共同的父类或接口。
工厂方法模式是简单工厂的仅一步深化 在工厂方法模式中我们不再提供一个统一的工厂类来创建所有的对象而是针对不同的对象提供不同的工厂。也就是说每个对象都有一个与之对应的工厂。工厂方法的实现思路是定义一个用于创建对象的接口让子类决定将哪一个类实例化。工厂方法模式让一个类的实例化延迟到其子类。
抽象工厂模式是工厂方法的仅一步深化在这个模式中的工厂类不单单可以创建一个对象而是可以创建一组对象。这是和工厂方法最大的不同点。抽象工厂的实现思路是提供一个创建一系列相关或相互依赖对象的接口而无须指定它们具体的类。
1.7 如何实现工厂模式
参考答案
简单工厂
示例
创建一个可以绘制不同形状的绘图工具可以绘制圆形正方形三角形每个图形都会有一个draw()方法用于绘图不看代码先考虑一下如何通过该模式设计完成此功能。
由题可知圆形正方形三角形都属于一种图形并且都具有draw方法所以首先可以定义一个接口或者抽象类作为这三个图像的公共父类并在其中声明一个公共的draw方法
public interface Shape {void draw();
}下面就是编写具体的图形每种图形都实现Shape接口
// 圆形
class CircleShape implements Shape {public CircleShape() {System.out.println(CircleShape: created);}Overridepublic void draw() {System.out.println(draw: CircleShape);}
}
// 正方形
class RectShape implements Shape {public RectShape() {System.out.println(RectShape: created);}Overridepublic void draw() {System.out.println(draw: RectShape);}}
// 三角形
public class TriangleShape implements Shape {public TriangleShape() {System.out.println(TriangleShape: created);}Overridepublic void draw() {System.out.println(draw: TriangleShape);}
}下面是工厂类的具体实现 class ShapeFactory {public static Shape getShape(String type) {Shape shape null;if (type.equalsIgnoreCase(circle)) {shape new CircleShape();} else if (type.equalsIgnoreCase(rect)) {shape new RectShape();} else if (type.equalsIgnoreCase(triangle)) {shape new TriangleShape();}return shape;}}为工厂类传入不同的type可以new不同的形状返回结果为Shape 类型这个就是简单工厂核心的地方了。
工厂方法
示例
现在需要设计一个这样的图片加载类它具有多个图片加载器用来加载jpgpnggif格式的图片每个加载器都有一个read()方法用于读取图片。下面我们完成这个图片加载类。
首先完成图片加载器的设计编写一个加载器的公共接口
public interface Reader {void read();
}然后完成各个图片加载器的代码
// jpg图片加载器
class JpgReader implements Reader {Overridepublic void read() {System.out.print(read jpg);}
}
// png图片加载器
class PngReader implements Reader {Overridepublic void read() {System.out.print(read png);}
}
// gif图片加载器
class GifReader implements Reader {Overridepublic void read() {System.out.print(read gif);}
}现在我们按照定义所说定义一个抽象的工厂接口ReaderFactory
interface ReaderFactory {Reader getReader();
}里面有一个getReader()方法返回我们的Reader 类接下来我们把上面定义好的每个图片加载器都提供一个工厂类这些工厂类实现了ReaderFactory 。
// jpg加载器工厂
class JpgReaderFactory implements ReaderFactory {Overridepublic Reader getReader() {return new JpgReader();}
}
// png加载器工厂
class PngReaderFactory implements ReaderFactory {Overridepublic Reader getReader() {return new PngReader();}
}
// gif加载器工厂
class GifReaderFactory implements ReaderFactory {Overridepublic Reader getReader() {return new GifReader();}
}在每个工厂类中我们都通过重写的getReader()方法返回各自的图片加载器对象。
抽象工厂
示例
现在需要做一款跨平台的游戏需要兼容AndroidIosWp三个移动操作系统该游戏针对每个系统都设计了一套操作控制器OperationController和界面控制器UIController下面通过抽闲工厂方式完成这款游戏的架构设计。
由题可知游戏里边的各个平台的UIController和OperationController应该是我们最终生产的具体产品。所以新建两个抽象产品接口。
抽象操作控制器
interface OperationController {void control();
}抽象界面控制器
interface UIController {void display();
}然后完成各个系统平台的具体操作控制器和界面控制器。
Android
class AndroidOperationController implements OperationController {Overridepublic void control() {System.out.println(AndroidOperationController);}
}
class AndroidUIController implements UIController {Overridepublic void display() {System.out.println(AndroidInterfaceController);}
}IOS
class IosOperationController implements OperationController {Overridepublic void control() {System.out.println(IosOperationController);}
}
class IosUIController implements UIController {Overridepublic void display() {System.out.println(IosInterfaceController);}
}WP
class WpOperationController implements OperationController {Overridepublic void control() {System.out.println(WpOperationController);}
}
class WpUIController implements UIController {Overridepublic void display() {System.out.println(WpInterfaceController);}
}下面定义一个抽闲工厂该工厂需要可以创建OperationController和UIController。
public interface SystemFactory {public OperationController createOperationController();public UIController createInterfaceController();
}在各平台具体的工厂类中完成操作控制器和界面控制器的创建过程。
Android
public class AndroidFactory implements SystemFactory {Overridepublic OperationController createOperationController() {return new AndroidOperationController();}Overridepublic UIController createInterfaceController() {return new AndroidUIController();}
}IOS
public class IosFactory implements SystemFactory {Overridepublic OperationController createOperationController() {return new IosOperationController();}Overridepublic UIController createInterfaceController() {return new IosUIController();}
}WP
public class WpFactory implements SystemFactory {Overridepublic OperationController createOperationController() {return new WpOperationController();}Overridepublic UIController createInterfaceController() {return new WpUIController();}
}1.8 说一说你策略模式的理解
参考答案
策略模式Strategy Pattern也叫政策模式是一种比较简单的模式。它的目的是定义一组算法将每个算法都封装起来并且使它们之间可以互换。其用意是针对一组算法将每一个算法封装到具有共同接口的独立的类中从而使得它们可以相互替换使得算法可以在不影响到客户端的情况下发生变化。
策略模式的通用类图如下图所示 策略模式涉及以下3个角色
环境Context角色该角色也叫上下文角色起到承上启下的作用屏蔽高层模块对策略、算法的直接访问它持有一个Strategy类的引用。抽象策略Strategy角色该角色对策略、算法进行抽象通常定义每个策略或算法必须具有的方法和属性。具体策略Concrete Strategy角色该角色实现抽象策略中的具体操作含有具体的算法。
抽象策略Strategy的代码如下所示
public abstract class Strategy {public abstract void strategyInterface();
}具体策略ConcreteStrategy的代码如下所示
public class ConcreteStrategy extends Strategy {public void strategyInterface() {...}
}环境角色Context的代码如下所示
public class Context {private Strategy strategy null;public Context(Strategy strategy) {this.strategy strategy;}public void contextInterface() {this.strategy.strategyInterface();}
}策略模式包括如下优点
策略模式提供了管理相关的算法族的办法。策略类的等级结构定义了一个算法或行为族恰当地使用继承可以把公共的代码移到父类中从而避免代码重复。策略模式提供了可以替换继承关系的办法。继承可以处理多种算法或行为如果不用策略模式那么使用算法或行为的环境类就可能会有一些子类每一个子类提供一个不同的算法或行为。但是这样算法或行为的使用者就和算法本身混在一起从而不可能再独立演化。使用策略模式可以避免使用多重条件转移语句。多重转移语句不易维护它把采取哪一种算法或采取哪一种行为的逻辑与算法或行为的逻辑混合在一起统统列在一个多重转移语句里面这比使用继承的办法还要原始和落后。
策略模式包括如下缺点
客户端必须知道所有的策略类并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别以便适时选择恰当的算法类即策略模式只适用于客户端知道所有的算法或行为的情况。策略模式造成很多的策略类。有时候可以通过把依赖于环境的状态保持到客户端里面而将策略类设计成可共享的这样策略类实例可以被不同客户端使用。可以使用享元模式来减少对象的数量。
策略模式有如下几个应用场景
多个类只是在算法或行为上稍有不同的场景。算法需要自由切换的场景。需要屏蔽算法规则的场景。
1.9 说一说你对观察者模式的了解
参考答案
观察者模式Observer Pattern也称发布订阅模式它的目的是定义对象间一种一对多的依赖关系使得每当一个对象改变状态则所有依赖于它的对象都会得到通知并被自动更新。
观察者模式的类图如下图所 观察者模式具有以下4个角色
抽象主题Subject角色该角色又称为“被观察者”可以增加和删除观察者对象。抽象观察者Observer角色该角色为所有的具体观察者定义一个接口在得到主题的通知时更新自己。具体主题Concrete Subject角色该角色又称为“具体被观察者”它将有关状态存入具体观察者对象在具体主题的内部状态改变时给所有登记过的观察者发出通知。具体观察者Concrete Observer角色该角色实现抽象观察者所要求的更新接口以便使自身的状态与主题的状态相协调。
上述类图所涉及的代码如下所示
interface Subject {// 登记一个新的观察者public void attach(Observer obs);// 删除一个登记过的观察者public void detach(Observer obs);// 通知所有登记过的观察者对象public void notifyObserver();
}
interface Observer {// 更新方法public void update();
}
class ConcreteSubject implements Subject {private VectorObserver obsVector new VectorObserver();// 登记一个新的观察者public void attach(Observer obs) {obsVector.add(obs);}// 删除一个登记过的观察者public void detach(Observer obs) {obsVector.remove(obs);}// 通知所有登记过的观察者对象public void notifyObserver() {for (Observer e : obsVector) {e.update();}}// 返回观察者集合的Enumeration对象public EnumerationObserver observers() {return obsVector.elements();}// 业务方法改变状态public void change() {this.notifyObserver();}
}
class ConcreteObserver implements Observer {// 实现更新方法public void update() {System.out.println(收到通知并进行处理);}
}观察者模式具有以下几个优点
观察者和被观察者之间是抽象耦合。被观察者角色所知道的只是一个具体观察者集合每一个具体观察者都符合一个抽象观察者的接口。被观察者并不认识任何一个具体的观察者它只知道它们都有一个共同的接口。由于被观察者和观察者没有紧密的耦合在一起因此它们可以属于不同的抽象化层次且都非常容易扩展。支持广播通信。被观察者会向所有登记过的观察者发出通知这就是一个触发机制形成一个触发链。
观察模式的缺点如下
如果一个主题有多个直接或间接的观察者则通知所有的观察者会花费很多时间且开发和调试都比较复杂。如果在主题之间有循环依赖被观察者会触发它们之间进行循环调用导致系统崩溃。在使用观察者模式时要特别注意这一点。如果对观察者的通知是通过另外的线程进行异步投递系统必须保证投递的顺序执行。虽然观察者模式可以随时使观察者知道所观察的对象发生了变化但是观察者模式没有提供相应的机制使观察者知道所观察的对象是如何发生变化。
观察者模式的应用场景如下
关联行为场景。事件多级触发场景。跨系统的消息交换场景如消息队列的处理机制。
1.10 说一说你对责任链模式的了解
参考答案
责任链模式Chain of Responsibility Pattern是一种常见的行为模式它的目的是使多个对象都有机会处理请求从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链并沿着这条链传递该请求直到有对象处理它为止。
责任链模式的重点是在“链”上由一条链去处理相似的请求在链中决定谁来处理这个请求并返回相应的结果。责任链模式的类图如下图所示 责任链模式涉及以下两个角色
抽象处理者Handler角色该角色对请求进行抽象并定义一个方法以设定和返回对下一个处理者的引用。具体处理者Concrete Handler角色该角色接到请求后可以选择将请求处理掉或者将请求传给下一个处理者。由于具体处理者持有对下一个处理者的引用因此如果需要具体处理者可以访问下一个处理者。
上述类图所涉及的代码如下所示
abstract class Handler {private Handler successor;public abstract void handleRequest();public Handler getSuccessor() {return successor;}public void setSuccessor(Handler successor) {this.successor successor;}
}
class ConcreteHandler extends Handler {// 处理请求public void handleRequest() {if (getSuccessor() ! null) {System.out.println(请求传递给 getSuccessor());getSuccessor().handleRequest();} else {System.out.println(请求处理);}}
}责任链模式的优点如下
责任链模式将请求和处理分开请求者不知道是谁处理的处理者可以不用知道请求的全貌。提高系统的灵活性。
责任链模式的缺点如下
降低程序的性能每个请求都是从链头遍历到链尾当链比较长的时候性能会大幅下降。不易于调试由于采用了类似递归的方式调试的时候逻辑比较复杂。
责任链模式的应用场景如下
一个请求需要一系列的处理工作。业务流的处理例如文件审批。对系统进行补充扩展。
1.11 说一说装饰器模式和适配器模式的区别
参考答案
装饰器的目的是动态地给一个对象添加一些额外的职责这个对象的类型不会发生变化但是行为却发生了改变。
适配器的目的是将一个类的接口变换成客户端所期待的另一种接口就是可以将一个对象包装成另外的一个接口。
1.12 Spring框架中用到了哪些设计模式
Spring框架在实现时运用了大量的设计模式常见的有如下几种 简单工厂 Spring中的BeanFactory就是简单工厂模式的体现根据传入一个唯一的标识来获得Bean对象但是否是在传入参数后创建还是传入参数前创建这个要根据具体情况来定。 工厂方法 实现了FactoryBean接口的bean是一类叫做factory的bean。其特点是spring会在使用getBean()调用获得该bean时会自动调用该bean的getObject()方法所以返回的不是factory这个bean而是这个bean的getOjbect()方法的返回值。 单例模式 Spring依赖注入Bean实例默认是单例的。Spring的依赖注入包括lazy-init方式都是发生在AbstractBeanFactory的getBean里。getBean的doGetBean方法调用getSingleton进行bean的创建。 适配器模式 SpringMVC中的适配器HandlerAdatper它会根据Handler规则执行不同的Handler。即DispatcherServlet根据HandlerMapping返回的handler向HandlerAdatper发起请求处理Handler。HandlerAdapter根据规则找到对应的Handler并让其执行执行完毕后Handler会向HandlerAdapter返回一个ModelAndView最后由HandlerAdapter向DispatchServelet返回一个ModelAndView。 装饰器模式 Spring中用到的装饰器模式在类名上有两种表现一种是类名中含有Wrapper另一种是类名中含有Decorator。 代理模式 AOP底层就是动态代理模式的实现。即切面在应用运行的时刻被织入。一般情况下在织入切面时AOP容器会为目标对象创建动态的创建一个代理对象。SpringAOP就是以这种方式织入切面的。 观察者模式 Spring的事件驱动模型使用的是观察者模式Spring中Observer模式常用的地方是listener的实现。 策略模式 Spring框架的资源访问Resource接口。该接口提供了更强的资源访问能力Spring 框架本身大量使用了 Resource 接口来访问底层资源。Resource 接口是具体资源访问策略的抽象也是所有资源访问类所实现的接口。 模板方法模式
个要根据具体情况来定。 工厂方法 实现了FactoryBean接口的bean是一类叫做factory的bean。其特点是spring会在使用getBean()调用获得该bean时会自动调用该bean的getObject()方法所以返回的不是factory这个bean而是这个bean的getOjbect()方法的返回值。 单例模式 Spring依赖注入Bean实例默认是单例的。Spring的依赖注入包括lazy-init方式都是发生在AbstractBeanFactory的getBean里。getBean的doGetBean方法调用getSingleton进行bean的创建。 适配器模式 SpringMVC中的适配器HandlerAdatper它会根据Handler规则执行不同的Handler。即DispatcherServlet根据HandlerMapping返回的handler向HandlerAdatper发起请求处理Handler。HandlerAdapter根据规则找到对应的Handler并让其执行执行完毕后Handler会向HandlerAdapter返回一个ModelAndView最后由HandlerAdapter向DispatchServelet返回一个ModelAndView。 装饰器模式 Spring中用到的装饰器模式在类名上有两种表现一种是类名中含有Wrapper另一种是类名中含有Decorator。 代理模式 AOP底层就是动态代理模式的实现。即切面在应用运行的时刻被织入。一般情况下在织入切面时AOP容器会为目标对象创建动态的创建一个代理对象。SpringAOP就是以这种方式织入切面的。 观察者模式 Spring的事件驱动模型使用的是观察者模式Spring中Observer模式常用的地方是listener的实现。 策略模式 Spring框架的资源访问Resource接口。该接口提供了更强的资源访问能力Spring 框架本身大量使用了 Resource 接口来访问底层资源。Resource 接口是具体资源访问策略的抽象也是所有资源访问类所实现的接口。 模板方法模式 Spring模板方法模式的实质是模板方法模式和回调模式的结合是Template Method不需要继承的另一种实现方式。Spring几乎所有的外接扩展都采用这种模式。
