如何理解 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

代码大全读后感——控制软件复杂性是软件构造过程的第一要务

为什么软件会趋于复杂

  1. 处理的任务本质复杂。软件的作用在于和现实交互,完成现实世界的任务。但是现实世界本身有其复杂性,实体、流程、规则、输入、输出、运行平台等都有其复杂性。软件中必须有对应现实中各部分的组成部分,和现实中各个实体对应后,软件会趋于复杂。同时,现实中的实体定义边界常常较为模糊,而软件是需要精确定义的,从模糊到精确,会有一定的信息衰减。
  2. 人脑理解复杂问题的局限性。人脑思考时无法同时容纳超过两位数的实体,导致人脑无法同时兼顾全局和细节。软件本质的复杂却要求人脑能同时顾及各种实体和关系,和人脑局限性相矛盾。
  3. 非直接可见导致的复杂。软件中大多数组成部分是不可见的,最终展现形式是代码和可执行的程序。其虚拟性,导致了解其整体需要分析阅读代码才能了解各部分。一个软件代码量越多,完全掌握软件所需的成本就越大。当软件代码量达到一定数量级后,团队中甚至没有任何人能完全掌握所有代码。
  4. 团队开发导致的复杂性。如果软件全部为一个人开发,开发人员对需求、设计、编码整个过程都了如指掌,则软件复杂性将不是问题。但是,典型软件是团队协作的产物,不同人介入的阶段不一样,团队协作的整体一致理解的达成较为困难。
  5. 未来视角的复杂性。软件生命周期长,
Read the rest