<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>臭皮匠 &#187; 设计模式</title>
	<atom:link href="http://guogoul.com/tag/design_patterns/feed/" rel="self" type="application/rss+xml" />
	<link>http://guogoul.com</link>
	<description></description>
	<lastBuildDate>Fri, 29 Oct 2010 00:24:37 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>摘自_设计模式解析(2)</title>
		<link>http://guogoul.com/2008/05/13/pick-design-patterns-2/</link>
		<comments>http://guogoul.com/2008/05/13/pick-design-patterns-2/#comments</comments>
		<pubDate>Tue, 13 May 2008 15:25:08 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[技巧]]></category>
		<category><![CDATA[设计模式]]></category>

		<guid isPermaLink="false">http://www.guogoul.com/2008/05/13/pick-design-patterns-2/</guid>
		<description><![CDATA[8.switch语句本身常常说明:
   (1).需要多态行为;
   (2)存在职责错放.应该考虑用一种更为通用的解决方案,比如抽象代替switch语句,或者将职责赋于其它对象.
9.使用设计模式常见的错误:
 (1)浮于表面:仅仅对低层情况有一些肤浅的理解，就草草选择一个模式。
 (2)偏见:对于模式过于偏信。根据已经选定的模式/模型来解释所有的数据，不愿意对自己的偏见有任何的怀疑。
 (3)错选: 不理解模式适用的背景和条件（对各模式的分类关系理解不全）,选择了错误的模式。
 (4)误判：不熟悉各种模式，因为无知导致误判。
 (5)削足适履：忽略了实际的，具体实例行为中的例外情况，因为它们似乎不符合模式中所表达的理论。很可能会使所建模出来的对象过于僵硬，不符合实际情况。
10.与客户打交道的经验:
 (1).他们通常非常了解他们的问题域（大多数我们永远都赶不上）
 (2).一般情况下，他们不会像开发人员经常的那样在概念层次上表达事情，相反，他们会谈得十分的具体。
 (3).他们经常用&#8221;总是&#8221;表示“通常”
 (4).他们经常用&#8221;从不&#8221;表示“很少”
 总之对于非常具体的问题，客户详细的回答一般是可信的，但是他们一般性的回答却不可信。
]]></description>
		<wfw:commentRss>http://guogoul.com/2008/05/13/pick-design-patterns-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>摘自_设计模式解析(1)</title>
		<link>http://guogoul.com/2008/05/11/pick-design-patterns/</link>
		<comments>http://guogoul.com/2008/05/11/pick-design-patterns/#comments</comments>
		<pubDate>Sun, 11 May 2008 08:03:59 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[设计模式]]></category>

		<guid isPermaLink="false">http://www.guogoul.com/2008/05/11/pick-design-patterns/</guid>
		<description><![CDATA[1. 正确分析和设计要求我们在互相矛盾的关注点中找到平衡,必须决定问题的哪些方面是设计的重点,或者应该让系统防范哪些变化.寻找平衡必须成为做出决策的第一要务.不要让细节转移了你的注意力.分析人员都可以犯的常见错误是:在开发过程中过早的深入细节,因为处理细节是比较容易.细节的解决方案总是显而易见的,但并非肯定是最好的入手点.细节问题的处理应尽可能推后.
2. Facade模式简化了接口,而adapter模式则将一个已有的接口转化成另一个接口.
3. 优先使用对象组合,而不是类继承.
4. 过度使用继承:(以下作者的感悟,我觉得很有道理)
   &#8220;在我还是一个初级的面向对象分析时,曾经很喜欢利用继承,使用特殊情况解决这里碰到的问题.我喜欢继承的思想,因为他们看起来新颖而且功能十分的强大.只要可以继承的地方都使用了继承.似乎对许多设计师来说这很正常,但是其实这是很幼稚的:有了新的&#8221;锤子&#8221;,所有的东西看上去都成了钉子.糟糕的是许多面向对象的设计方式关注点都放在了通过特化处理,从已有的类派生新类上.正是对这种对对象的&#8217;is-ness&#8217;性质的过度关注,程序员往往会在巨大臃肿的类层次关系中创建对象,这种层次开始时可能还能正常工作,但是随着时间的推移将变得越来越难以维护.而当我成为一个有经验的面向对象设计人员之后,仍然深陷于继承的设计方式之中,还是根据&#8217;is-ness&#8217;性质观察类的特点,无论结构变得多么的复杂.用设计模式进行思考最终救我于泥潭之中,自此学会了用对象的职责而不是其结构来思考问题.有经验的设计分析师都已经了解到应该有选择的使用继承.才能发挥其优势.使用设计模式,将有助于加快这一学习进程.其中就包括从&#8217;为每种变化使用不同的特化&#8217;(继承)到&#8217;将变化转移到使用或拥有这种变化的对象中&#8217;(组合)的转变&#8221;
5. 一条规则,实现一次:
  &#8216;有一条重要的实现策略应该遵循:规则只在一个地方实现.换言之,如果做什么事只有一条规则,只实现一次.这通常会使代码中出现许多小的方法,所增加的代价很小,却消除了重复,而且经常可以预防将来可以出现的许多问题。重复的害处不仅在于输入工作成倍增加，还因为将来有东西发生变化时，可能会忘记在所有需要地方进行修改.&#8217;
6.衡量设计质量的一种方法是:看它是否能很多好应对变化。
7。模式并不总能提供十全十美的解决方案,但是因为模式是众多设计人员多年的集体智慧结晶，所以它们通常优于你我自己有限时间所能提供的解决方案。
欢迎大家谈谈关于设计模式的一些想法
]]></description>
		<wfw:commentRss>http://guogoul.com/2008/05/11/pick-design-patterns/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>为什么要学习设计模式</title>
		<link>http://guogoul.com/2008/05/08/why-design-patterns/</link>
		<comments>http://guogoul.com/2008/05/08/why-design-patterns/#comments</comments>
		<pubDate>Thu, 08 May 2008 15:19:44 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[设计模式]]></category>

		<guid isPermaLink="false">http://www.guogoul.com/2008/05/08/why-design-patterns/</guid>
		<description><![CDATA[设计模式是程序员自身修炼的宝典,一直没有时间系统的学习.主要原因是没有认知其重要性.最近花了点时间看了设计模式解析,通俗易懂.个人觉得是一本好书,过一段时间再认真学习一篇.学习设计模式最好的时机是在有一年左右的编码经验以后.因为只有在有一定的编码经验才能感同身受,更易理解模式其更深层的道理.
    下面就来解答一下学习设计模式的理由:
     1.复用解决方案: 通过复用已经公认的设计,能够在解决问题时取得先发优势.避免重蹈覆辙.您是是否也有类似疑虑:几个项目下好像解决方案大体可以公用.但是就是没有总结.工作好像一直在重复
     2. 确定通用术语: 开发中的交流和协作都需要共同的词汇其础和对问题的共识.如果交流双方都学习过设计模式交流起来就会十分的舒服.不知道你有没有想表达又表达不清楚的设计思路,或者自己表达得明白但对方又误解了你的意思了呢?看了设计模式你也许可以找到你想要的答案
     3. 改善团队的沟通和个人学习.一个团队一起学习设计模式,有助于团队战斗力的提高.
     4. 代码更易于修改与维护. 因为设计模式都是久经考验的解决方案,它们的结构都是经过长期的发展形成的.善于应对变化.
     5.学习模式后,就算不用模式中的方法.也会更好的采取更好的策略去解决问题.
     难道你还不心动吗?
]]></description>
		<wfw:commentRss>http://guogoul.com/2008/05/08/why-design-patterns/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>singleton模式与double-checked Locking模式</title>
		<link>http://guogoul.com/2008/05/04/singleton/</link>
		<comments>http://guogoul.com/2008/05/04/singleton/#comments</comments>
		<pubDate>Sun, 04 May 2008 15:10:47 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[设计模式]]></category>
		<category><![CDATA[singleton]]></category>

		<guid isPermaLink="false">http://www.guogoul.com/2008/05/04/singleton/</guid>
		<description><![CDATA[singleton是一个十分常用的模式,也十分简单.不过到现在才知道这种模式叫singleton模式.
现在把singleton模式做一下记录.
模式意图:
     保证一个类仅有一个实例,并提供一个访问它的全局访问点.
问题:
    几个不同的客户对象需要引用一个对象.而且希望确保这种类型的对象数目不超过1个
实现原理:
    1.添加一个类的私有的静态成员变量,引用所需的对象.
    2.添加一个公共的静态方法,它在成员变量的值为null时实例化这个类,然后返回成员变量的值.
    3.将构造函数的状态设置为保护或私有,从而防止任何人实例化这个类,绕过静态构造函数的机制
Singleton模式的C++片段
        class SingletonTest{
            private static Singleton s_instance;
          [...]]]></description>
		<wfw:commentRss>http://guogoul.com/2008/05/04/singleton/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

