如何理解 GoF 的设计模式

作者:kidneyball
链接:https://www.zhihu.com/question/23757906/answer/25616658
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

首先离题一下说点虚的

其实GoF的《设计模式》一书,一共有三个层面的内容:

  1. 指出编程开发活动中存在模式,提出总结设计模式需要关注的四要素 “名称-问题-解决方案-效果“ ,并给出描述一套模式的格式模板。
  2. 提出了面向对象开发中”针对接口编程优于针对实现编程”,”组合优于继承”的总体设计思路
  3. 选取了现实开发中基于上述设计思路所形成的23种常见设计模式作为例子详细描述

虽然第3点包括的多个具体的设计模式实例占据了最多的篇幅,但事实上第1,2点才是纲。实际上《设计模式》一书最划时代的意义,在于第1点。在此之后,出现了以设计模式的格式来组织内容的《分析模式》,《企业架构模式》,《企业集成模式》,《xUnit测试模式》,《重构》等等质量颇高的书籍

在书中有一段我认为非常重要但很容易被忽略的话

本书中涉及的设计模式并不描述新的或未经证实的设计,我们只收录那些在不同系统中多次使用过的成功设计

Read the rest

设计模式总结

紧跟上回 代码大全读后感——控制软件复杂性是软件构造过程的第一要务,我们知道软件开发是一个复杂的心理和智力活动。软件是一个工程产物,做工程其实就是在多、快、好、省四个字之间做折中和权衡。多要求功能多,快要求速度快,好要求实现质量高,省要求投入成本少。在定义清晰的软件中,功能并不是实现地越多越好,甚至力求精简,所以相对地,我们需要更多地考虑快、好、省三点。

通向快、好、省的道路

如何做到快?

  1. 建立一个高效、有经验的团队
  2. 复用已经开发过的功能模块,或者是内部开发,或者是社区中的开源实现,或者是可购买的商用软件

如何做到好?

  1. 在早期建立良好的架构,尽量减少较高层次的错误。
  2. 引入常规的代码审核流程,尽量减少编码引入的问题。
  3. 定义完善的测试过程,尽量减少遗留到维护阶段的问题。
  4. 在后期维护时,尽量做扩展,而不需要修改之前的代码导致引入新问题。出现问题从根本上解决,而不是临时修补。

软件的挑战在于虚拟,常常只有在做完时才知道是否可行,所以如果需要尽量借鉴之前的可行经验

如何做到省?

  1. 定义清晰的需求,不在开始做需求性价比很低的功能点。
  2. 实事求是,不做过度的设计,不做过早的优化。
  3. 合适的架构,提升模块、代码复用程度。

软件行业技术发展日新月异,但是由于软件开发中关系到人的心理和智力属性,而人在这两点上变化很… Read the rest

GoF 设计模式的分类

作者:Joash
链接:https://www.zhihu.com/question/23757906/answer/96776295
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

对于java程序员来说,这个问题个人感觉应该去jdk,经典开源框架中寻找答案。之前写过一篇博客:一句话总结java23种设计模式 下面是部分内容,本人菜鸟一只望轻喷。。

设计模式的六大原则

  • 开闭原则(Open Close Principle):对扩展开放对修改关闭
  • 里氏代换原则(Liskov Substitution Principle):父类出现的地方,子类也可出现
  • 依赖倒转原则(Dependence Inversion Principle):依赖抽象而不依赖具体
  • 接口隔离原则(Interface Segregation Principle):多个隔离的接口,比使用单个接口要好
  • 迪米特法则(最少知道原则)(Demeter Principle):最少知道原则。一个实体应当尽量少的与其他实体之间发生相互作用
  • 合成复用原则(Composite Reuse Principle):尽量使用合成/聚合的方式,而不是使用继承。

创建型

Read the rest