C++博客-Welcome to ErranLi's Blog!-随笔分类-Design Pattern

道可道，非常道。道不远人，设计模式亦然如此---设计模式学习小记

erran — Sat, 16 Jun 2007 09:59:00 GMT

学习设计模式，选定了三本书：

1. 设计模式精解 [美]Alan Shalloway & James R. Trott著
    很基础的书，没有全面介绍23种模式，但是比较好懂，已经看完了。

2.设计模式-可复用面向对象软件的基础      GOF
   公认的设计模式经典之作，不是很好懂，考验考验耐心吧，早些时候看了一半，就没看了，感觉收获很少，看完了第一本书后，现有捡起这本来从头看起，应该会有不少收获。

3.设计模式精解-GOF23种设计模式解析      一牛人写的手稿
   这个是某牛人深刻理解和实际应用GOF那一帮理论后，写的一个手稿，感觉很不错，已经看完了，现又看准备一遍。

   这儿准备记录些书中比较经典的文字，以及自己的些些理解。欢迎指正，共同探讨。

   1、懂了设计模式，你就懂了面向对象分析和设计（OOA/D）的精要。反之好像也可能成立。道可道，非常道。道不远人，设计模式亦然如此。
【排第一的当然是这一句了！道可道，非常道，顺便查了下这句话的出处老子《道德经》：“道可道也，非恒道也。名可名也，非恒名也。无名，万物之始也；有名，万物之母也。故恒无欲也，以观其眇；恒有欲也，以观其所徼。两者同出，异名同谓。玄之又玄，众眇之门。” 简单理解就是，“道”是可以意会的，但不可以言传。哈哈，感觉设计模式也是这样，往往只能由某个例子去通过“模式”的方法去解决某个问题，来说明模式的存在，在设计模式精解（第一本书里）最后几章，感觉作者是在拿着问题用一个一个的模式去套，违背了它的本意。正如下句所说：】

   2、设计模式体现的是一种思想，而思想则是指导行为的一切，理解和掌握了设计模式，并不是说记住了 23 种（或更多）设计场景和解决策略（实际上这也是很重要的一笔财富），实际接受的是一种思想的熏陶和洗礼，等这种思想融入到了你的思想中后，你就会不自觉地使用这种思想去进行你的设计和开，这一切才是最重要的。

   3、设计模式之于面向对象系统的设计和开发的作用就有如数据结构之于面向过程开发的作用一般，其重要性和必要性自然不需要我赘述。

   4、Scott Mayer 在其巨著《Effective C++》就曾经说过：C++老手和C++新手的区别就是前者手背上有很多伤疤。是的在软件开发和设计的过程中，失败、错误是最好的老师，当然在系统开发中，失败和错误则是噩梦的开端和结束，因为你很难有改正错误的机会。因此，尽量让自己多几道疤痕是对的。

   5、面向对象系统的分析和设计实际上追求的就是两点，一是高内聚(Cohesion),而是低耦合（Coupling）。这也是我们软件设计所准求的，因此无论是 OO 中的封装、继承、多态，还是我们的设计模式的原则和实例都是在为了这两个目标努力着、贡献着。

   6、写这些文章，本身没有任何功利的杂念，只是一个原生态的冲动，反而很轻松的完成了。有心栽花未必发，无心之事可成功，世间的事情可能在很多的时候恰恰就是那样了。【作者的心态很令人欣赏....】

   （1到6是择自设计模式手稿（第三本书））

   7、设计模式是针对特定场景下的特定问题的可重复、可表达的解决方案。它不限于面向对象。不限于设计阶段，甚至不限于软件开发领域。

   8、从概念层次来看，一个对象是一系列的责任。从规范层次来看，一个对象是一系列可以被其他对象或者该对象自己调用的方法。从实现层次来看，一个对象是一些代码和数据。

   9、一个分析的缺陷：过早对细节投入太多的关心。分析者可能共同存在一个问题：在开发过程中过早的投入了细节分析。这也很自然，因为细节上的问题总是很具体很容易的。细节上的解决方案通常很明显，但这未必是一个最好的起点。应该尽可能晚地投入细节中去。

   10、设计模式源于建筑学和人类学。【延伸阅读著名建筑师Christopher Alexander的名著：The Timeless Way of Building，有中译本，已经看过，译本形如散文，很有意思。】

   11、最主要的一点就是封装变化的概念，这是许多设计模式的主题。发现并封装变化点。

   12、换句话说，如果变化点是问题领域中的特定的具体情况，共同点就定义了问题领域中将具体情况捆绑在在一起的概念。共同的概念将由抽象类来表现。而变化点分析发现的变化点将由具体类（使用特定实现的派生自抽象类的类）来实现。

   13、在创建设计以处理变化的过程中，应该遵循两条基本策略：
                     ·发现并封装变化点。
                     ·优先使用对象组合，而不是类继承。
