本文预览：
- 设计模式简介
- 软件设计固有的复杂性
- 如何解决复杂性
- 软件设计的目标
- 设计模式六大原则
- 组件协作模式
- 模板方法
- 策略模式
- 观察者模式
- 装饰模式
- 桥模式
设计模式简介
设计模式
历史性著作《设计模式:可复用面向对象软 件的基础》一书中 述了23种经典面向对象 设计模式,创立了模式在软件设计中的地位。GoF(GoF is simple of Gang of Four)这本书名声有多大，几乎无人不知无人不晓，堪称《九阴真经》心法，既然是心法，那可不是一朝一夕就可练成的。在软件设计界，此书几乎人手一本，但是，然并卵，此书闲置率也堪称绝世经典，即使此书读了上百遍，依然不能在实际应用中有所建树，这就是心法。
软件设计固有的复杂性
建筑商从来不会去想给一栋已建好的100层高的 楼房底下再新修一个小地下室——这样做花费极 大而且注定要失败。然而令人惊奇的是,软件系统的用户在要求作出类似改变时却不会仔细考虑, 而且他们认为这只是需要简单编程的事。
——Object-Oriented Analysis and Design with Applications
软件设计为什么那么复杂，很多时候项目经理说要添加一个需求，程序说加不了，于是经理说，不就是改两行代码吗。其实，在很多情况下相当于，我盖好了一栋大楼
经理：我要加一个地下室。
工程师：加不了。
经理：不就是加一个地下室吗？
显然没有这么无知的经理，但是在软件领域，确实是有这么无知的产品经理，因为不是所有的人都懂得软件设计，但是几乎所有的人都知道怎么盖大楼。
那么软件设计为什么如此复杂？
根本原因在于变化。一是，客户需求反复无常，一会这样一会那样，刚盖好三层楼拆掉重盖也不是没有可能。二是，技术团队变化，资本主义社会不再像美好的社会主义，市场经济下，人才流动是常常发生的事，总工程师带着小弟去创业了，如果之前没有完善的文档，那么，谁来接手这个烫手的山芋。三是，技术平台变化，十年前谁能想到，我们现在人手一部智能手机，原来花了几百万开发的跑在windows上的程序能不能跑在iphone上？四是，市场环境变化，妈了个蛋的，谁曾想到，半年前确定的开发一套造自行车的ERP系统，今天你说我要转行去做房地产，把原来的系统改成房地产ERP系统。
变化，这才是软件设计领域要解决的最头等的大事，试想，盖好的大楼，谁会拆了加一个地下室，但是软件设计领域会，一个好的架构，不止能加地下室，还能把大楼改造成钢铁侠(纯扯淡)。
如何解决复杂性
面对一个一脸懵逼的问题，我们如何面对：
- 分解
- 抽象
分解：一个复杂的问题，人类如何面对，分解成一个个小的，简单的问题，逐个击破。这就是人类解决问题最基本的方法。
抽象：其实一切高于自然的东西都是抽象出来的，社会、法律、制度......这是人类统治世界的终极大招。由于不能掌握全部的复杂对象,我们选择忽视它的非本质细节, 而去处理泛化和理想化了的对象模型。
这两种方法是通用方法，研究数学也是用到这两种方法，一种是泛化(抽象)，一种是特化(分解)。
软件设计的目标
什么是好的软件设计，软件设计的金科玉律：复用
设计模式六大原则
六大设计原则是心法的心法，所有设计模式都是遵循这六大原则演变来的，虽然晦涩难懂，但是既然是心法的心法，即使不懂怎么用，背出来装装逼也是可以的。
-
依赖倒置原则
-
高层模块(稳定)不应依赖低层(变化)模块，二者都应依赖于抽象(稳定)。
-
抽象(稳定)不应依赖实现细节(变化)，实现细节应该依赖抽象(稳定)。
-
开放封闭原则
- 对扩展开放，对更改封闭
- 类模块应该是可扩展的，但是不可修改
-
单一职责原则
-
一个类应该只有一个引起它变化的原因
-
变化的方向隐含着类的责任
-
Liskov替换原则
-
子类必须能够替换它们的基类(IS-A)
-
继承表达类型抽象
-
接口隔离原则
-
不应该强迫客户程序依赖它们不用的方法
-
接口应该小而完备
-
优先使用对象组合,而不是类继承
-
继承在某种程度上破坏了封装性,子类父类耦合度高
-
而对象组合则只要求被组合的对象具有良好定义的接口,耦合 度低
重构获得模式
看完这六大原则，不管是不是理解了，是不是在写代码的时候直接就可以用上了呢？一副都起开，老衲要开始装逼了的样子。然而并不是，设计模式的应用不宜先入为主,一上来就使用设计模式是对设计 模式的最大误用。没有一步到位的设计模式。敏捷软件开发实践提倡的“Refactoring to Patterns”是目前普遍公认的最好的使用设计模式的方法。
现代软件设计的特征是“需求的频繁变化”。设计模式的要点是 “寻找变化点,然后在变化点处应用设计模式,从而来更好地应对 需求的变化”.“什么时候、什么地点应用设计模式”比“理解设计 模式结构本身”更为重要。
我相信看到这的你，是懵逼的，说了这么久，设计模式不是一样来就用的(除非你对业务模型非常了解，和之前做过的项目一样的)，而是通过重构。
关于重构的经典书籍
重构关键技法
- 静态 动态
- 早绑定 晚绑定
- 继承 组合
- 编译时依赖 运行时依赖
- 紧耦合 松耦合
组件协作模式
现代软件专业分工后的第一个结果是框架与应用程序的划分，组件协作模式通过晚绑定，来实现框架与应用程序之间的松耦合，是二者之间协作时的常用模式。
典型模式
- 模板方法
- 策略模式
- 观察者模式
关于这些模式的代码演示和解释见下面链接:
模板方法
策略模式
观察者模式
这几篇是我读过的算是解释的非常清楚简介的文章了，代码有些是用java写的，可能作者比较懒，直接抄的《大话设计模式》，自己实际写一遍还是很有收获的。
网友评论