常见设计模式还有这些

简介: 《基础系列》

说说你所熟悉或听说过的设计模式以及你对设计模式的看法

答:在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(责任链模式)。

所谓设计模式,就是一套被反复使用的代码设计经验的总结(情境中一个问题经过证实的一个解决方案)。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式使人们可以更加简单方便的复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。

【补充】设计模式并不是像某些地方吹嘘的那样是遥不可及的编程理念,说白了设计模式就是对面向对象的编程原则的实践,面向对象的编程原则包括:

单一职责原则:一个类只做它该做的事情。(单一职责原则想表达的就是“高内聚”,写代码最终极的原则只有六个字“高内聚、低耦合”,就如同葵花宝典或辟邪剑谱的中心思想就八个字“欲练此功必先自宫”,所谓的高内聚就是一个代码模块只完成一项功能,在面向对象中,如果只让一个类完成它该做的事,而不涉及与它无关的领域就是践行了高内聚的原则,这个类就只有单一职责。我们都知道一句话叫“因为专注,所以专业”,一个对象如果承担太多的职责,那么注定它什么都做不好。这个世界上任何好的东西都有两个特征,一个是功能单一,好的相机绝对不是电视购物里面卖的那种一个机器有一百多种功能的,它基本上只能照相;另一个是模块化,好的自行车是组装车,从减震叉、刹车到变速器,所有的部件都是可以拆卸和重新组装的,好的乒乓球拍也不是成品拍,一定是底板和胶皮可以拆分和自行组装的,一个好的软件系统,它里面的每个功能模块也应该是可以轻易的拿到其他系统中使用的,这样才能实现软件复用的目标。)

开闭原则:软件实体应当对扩展开放,对修改关闭。(在理想的状态下,当我们需要为一个软件系统增加新功能时,只需要从原来的系统派生出一些新类就可以,不需要修改原来的任何一行代码。要做到开闭有两个要点:①抽象是关键,一个系统中如果没有抽象类或接口系统就没有扩展点;②封装可变性,将系统中的各种可变因素封装到一个继承结构中,如果多个可变因素混杂在一起,系统将变得复杂而换乱,如果不清楚如何封装可变性,可以参考《设计模式精解》一书中对桥梁模式的讲解的章节。)

依赖倒转原则:面向接口编程。(该原则说得直白和具体一些就是声明方法的参数类型、方法的返回类型、变量的引用类型时,尽可能使用抽象类型而不用具体类型,因为抽象类型可以被它的任何一个子类型所替代,请参考下面的里氏替换原则。)

里氏替换原则:任何时候都可以用子类型替换掉父类型。(关于里氏替换原则的描述,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、内存、硬盘、显卡、声卡各种设备需要相互配合才能很好的工作,但是如果这些东西都直接连接到一起,计算机的布线将异常复杂,在这种情况下,主板作为一个调停者的身份出现,它将各个设备连接在一起而不需要每个设备之间直接交换数据,这样就减小了系统的耦合度和复杂度。迪米特法则用通俗的话来将就是不要和陌生人打交道,如果真的需要,找一个自己的朋友,让他替你和陌生人打交道。)

 7.png

6.png


Java企业级开发中常用的设计模式有哪些?

答: 按照分层开发的观点,可以将应用划分为:表示层、业务逻辑层和持久层,每一层都有属于自己类别的设计模式。

表示层设计模式:

1) Interceptor Filter:拦截过滤器,提供请求预处理和后处理的方案,可以对请求和响应进行过滤。/p>

2) Front Controller:通过中央控制器提供请求管理和处理,管理内容读取、安全性、视图管理和导航等功能。Struts 2中的StrutsPrepareAndExecuteFilter、Spring MVC中的DispatcherServlet都是前端控制器,后者如下图所示:

5.png

3) View Helper:视图帮助器,负责将显示逻辑和业务逻辑分开。显示的部分放在视图组件中,业务逻辑代码放在帮助器中,典型的功能是内容读取、验证与适配。

4) Composite View:复合视图。

业务逻辑层设计模式:

1) Business Delegate:业务委托,减少表示层和业务逻辑层之间的耦合。

2) Value Object:值对象,解决层之间交换数据的开销问题。

3) Session Façade:会话门面,隐藏业务逻辑组件的细节,集中工作流程。

4) Value Object Assembler:灵活的组装不同的值对象

