鉴于比较的方式看设计模式

长期以来，时断时续的读设计模式相关的书，也稍微积累了一点点知识，但是仅仅如此却远远不够。一无实践，二无理论。借口一堆，能力无存啊！

 

最近一段时间再次拿起这些书，反复品味里面的一点点差别，发现这些差别却也正是实践中的入手点。市面上有很多很多跟设计模式相关的好书，里面不乏非常有用的例子，并且是以实际情况作比，但是如果在这个时候是以一种生搬硬套的方式，套用一个场景的模式，却反倒会起一些模式滥用，反模式的作用。

 

于是，对设计模式的比较“研究”（在此，就高吹一次吧）的想法就油然而生了。。。

（以下是小生的想法，以及以后写这些blog的思路，嗤之以鼻者，完全可以绕路而行，倘若有高手路过，小弟愿请留下墨宝！）

因为从毕业开始，就一直在跟java打交道，的确是写了好几年代码，接触了很多方面的技术，但是好像都是皮毛。。。面向对象的概念一直就是一个概念。跟公司里面的很多人沟通，他们也是这么一种感觉，如果是过程性的开发，java却有没有c的那种效率（在此，不敢动语言之间优劣比较这块奶酪）；如果是面向对象，却也没有真正发挥java的作用。总而言之，就只是会用几种常用的框架而已。所以，我一直在想，所谓的设计到底存在于何地？

 

当我开始琢磨这个问题的时候，我的很多同事可能还是在讨论数据库表字段到底该怎么建立？个人觉得，那种细节问题必须跟设计一样，从基础入手，这里的基础我定义成“需求”。因为我们接触了大量的需求，但是这个需求的层次太接近用户了，一直都是用户的概念。

 

所以，我想要做好设计，要理解设计模式，就要做好理解以下这几个方面的准备：

1.需求

   需求，过程上分为：需求获取和需求分析。我接触过很多接触过这两个方面的工作的人。工作经验在3以内的都对这两个方面有或多或少的了解，尤其是在小公司（开发团队规模在100人以内的，项目规模在10人以内的）里面。当我们兴致勃勃的冲到客户面前，跟客户促膝长谈，跟客户之间，除了没有相见恨晚之意之外，一般做需求调研的人会有一种感觉：我完全理解你的意思。被调研的客户也会有一种感觉：终于有人理解我的看法了。冗长的需求文档变成了“高山流水”。但是，我的亲身经历告诉我，即便是经过了所谓的抽象分析，有些用户的需求还是停留在用户的层次上（需求调研人员就只承担了录音机的功能），我们分析出来的最多就是把用户的“话”变成了我们的“话”，换汤不换药，没有抓住需求中矛盾的本质。也就是需求在获取了之后，没有经过很好的分析真正变成我们分析人员和用户都认可的有深度的“需求文档”。我们的需求分析只是一个模板，所以我们的软件如果不是有很好的开源框架的支撑，扩展性方面的问题，可能会更加严重。。。

   上面这么多，就是想表明一点，需求分析需要概念模型。无论是敏捷中草图还是uml里面的用例图，只有体现出了“概念模型”。那我们就很少会产生偏差了。

   这里的需求概念定义为：能够切实体现用户实际业务处理场景的需求抽象。

正如很多书中提到的运输模型：一个客户下了将一定量的一种商品，采用某种运输方式，从一个地点运到另一个地点，交给接收人。假设这是用户给我们的陈述，我们就可以把客户和接受人从这个需求中提炼出来变成“参与人”和角色（客户，接收人）两个概念，以体现这个这个需求的一般性。

  需求的分析，给我们以清晰的对象运行上下文，也就会使得我们的设计更加贴合用户，甚至是市场的需要。

2.对象

  这个就不展开牢骚了，没有对象的概念来谈设计模式，就像我现在的感觉一样。

3.上下文

  建立在1,2的基础之上，我们如何来构造一个运行场景，如何来设计对象之间的关联关系。绝对不会简单到像很多书中讲的那些场景那么简单，因为那些场景首先不是我们从具体需求中分析出来的，其次不能从整个系统架构上考虑具体问题。

  那本《敏捷软件开发》里面有一个大的实例，还是相当有意思的。

4.分层

  有了需求环境，有了具体上下文中的对象，我们也不能随便把这些对象揉和在一起。

  就像是ddd中提到的需要基础框架，需要分层一样，我们要想mvc那样，用基础框架来屏蔽最基本的问题（结构问题，模块划分等方面）。

5.重构

  设计模式，是用来改进我们的软件的。这个过程都是在重构中实现的。

 

所以，我们要学会如何需求分析，如何抽出需求中的上下文和对象，然后采用什么样的设计模式来组合和关联这些对象，以至于在不断的扩展中来提高和改进我们的软件产品。

 

 

这么一个开端，应该定下了一个基调，希望兄弟姐妹跟我一起分析。。