Skip to content

Latest commit

 

History

History
58 lines (43 loc) · 4.22 KB

DEAL-WITH_DESIGN_PATTERNS.md

File metadata and controls

58 lines (43 loc) · 4.22 KB

模式

模式是在某种情境下,针对某种问题的某种解决方案。

  • 情境:情境就是应用某个模式的情况。这应该是会不断出现的情况。
  • 问题:就是你想在某情境下达到的目标,但也可以是某情境下的约束。
  • 解决方案:就是一个通用的设计,用来约束、达到目标。

如果你发现在自己处于某个情境下,面对所欲达到的目标被一群约束影响着的问题,然而你能够应用某个设计, 克服这些约束并达到该目标,将你领向某个解决方案。

模式类目

模式类目描述某个模式的意图、动机、可能应用该模式的地方、解决方案的设计以及使用后果(好的或坏的)。

第一个也是最重要的一个设计类目是《设计模式:可复用面向对象软件的基础》

模式分类 1

  • 创建型:创建型模式涉及到将对象实例化,这类模式都提供一个方法,将客户从所需要实例化的对象中解耦。
  • 行为型:涉及到类和对象如何交互及分配职责。
  • 结构型:把类或者对象组合到更大的结构中。

模式分类 2

  • 类模式:描述类之间的关系如何通过继承定义。类模式的关系是在编译时建立的。
  • 对象模式:描述对象之间的关系,而且主要是利用组合定义。对象模式的关系通常是在运行时建立,而且更加动态、更有弹性。

用模式思考

  • 保持简单,不要认为:如果没有使用模式解决某个问题,就不是经验丰富的开发人员
  • 设计模式非万灵丹。要使用模式,需要考虑到模式对你的设计中其他部分造成的后果
  • 知道何时需要模式:如果在设计的时候,确定在设计中科院采用某个模式解决某个问题,就使用这个模式;如果有更坚定的解决方案,在决定使用模式之前应该先考虑这个方案
  • 重构的时间就是模式的时间:重构就是通过改变你的代码来改进它的组织方式的过程。目标是改善其结构而不是改变其行为。可以重新检查设计来看看是否能够利用模式让它拥有更好的结构
  • 拿掉你所不需要的,不要害怕讲一个设计模式从你的设计中删除。当你的系统变得非常复杂,而且不需要预留任何弹性的时候,换句话说,也就是当一个较简单的解决方案比使用模式更适合的时候,就不要使用模式
  • 如果现在不需要模式,就别用模式。使用模式会将你的系统越搞越复杂,很可能会永远都不会需要它。

将你的思维集中在设计本身而不是在模式上。只有在真正需要时才使用模式。有些时候,简单的方式就行得通,那么就别用模式。

模式使用者心智

  • 初学者心智:我要为 “hello word” 找个模式。到处使用模式
  • 中级人员心智:或许这里我需要一个单例模式。能够分辨何时需要模式,何时不需要
  • 悟道者心智:在这里采用装饰着模式相当自然。能够看到模式在何处能够自然融入,不会让模式的知识过度影响设计的决策

模式类型

  • 架构模式:用来建立生机勃勃的建筑、城镇和城市的架构
  • 应用模式:是建立系统级架构的模式,许多多层的架构都属于这一类目
  • 领域特定模式:关注特定领域的问题,例如并发系统或实时系统
  • 业务流程模式:描述业务、顾客和数据之间的交互,此种模式能够处理如“如何有效决策并沟通决策”之类的问题
  • 组织模式:描述了人类组织的结构及实践。目前大多数努力聚焦于制造或支持软件的组织
  • 用户界面设计模式:致力于解决设计交互软件时的问题

反模式

反模式告诉你如何采用一个不好打解决方案解决一个问题。

  • 反模式告诉我们为什么不好打解决方案会有吸引力
  • 反模式告诉我们为什么这个解决方案从长远看会造成不好的影响
  • 反模式建议你改用其他的模式以提供更好的解决方案

反模式看起来总像是一个好的解决方案,但是当它真正被采用后,就会带来麻烦

有许多类型的反模式:开发反模式、OO 反模式、组织反模式、领域特定反模式