5) Value List Handler:提供执行查询和处理结果的解决方案,还可以缓存查询结果,从而达到提升性能的目的。

6) Service Locator:服务定位器,可以查找、创建和定位服务工厂,封装其实现细节,减少复杂性,提供单个控制点,通过缓存提高性能。

持久层设计模式:

Data Access Object:数据访问对象,以面向对象的方式完成对数据的增删改查。

【补充】如果想深入的了解Java企业级应用的设计模式和架构模式,可以参考这些书籍: 《Pro Java EE Spring Patterns》、《POJO in Action》、《Patterns of Enterprise Application Architecture》。


你在开发中都用到了那些设计模式?用在什么场合?

答:面试被问到关于设计模式的知识时,可以拣最常用的作答,例如:

1) 工厂模式:工厂类可以根据条件生成不同的子类实例,这些子类有一个公共的抽象父类并且实现了相同的方法,但是这些方法针对不同的数据进行了不同的操作(多态方法)。当得到子类的实例后,开发人员可以调用基类中的方法而不必考虑到底返回的是哪一个子类的实例。

2) 代理模式:给一个对象提供一个代理对象,并由代理对象控制原对象的引用。实际开发中,按照使用目的的不同,代理可以分为:远程代理、虚拟代理、保护代理、Cache代理、防火墙代理、同步化代理、智能引用代理。

3) 适配器模式:把一个类的接口变换成客户端所期待的另一种接口,从而使原本因接口不匹配而无法在一起使用的类能够一起工作。

4) 模板方法模式:提供一个抽象类,将部分逻辑以具体方法或构造器的形式实现,然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法(多态实现),从而实现不同的业务逻辑。

除此之外,还可以讲讲上面提到的门面模式、桥梁模式、单例模式、装潢模式(Collections工具类里面的synchronizedXXX方法把一个线程不安全的容器变成线程安全容器就是对装潢模式的应用,而Java IO里面的过滤流(有的翻译成处理流)也是应用装潢模式的经典例子)等,反正原则就是拣自己最熟悉的用得最多的作答,以免言多必失。


什么是设计模式,设计模式的作用。

设计模式是一套被反复使用的、多数人知晓、经过分类编目的优秀代码设计经验的总结。特定环境下特定问题的处理方法。

1)重用设计和代码 重用设计比重用代码更有意义,自动带来代码重用

2)提高扩展性 大量使用面向接口编程,预留扩展插槽,新的功能或特性很容易加入到系统中来

3)提高灵活性 通过组合提高灵活性,可允许代码修改平稳发生,对一处修改不会波及到其他模块

4) 提高开发效率 正确使用设计模式,可以节省大量的时间


23种经典设计模式都有哪些,如何分类。

4.png 

3.png



写出简单工厂模式的示例代码


packagecom.bjsxt;

 

publicclassSimpleFactory {

publicstaticProduct createProduct(String pname){

Product product=null;

if("p1".equals(pname)){

product = newProduct();

}elseif("p2".equals(pname)){

product = newProduct();

}elseif("pn".equals(pname)){

product = newProduct();

}

returnproduct;

}

}

基本原理:由一个工厂类根据传入的参数(一般是字符串参数),动态决定应该创建哪一个产品子类(这些产品子类继承自同一个父类或接口)的实例,并以父类形式返回

优点:客户端不负责对象的创建,而是由专门的工厂类完成;客户端只负责对象的调用,实现了创建和调用的分离,降低了客户端代码的难度;

缺点:如果增加和减少产品子类,需要修改简单工厂类,违背了开闭原则;如果产品子类过多,会导致工厂类非常的庞大,违反了高内聚原则,不利于后期维护

430.请对你所熟悉的一个设计模式进行介绍

分析:建议挑选有一定技术难度,并且在实际开发中应用较多的设计模式。可以挑选装饰模式和动态代理模式。此处挑选动态代理设计模式。

讲解思路:生活案例引入、技术讲解、优缺点分析、典型应用。

1、生活案例引入:送生日蛋糕:

MM们要过生日了,怎么也得表示下吧。最起码先送个蛋糕。蛋糕多种多样了。巧克力,冰淇淋,奶油等等。这都是基本的了,再加点额外的装饰,如蛋糕里放点花、放贺卡、放点干果吃着更香等等。

分析:

方案1:如果采用继承会造成大量的蛋糕子类

