单一职责原则告诉我们实现类要职责单一;
里氏替换原则告诉我们不要破坏继承体系;
依赖倒置原则告诉我们要面向接口编程;
接口隔离原则告诉我们在设计接口的时候要精简单一;
迪米特法则告诉我们要降低耦合。
而开闭原则是总纲,他告诉我们要对扩展开放,对修改关闭。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KIRmV0UU-1596532080527)(D97A78BA8C644248A093ECE47B5BF4A9)]
单例模式:某个类只能有一个实例,提供一个全局的访问点。
简单工厂:一个工厂类根据传入的参量决定创建出那一种产品类的实例。
工厂方法:定义一个创建对象的接口,让子类决定实例化那个类。
抽象工厂:创建相关或依赖对象的家族,而无需明确指定具体类。
建造者模式:封装一个复杂对象的构建过程,并可以按步骤构造。
原型模式:通过复制现有的实例来创建新的实例。
适配器模式:将一个类的方法接口转换成客户希望的另外一个接口。
组合模式:将对象组合成树形结构以表示“”部分-整体“”的层次结构。
装饰模式:动态的给对象添加新的功能。
代理模式:为其他对象提供一个代理以便控制这个对象的访问。
亨元(蝇量)模式:通过共享技术来有效的支持大量细粒度的对象。
外观模式:对外提供一个统一的方法,来访问子系统中的一群接口。
桥接模式:将抽象部分和它的实现部分分离,使它们都可以独立的变化。
模板模式:定义一个算法结构,而将一些步骤延迟到子类实现。
解释器模式:给定一个语言,定义它的文法的一种表示,并定义一个解释器。
策略模式:定义一系列算法,把他们封装起来,并且使它们可以相互替换。
状态模式:允许一个对象在其对象内部状态改变时改变它的行为。
观察者模式:对象间的一对多的依赖关系。
备忘录模式:在不破坏封装的前提下,保持对象的内部状态。
中介者模式:用一个中介对象来封装一系列的对象交互。
命令模式:将命令请求封装为一个对象,使得可以用不同的请求来进行参数化。
访问者模式:在不改变数据结构的前提下,增加作用于一组对象元素的新功能。
责任链模式:将请求的发送者和接收者解耦,使的多个对象都有处理这个请求的机会。
迭代器模式:一种遍历访问聚合对象中各个元素的方法,不暴露该对象的内部结构。
1、只有一个实例。 2、自我实例化。 3、提供全局访问点。
工厂方法模式定义了一个创建对象的接口,但由子类决定要实例化的类是哪一个,也就是说工厂方法模式让实例化推迟到子类。
所谓抽象工厂模式就是提供一个接口,用于创建相关或者依赖对象的家族,而不需要明确指定具体类。他允许客户端使用抽象的接口来创建一组相关的产品,而不需要关系实际产出的具体产品是什么。
Spring框架中使用到了大量的设计模式,下面列举了比较有代表性的:
代理模式—在AOP和remoting中被用的比较多。
单例模式—在spring配置文件中定义的bean默认为单例模式。
模板方法—用来解决代码重复的问题。比如. RestTemplate, JmsTemplate, JpaTemplate。
前端控制器—Spring提供了DispatcherServlet来对请求进行分发。
视图帮助(View Helper
)—Spring提供了一系列的JSP标签,高效宏来辅助将分散的代码整合在视图里。
依赖注入—贯穿于BeanFactory / ApplicationContext接口的核心理念。
工厂模式—BeanFactory用来创建对象的实例。
答:面试被问到关于设计模式的知识时,可以拣最常用的作答,例如:
工厂模式:工厂类可以根据条件生成不同的子类实例,这些子类有一个公共的抽象父类并且实现了相同的方法,但是这些方法针对不同的数据进行了不同的操作(多态方法)。当得到子类的实例后,开发人员可以调用基类中的方法而不必考虑到底返回的是哪一个子类的实例。
代理模式:给一个对象提供一个代理对象,并由代理对象控制原对象的引用。实际开发中,按照使用目的的不同,代理可以分为:远程代理、虚拟代理、保护代理、Cache代理、防火墙代理、同步化代理、智能引用代理。
适配器模式:把一个类的接口变换成客户端所期待的另一种接口,从而使原本因接口不匹配而无法在一起使用的类能够一起工作。
模板方法模式:提供一个抽象类,将部分逻辑以具体方法或构造器的形式实现,然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法(多态实现),从而实现不同的业务逻辑。
除此之外,还可以讲讲上面提到的门面模式、桥梁模式、单例模式、装潢模式(Collections工具类里面的synchronizedXXX方法把一个线程不安全的容器变成线程安全容器就是对装潢模式的应用,而Java IO里面的过滤流(有的翻译成处理流)也是应用装潢模式的经典例子)等,反正原则就是拣自己最熟悉的用得最多的作答,以免言多必失。
所谓设计模式,就是一套被反复使用的代码设计经验的总结(情境中一个问题经过证实的一个解决方案)。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式使人们可以更加简单方便的复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。
在GoF的《Design Patterns: Elements of Reusable Object-Oriented Software》中给出了三类(创建型[对类的实例化过程的抽象化]、结构型[描述如何将类或对象结合在一起形成更大的结构]、行为型[对在不同的对象之间划分责任和算法的抽象化])共23种设计模式,包括:Abstract Factory(抽象工厂模式),Builder(建造者模式),Factory Method(工厂方法模式),Prototype(原始模型模式),Singleton(单例模式);Facade(门面模式),Adapter(适配器模式),Bridge(桥梁模式),Composite(合成模式),Decorator(装饰模式),Flyweight(享元模式),Proxy(代理模式);Command(命令模式),Interpreter(解释器模式),Visitor(访问者模式),Iterator(迭代子模式),Mediator(调停者模式),Memento(备忘录模式),Observer(观察者模式),State(状态模式),Strategy(策略模式),Template Method(模板方法模式), Chain Of Responsibility(责任链模式)。
面试被问到关于设计模式的知识时,可以拣最常用的作答,例如:
①工厂模式:工厂类可以根据条件生成不同的子类实例,这些子类有一个公共的抽象父类并且实现了相同的方法,但是这些方法针对不同的数据进行了不同的操作(多态方法)。当得到子类的实例后,开发人员可以调用基类中的方法而不必考虑到底返回的是哪一个子类的实例。
②代理模式:给一个对象提供一个代理对象,并由代理对象控制原对象的引用。实际开发中,按照使用目的的不同,代理可以分为:远程代理、虚拟代理、保护代理、Cache代理、防火墙代理、同步化代理、智能引用代理。
③适配器模式:把一个类的接口变换成客户端所期待的另一种接口,从而使原本因接口不匹配而无法在一起使用的类能够一起工作。
④除此之外,还可以讲讲上面提到的门面模式、桥梁模式、单例模式、装潢模式(Collections工具类和I/O系统中都使用装潢模式)等,反正基本原则就是拣自己最熟悉的、用得最多的作答,以免言多必失。
设计模式是一套被反复使用的、多数人知晓、经过分类编目的优秀代码设计经验的总结。特定环境下特定问题的处理方法。
1)重用设计和代码 重用设计比重用代码更有意义,自动带来代码重用
2)提高扩展性 大量使用面向接口编程,预留扩展插槽,新的功能或特性很容易加入到系统中来
3)提高灵活性 通过组合提高灵活性,可允许代码修改平稳发生,对一处修改不会波及到其他模块
4) 提高开发效率 正确使用设计模式,可以节省大量的时间
单一职责原则:一个类只做它该做的事情。(单一职责原则想表达的就是“高内聚”,写代码最终极的原则只有六个字“高内聚、低耦合”,就如同葵花宝典或辟邪剑谱的中心思想就八个字“欲练此功必先自宫”,所谓的高内聚就是一个代码模块只完成一项功能,在面向对象中,如果只让一个类完成它该做的事,而不涉及与它无关的领域就是践行了高内聚的原则,这个类就只有单一职责。我们都知道一句话叫“因为专注,所以专业”,一个对象如果承担太多的职责,那么注定它什么都做不好。这个世界上任何好的东西都有两个特征,一个是功能单一,好的相机绝对不是电视购物里面卖的那种一个机器有一百多种功能的,它基本上只能照相;另一个是模块化,好的自行车是组装车,从减震叉、刹车到变速器,所有的部件都是可以拆卸和重新组装的,好的乒乓球拍也不是成品拍,一定是底板和胶皮可以拆分和自行组装的,一个好的软件系统,它里面的每个功能模块也应该是可以轻易的拿到其他系统中使用的,这样才能实现软件复用的目标。)
开闭原则:软件实体应当对扩展开放,对修改关闭。(在理想的状态下,当我们需要为一个软件系统增加新功能时,只需要从原来的系统派生出一些新类就可以,不需要修改原来的任何一行代码。要做到开闭有两个要点:①抽象是关键,一个系统中如果没有抽象类或接口系统就没有扩展点;②封装可变性,将系统中的各种可变因素封装到一个继承结构中,如果多个可变因素混杂在一起,系统将变得复杂而换乱,如果不清楚如何封装可变性,可以参考《设计模式精解》一书中对桥梁模式的讲解的章节。)
依赖倒转原则:面向接口编程。(该原则说得直白和具体一些就是声明方法的参数类型、方法的返回类型、变量的引用类型时,尽可能使用抽象类型而不用具体类型,因为抽象类型可以被它的任何一个子类型所替代,请参考下面的里氏替换原则。)
里氏替换原则:任何时候都可以用子类型替换掉父类型。(关于里氏替换原则的描述,Barbara Liskov女士的描述比这个要复杂得多,但简单的说就是能用父类型的地方就一定能使用子类型。里氏替换原则可以检查继承关系是否合理,如果一个继承关系违背了里氏替换原则,那么这个继承关系一定是错误的,需要对代码进行重构。例如让猫继承狗,或者狗继承猫,又或者让正方形继承长方形都是错误的继承关系,因为你很容易找到违反里氏替换原则的场景。需要注意的是:子类一定是增加父类的能力而不是减少父类的能力,因为子类比父类的能力更多,把能力多的对象当成能力少的对象来用当然没有任何问题。)
接口隔离原则:接口要小而专,绝不能大而全。(臃肿的接口是对接口的污染,既然接口表示能力,那么一个接口只应该描述一种能力,接口也应该是高度内聚的。例如,琴棋书画就应该分别设计为四个接口,而不应设计成一个接口中的四个方法,因为如果设计成一个接口中的四个方法,那么这个接口很难用,毕竟琴棋书画四样都精通的人还是少数,而如果设计成四个接口,会几项就实现几个接口,这样的话每个接口被复用的可能性是很高的。Java中的接口代表能力、代表约定、代表角色,能否正确的使用接口一定是编程水平高低的重要标识。)
合成聚合复用原则:优先使用聚合或合成关系复用代码。(通过继承来复用代码是面向对象程序设计中被滥用得最多的东西,因为所有的教科书都无一例外的对继承进行了鼓吹从而误导了初学者,类与类之间简单的说有三种关系,IS-A关系、HAS-A关系、USE-A关系,分别代表继承、关联和依赖。其中,关联关系根据其关联的强度又可以进一步划分为关联、聚合和合成,但说白了都是HAS-A关系,合成聚合复用原则想表达的是优先考虑HAS-A关系而不是IS-A关系复用代码,原因嘛可以自己从百度上找到一万个理由,需要说明的是,即使在Java的API中也有不少滥用继承的例子,例如Properties类继承了Hashtable类,Stack类继承了Vector类,这些继承明显就是错误的,更好的做法是在Properties类中放置一个Hashtable类型的成员并且将其键和值都设置为字符串来存储数据,而Stack类的设计也应该是在Stack类中放一个Vector对象来存储数据。记住:任何时候都不要继承工具类,工具是可以拥有并可以使用的(HAS/USE),而不是拿来继承的。)
迪米特法则:迪米特法则又叫最少知识原则,一个对象应当对其他对象有尽可能少的了解。(迪米特法则简单的说就是如何做到“低耦合”,门面模式和调停者模式就是对迪米特法则的践行。对于门面模式可以举一个简单的例子,你去一家公司洽谈业务,你不需要了解这个公司内部是如何运作的,你甚至可以对这个公司一无所知,去的时候只需要找到公司入口处的前台美女,告诉她们你要做什么,她们会找到合适的人跟你接洽,前台的美女就是公司这个系统的门面。再复杂的系统都可以为用户提供一个简单的门面,Java Web开发中作为前端控制器的Servlet或Filter不就是一个门面吗,浏览器对服务器的运作方式一无所知,但是通过前端控制器就能够根据你的请求得到相应的服务。调停者模式也可以举一个简单的例子来说明,例如一台计算机,CPU、内存、硬盘、显卡、声卡各种设备需要相互配合才能很好的工作,但是如果这些东西都直接连接到一起,计算机的布线将异常复杂,在这种情况下,主板作为一个调停者的身份出现,它将各个设备连接在一起而不需要每个设备之间直接交换数据,这样就减小了系统的耦合度和复杂度。迪米特法则用通俗的话来将就是不要和陌生人打交道,如果真的需要,找一个自己的朋友,让他替你和陌生人打交道。)
思路:生活案例引入、技术讲解、优缺点分析、典型应用。
1、生活案例引入:送生日蛋糕:
MM们要过生日了,怎么也得表示下吧。最起码先送个蛋糕。蛋糕多种多样了。巧克力,冰淇淋,奶油等等。这都是基本的了,再加点额外的装饰,如蛋糕里放点花、放贺卡、放点干果吃着更香等等。
分析:
方案1:如果采用继承会造成大量的蛋糕子类
方案2:蛋糕作为主体,花,贺卡,果仁等是装饰者,需要时加到蛋糕上。要啥我就加啥。
技术讲解
装饰模式(别名Wrapper)是在不必改变原类文件和使用继承的情况下,动态的扩展一个对象的功能。它通过创建一个包装对象,也就是装饰来包裹真实对象,提供了比继承更具弹性的代替方案。
装饰模式一般涉及到的角色
抽象构建角色(Component):给出一个抽象的接口,以规范准备接受附加责任的对象。
具体的构建角色(ConcreteComponent):定义一个将要接受附加责任的类。
抽象的装饰角色 (Decorator):持有一个抽象构建(Component)角色的引用,并定义一个与抽象构件一致的接口。
具体的装饰角色(ConcreteDecorator):负责给构建对象“贴上”附加的责任。
3、优缺点分析
优点
1)Decorator模式与继承关系的目的都是要扩展对象的功能,但是Decorato更多的灵活性。
2)把类中的装饰功能从类中搬移出去,这样可以简化原有的类。有效地把类的核心功能和装饰功能区分开了。
3)通过使用不同的具体装饰类以及这些装饰类的排列组合,可创造出很多不同行为的组合。
缺点
这种比继承更加灵活机动的特性,也同时意味着更加多的复杂性。
装饰模式会导致设计中出现许多小类,如果过度使用,会使程序变得很复杂。
符合的设计原则:
多用组合,少用继承。利用继承设计子类的行为是在编译时静态决定的,且所有的子类都会继承到相同的行为。如能够利用组合扩展对象的行为,就可在运行时动态进行扩展。
类应设计的对扩展开放,对修改关闭。
4、典型应用
java IO中需要完成对不同输入输出源的操作,如果单纯的使用继承这一方式,无疑需要很多的类。比如说,我们操作文件需要一个类,实现文件的字节读取需要一个类,实现文件的字符读取又需要一个类…一次类推每个特定的操作都需要一个特定的类。这无疑会导致大量的IO继承类的出现。显然对于编程是很不利的。而是用装饰模式则可以很好的解决这一问题,在装饰模式中:节点流(如FileInputStream)直接与输入源交互,之后通过过滤流(FilterInputStream)进行装饰,这样获得的io对象便具有某几个的功能,很好的拓展了IO的功能
1:什么是设计模式?
就是经过实践验证的用来解决特定环境下特定问题的解决方案
2:设计模式用来干什么?
寻找合适的对象
决定对象的粒度
指定对象的接口
描述对象的实现
运用复用机制
重复使用经过实践验证的正确的,用来解决某一类问题的解决方案来达到减少
工作量、提高正确率等目的
3:什么是对象粒度
对象中方法的多少就是粒度
4:基本的Java编程设计应遵循的规则?
面向接口编程,优先使用对象组合
5:设计模式的应用范围
所能解决的特定的一类问题中
6:简述什么是单例模式,以及他解决的问题,应用的环境,解决的方案,
模式的本质
在任何时间内只有一个类实例存在的模式
需要有一个从中进行全局访问和维护某种类型数据的区域的环境下使用单例模式
解决方案就是保证一个类只有一个类实例存在
本质就是实例共用同一块内存区域
7:代码示例:单例模式的两种实现方法,并说明优缺点
public class Test{
public Test(){
}
private static Test test = new Test();
public static Test getInstance(){
return test;
}
}
public class Test{
private static Test test = null;
private Test(){
}
public static Test getInstance(){
if(test==null){
test = new Test();
}
return test;
}
}
第二种方式不需每次都创建一个类实例,而只是在第一次创建
8:简述什么是工厂模式,以及他解决的问题,应用的环境,解决的方案,模式的本质
利用工厂来解决接口选择的问题的模式
应用环境:当一个类无法预料要创建哪种类的对象或是一个类需要由子类来指定
创建的对象时,就需要用到工厂模式
解决方案:定义一个创建对象的接口,让子类来决定具体实例化哪一个类
本质就是根据不同的情况来选择不同的接口
9:代码示例:工厂模式的实现方法
public class Factory{
public static Sample creator(int which){
if (which==1){
return new SampleA();
}else if (which==2)
return new SampleB();
}
}
}
Public class MyFactory{
Public static myFactory f = null;
Public MyFactory(){
}
Public static MyFactory getInstance(){
If(f==null){
F=new MyFactory();
}
}
Public DBDAO getDAO(){
Return new DBDAOImpl();
}
}
10述什么是值对象模式,以及他解决的问题,应用的环境,解决的方案,模式的本质
用来把一组数据封装成一个对象的模式
解决问题:在远程方法的调用次数增加的时候,相关的应用程序性能将会有很大的下降
解决方案:使用值对象的时候,可以通过仅仅一次方法调用来取得整个对象,而不是使用多次方法调用以得到对象中每个域的数值
本质:就是把需要传递的多个值封装成一个对象一次性传过去
11:代码示例:值对象模式的实现方法
public class UserModel{
private String userId;
private String userName;
public void setUserId(String id){
this.userId = id;
}
public String getUserId(){
return userId;
}
public void setUserName(String name){
this.userName = name;
}
public String getUserName(){
return userName;
}
}
12:简述什么是DAO模式,以及他解决的问题,应用的环境,解决的方案,模式的本质
数据访问对象
解决问题:根据数据源不同,数据访问也不同。根据存储的类型(关系数据库、
面向对象数据库、纯文件等)和供应商实现不同,持久性存储(如数据库)的访问差别也很大。如何对存储层以外的模块屏蔽这些复杂性,以提供统一的调用存储实现。程序的分布式问题
解决方案:式将数据访问逻辑抽象为特殊的资源,也就是说将系统资源的接口从
其底层访问机制中隔离出来;通过将数据访问的调用打包,数据访问对象可以
促进对于不同数据库类型和模式的数据访问。
DAO的本质就是一层屏蔽一种变化
本质:分层,是系统组件和数据源中间的适配器。(一层屏蔽一种变化)
13:代码示例:DAO模式的实现方法
public interface CustomerDAO {
public int insertCustomer(…);
public Collection selectCustomersVO(…);
}
14:什么是开放-封闭法则(OCP)
可扩展但是不可以更改已有的模块
对扩展是开放的 对修改是封闭
15:什么是替换法则(LSP)
使用指向基类(超类)的引用的函数,必须能够在不知道具体派生类(子类)对象
类型的情况下使用
16:如何综合使用我们学过的设计模式来构建合理的应用程序结构
是采用接口进行隔离,然后同时暴露值对象和工厂类,如果是需要数据存储的功能,又会通过DAO 模式去与数据存储层交互。
17:构建常用的合理的Java应用包结构
Ui(表现层)
business–factory,ebi,ebo
dao–factory,dao,impl