头几天闲着，睡觉前就重新翻了一下之前看过的一本书《设计模式解析》（原来看的是英文版，这次看的是中文版的，翻译的有点...看起来挺累～_～。大家如果看，还是选原版的吧）。总觉得看到两位作者（Alan Shalloway; James R.Trott ）好像试图推荐一种自己的方法论：基于模式进行分析和设计。想来想去，有点自己的想法，写出来，欢迎讨论。
【设计模式是一个工具】
首先说明，本人设计经验不是很多，而且一般也只是局限于模块级的，所以，以下内容全部是乱弹琴了。
设计模式是一个工具，而且仅仅是个工具。为什么这么说呢？个人觉得，我们一般进行设计的时候，最关键的三点应该是：需求分析结果、基本的OO设计原则和特定领域的经验（例如行业解决方案等）。例如我举这么一个例子，开闭原则（对扩展开放、对修改关闭）大家应该是很熟了，所以经常我们在设计一个模型层次的时候，这个时候脑子中哪来的什么设计模式啊，我们可能只想着将抽象层面的概念暴露出来，把实现层面的东西尽量隐藏在模块内部，而且也希望用户来扩展这种模型。所以很自然的做了模型的分层，上层是抽象层接口，对外暴露，同时暴露的还有一些公共抽象基类，供其他人扩展模型使用；下层是扩展实现，不需要对外暴露。
到这里，相当于我们设计的模块的模型已经基本固定了，现在就是如何实现这种设计初衷了。这个时候想到一个重要的工具，那就是设计模式。例如我们的模型分为了抽象接口层和实现层，我们如何支持既联系又独立变化呢？Bridge。 例如我们的模型看起来是树状的，怎么来封装呢？Composite。 例如我们的模型之上可能又很多操作需要支持，我们想把这种操作和数据模型本身做松耦合拆分？Visitor。我们想把模型的构建和模型类类型定义做拆分，因为我们可能觉得用户来构造这种数据模型节点可能很负责？Factory、Builder。...我想这类的问题有很多，无非就是在具体实现设计，用设计模式做个工具而已。而我们前面的需求分析、基本OO原则进行模块整体处理等等，都是设计模式层面之上的东西。
说到这里，我一直觉得设计模式就是个工具，而且是个后期实现设计的工具，不是前期主导设计的工具。
【基于模式进行分析和思考】
主要有如下几个疑问：
1、设计模式的过早引入，会不会导致开发者过多的关注于实现了呢？？？我们知道，如果进行模块级别或者更高级别的代码框架编写，脑子里过早过多的闯入了实现细节，那不是会导致基于实现细节的思考来写抽象层面的框架代码？？？这样，代码还有核心的框架吗？？？
2、无容置疑，设计模式含有使用场景的经典浓缩，我们的需求肯定和这些场景有重叠的地方。但是，我们在整体考虑一个模块层面的设计的时候，应该更多的是由基本设计原则来确定，希望这个模块长成什么样子，而不是去这个模块怎么长成这个样子。这可能类似于一个女的去整容，她对自己的需求整理的半天，同时又不想违反基本规则挑战审美极限，最终去定下来：胸不要太大，胸形漂亮点，想明星***。接着医生进来了，用一些工具或者药物帮她实现了。 哈哈 ^_^
3、让设计模式更早一点的进入分析和设计，是不是需要对相应人员要求太高呢？既能借鉴设计模式中的场景来帮助思考，又能避免过于面向实现细节来设计。当然，高手是狂多的～_～
4、是否很容易造成设计模式的过度使用呢？导致代码框架在设计模式不自然的用法的基础之上机械堆砌起来的，对同事提出了很大的挑战呢....同时，也有可能将很大一部分注意力转移到了如何使用设计模式上了，带着有色眼睛去看需求，满眼都是设计模式...
PS：以上说的很多是个人一些疑问，绝对没有贬低设计模式的意思。欢迎高手前来讨论 ~_~
本博客中的所有文章、随笔除了标题中含有引用或者转载字样的，其他均为原创。转载请注明出处，谢谢！