方案2:蛋糕作为主体,花,贺卡,果仁等是装饰者,需要时加到蛋糕上。要啥我就加啥。

技术讲解

装饰模式(别名Wrapper)是在不必改变原类文件和使用继承的情况下,动态的扩展一个对象的功能。它通过创建一个包装对象,也就是装饰来包裹真实对象,提供了比继承更具弹性的代替方案。

装饰模式一般涉及到的角色

抽象构建角色(Component):给出一个抽象的接口,以规范准备接受附加责任的对象。

具体的构建角色(ConcreteComponent):定义一个将要接受附加责任的类。

抽象的装饰角色 (Decorator):持有一个抽象构建(Component)角色的引用,并定义一个与抽象构件一致的接口。

具体的装饰角色(ConcreteDecorator):负责给构建对象“贴上”附加的责任。

2.png

3、优缺点分析

优点

1)Decorator模式与继承关系的目的都是要扩展对象的功能,但是Decorato更多的灵活性。

2)把类中的装饰功能从类中搬移出去,这样可以简化原有的类。有效地把类的核心功能和装饰功能区分开了。

3)通过使用不同的具体装饰类以及这些装饰类的排列组合,可创造出很多不同行为的组合。

缺点

这种比继承更加灵活机动的特性,也同时意味着更加多的复杂性。

装饰模式会导致设计中出现许多小类,如果过度使用,会使程序变得很复杂。

符合的设计原则:

多用组合,少用继承。利用继承设计子类的行为是在编译时静态决定的,且所有的子类都会继承到相同的行为。如能够利用组合扩展对象的行为,就可在运行时动态进行扩展。

类应设计的对扩展开放,对修改关闭。

4、典型应用

java IO中需要完成对不同输入输出源的操作,如果单纯的使用继承这一方式,无疑需要很多的类。比如说,我们操作文件需要一个类,实现文件的字节读取需要一个类,实现文件的字符读取又需要一个类....一次类推每个特定的操作都需要一个特定的类。这无疑会导致大量的IO继承类的出现。显然对于编程是很不利的。而是用装饰模式则可以很好的解决这一问题,在装饰模式中:节点流(如FileInputStream)直接与输入源交互,之后通过过滤流(FilterInputStream)进行装饰,这样获得的io对象便具有某几个的功能,很好的拓展了IO的功能。

1.png

相关文章
|
7月前
|
设计模式 算法 关系型数据库
23种设计模式总结
23种设计模式总结
43 0
|
10月前
|
设计模式 程序员
设计模式 | 模版方法
设计模式 | 模版方法
58 0
|
7月前
|
设计模式 安全 Java
设计模式~单列模式-01
单列模式 1、饿汉式 2、懒汉式(lazy loading) 3、双重检测 4、静态内部类
21 0
|
9月前
|
设计模式 关系型数据库
设计模式介绍
设计模式介绍
|
9月前
|
设计模式 算法 程序员
2023-6-9-一天一种设计模式
2023-6-9-一天一种设计模式
54 0
|
9月前
|
设计模式 容器
2022-9-19-C++各种设计模式的简单总结
2022-9-19-C++各种设计模式的简单总结
48 0
|
10月前
|
设计模式 算法 数据库连接
|
11月前
|
设计模式 存储 监控
设计模式(C++版)
看懂UML类图和时序图30分钟学会UML类图设计原则单一职责原则定义:单一职责原则,所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变,那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。bad case:IPhone类承担了协议管理(Dial、HangUp)、数据传送(Chat)。good case:里式替换原则定义:里氏代换原则(Liskov 
35910 13
设计模式(C++版)
|
设计模式 Java
|
设计模式 算法 安全
11种常用的设计模式
有这么一个很形象的比喻,把写代码比作是建房子,代码比作是砖瓦、一个完整的系统就好比是一栋高楼大厦、程序员无疑就好比是建(ban)筑(zhuan)工,这些很表面的东西我们都可以很形象深刻的理解,其实要设计和开发一个系统远远不只这些东西,深挖表象之下隐藏着的细节往往才是灵魂所在,诸如:算法和数据结构、框架、设计模式等,设计模式是一个虚幻的抽象的概念,好比建造房子时的设计理念方案一样,一个软件系统扩展性、可维护性以及稳定健壮性如何,很大程度上取决于设计模式。
11种常用的设计模式