设计模式概述

目录

设计模式概述

设计模式的分类

根据模式的目的,可分为:

根据模式的范围,可分为:

GoF的23种模式一览表

反模式

项目管理方面:

设计方面:

编程方面:

方法方面:

结构管理方面:

---

设计模式概述

GoF四人帮提出了设计模式的概念.

模式:模式是在特定环境下人们解决某类重复出现问题的一套成功或有效的解决方案.

软件模式:软件模式即软件开发的总体指导思路或参照样板;软件模式并非仅限于设计模式,还包括架构模式,分析模式和过程模式等.

软件模式的基本结构:问题描述,前提条件(环境或约束条件),解法和效果.

设计模式:设计模式是在特定环境下为解决某一通用软件设计问题提供的一套定制的解决方案,该方案描述了对象和类之间的相互作用.

设计模式的基本要素:模式名称,问题,目的,解决方案,效果,实例代码和相关设计模式.

设计模式的分类

• 根据目的分类
• 根据范围(即模式主要用于处理类之间的关系还是处理对象之间的关系)分类

根据模式的目的,可分为:

• 创建型模式,主要用于创建对象,GoF提供了5种.
• 结构型模式,主要用于处理类或对象的组合,GoF提供了7种.
• 行为型模式,主要用于描述类或对象怎样交互和怎样分配职责,GoF提供了11种.

根据模式的范围,可分为:

• 类模式,处理类和子类之间的关系.关系编译时确定,是一种静态关系.
• 对象模式,处理对象之间的关系,关系在运行时变化,更具动态性.

GoF的23种模式一览表

范围/目的	创建型模式	结构型模式	行为型模式
类模式	工厂方法模式	(类)适配器模式	解释器模式 模板方法模式
对象模式	抽象工厂模式 建造者模式 原型模式 单例模式	(对象)适配器模式 桥接模式 组合模式 装饰模式 外观模式 享元模式 代理模式	职责链模式 命令模式 迭代器模式 中介者模式 备忘录模式 观察者模式 状态模式 策略模式 访问者模式

 

JDK中使用了哪些设计模式?列举几个

• AWT和JDBC使用了桥接模式
• InputStreamReader和OutputStreamWriter使用了适配器模式
• IO包中许多类使用了装饰者模式
• 基本类型包装类使用了享元模式
• Proxy使用了代理模式
• StringBuilder,StringBuffer和PreparedStatement使用了建造者模式
• Object.clone()使用了原型模式
• Filter使用了责任链模式
• Runable使用了命令模式
• Iterator使用了迭代器模式和状态模式
• ......等

反模式

反模式:是指用来解决问题的带有共同性的不良方法.它们已经经过研究并分类,以防止日后重蹈覆辙,并能在研发尚未投产时辨认出来.

项目管理方面:

• 水中望月:向人演示还没有实现的功能看上去会是什么样的.
• 软件膨胀:随着版本的升级,软件越来越消耗系统资源.
• 不良管理:在未对主题有足够认识的情况下管理一个专案.

设计方面:

• 反抽象:需要的功能并不暴露给用户，导致用户要在较高层次重新实现一些功能.
• 四不像:往往一个设计模型可以暴露不同的接口给用户，不同的接口表现了模型的不同方面。然而把不同方面的功能混在一起是常见的不良设计.
• 乱麻球:系统没有可辨认的结构，就像一团乱麻一样.
• 万应灵:一个对象了解的东西太多，或者要做太多的事情，就好像无所不能一样.
• 屠龙术:没有必要的复杂设计.
• 竞争危害:缺乏预见事件以不同顺序发生的后果.
• 万能类:在一个类的设计中,聚集了太多的函数.
• 吵闹鬼:建立某对象的目的只是为了传送讯息给其它的物件.
• 溜溜问题:因结构（例如继承）极度破碎冗长,而必须花费极大力气来了解它.

编程方面:

• 硬编码:或称写死.在实现某系统用途上设死该系统的运作环境.
• 紊乱代码:几乎无法理解的结构,特别是因为代码结构的滥用.
• 超布尔逻辑:不必要的比较,或是过于抽象的布尔计算.
• 无用的例外处理:插入了条件去防止运行时异常,但确在条件为false时又throw.

方法方面:

• 剪贴编程:宁愿拷贝(并修改)现存代码而非创造通用的解决方案.
• 反重构:"移除功能性并以注解取代"的过程.
• 金锤子(银弹):假设个人偏好的解决方案是世界通用.
• 掩耳盗铃:假设一个已知的bug不会出现.
• 不成熟的优化:根据不足信息优化.
• 重新造个轮子:拒绝采纳现有的解决方案,重写一个.
• 造了个正方形的轮子:当一个优秀的方案存在时,创造一个蹩脚解决方案.

结构管理方面:

• 相依性地狱:由于需要的产品版本不匹配造成的种种问题,特别是在UNIX/Linux.
• DLL地狱:由于动态连接库的版本,存在与否,和重复所造成的种种问题,特别是在Microsoft Windows.
• JAR地狱:源自于不同版本或位址的JAR档案所造成的问题,常造成加载模组的欠缺.
• 延伸冲突:源自于Mac OS不同的延伸尝试修补相同的系统部分.

一些组织方面的反模式:

• 分析麻痹症:项目分析过程已经长得不成比例,却听之任之.
• 摇钱树项目:或者叫吃老本,一件有利可图的产品让新产品固步自封.
• 永远革命:总是要不停地不计代价将现有系统移植到新的环境.
• 军队式管理:没有容忍异议的空间.
• Scope creep:允许专案范围增长而没有适当控制.