过去，开发这常常依靠扩展继承来为这些变化点定位。但是，第二条策略告诉我们，应该尽可能尝试使用对象组合。其意图是可以在独立的类中包含变化点从而使未来的变化不会影响现在的代码。

6点了，要回了，下次接着写吧.......o(∩_∩)o...

erran 2007-06-16 17:59 发表评论

设计模式的高度浓缩

erran — Mon, 11 Jun 2007 11:05:00 GMT

看完了设计模式精解，得出了一句话作为总结：

高效合理地封装变化点

o(∩_∩)o...哈哈........

erran 2007-06-11 19:05 发表评论

关于工厂模式很有趣的解释.哈哈.

erran — Tue, 23 May 2006 15:52:00 GMT

用简单的语言解释一下什么叫工厂方法? 到底有什么用?

A

每个月1号是happy家庆祝的日子,因为是happy father发工资的日子.
happy father:"今天饭真香."
happy mother:"肉多就香,儿子这50块是你这个月的零花钱!"
happy father:"记住不许去网吧,那地方总着火!"
情景解释:happy mother把零花钱给儿子,至于他怎么花,什么时候花买什么东西有儿子做主.

B

LZ 有时候吃康师傅方便面，统一方便面，.... 但吃的时候都要自己去煮
我给LZ做了台机器叫煮方便面机，LZ把这些方便面放里面，想吃康师傅按1，想吃统一按2....
自动给LZ煮好出来了

C

请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。

D

这么笼统的说让一个其他对象代替你干事情，好像所有的模式都是干这个事情的，应该把范围限制一下：
主要是用在创建实例的时候使用，比如你在客户端，有一个接口要你调用，有很多类实现了这个接口，你想使用这个接口的时候必须指明new 的是哪一个类，就是接口 I = new 类名。这个时候问题来了，你根本就不知道类名，或者你不想在你的这个里面直接指定类名，这个时候，如果有一个专门生成实例的工厂有多好啊，你向它提出要求生成的实例，然后他给你返回对象的实例。这样客户端和具体类之间耦合性减低，内聚性增强。

E

打个比方，你是一个初创IT公司的CEO，公司目前处于不断的发展阶段，需要不停的招各方面的人才，如程序员，系统设计师，后勤人员，管理人员，财务人员，你开始的做法是你亲自干这件事情，你不停的拟定标准，然后和人员面试，决定选人。哪天，你突然意识到你可以制定一个人去专门干这件事情，而你可以腾出更多的精力考虑公司的发展，于是你指定了一个HR经理，此后，你需要哪方面的人，你不再需要做这方面的事情，你可以叫来HR经理，告诉他你要一个“财务人员”，并告诉一些基本要求，然后HR经理会帮你选定符合标准的人才。这个例子中的HR经理就是工厂模式。
我觉得有些模式你看不懂是正常的，但是如果你在写程序的时候认真思考一些问题，你会触类旁通的。一个人写的程序的过程与一个公司的发展我觉得一定程度上是类似的，一开始，你的程序或者你的公司处于起步阶段，啥事情都需要你总经理做，啥功能都需要你一行行写，随着经验的提高，你会觉得一些重复写的功能我可以把他封装一下，避免重复CODING，我还可以把他写的更灵活，适应于各种情况，这就是模式，对于公司，一样，等到公司发展到一定程度，各个职能的部门都建立起来了，负责各自职能的一块，你作为总经理会觉得轻松了许多，也会有更多的时间关注在公司发展上面了。

erran 2006-05-23 23:52 发表评论