星期二, 5月 13th, 2008 189 次访问
8.switch语句本身常常说明:
(1).需要多态行为;
(2)存在职责错放.应该考虑用一种更为通用的解决方案,比如抽象代替switch语句,或者将职责赋于其它对象.
9.使用设计模式常见的错误:
(1)浮于表面:仅仅对低层情况有一些肤浅的理解，就草草选择一个模式。
(2)偏见:对于模式过于偏信。根据已经选定的模式/模型来解释所有的数据，不愿意对自己的偏见有任何的怀疑。
(3)错选: 不理解模式适用的背景和条件（对各模式的分类关系理解不全）,选择了错误的模式。
(4)误判：不熟悉各种模式，因为无知导致误判。
(5)削足适履：忽略了实际的，具体实例行为中的例外情况，因为它们似乎不符合模式中所表达的理论。很可能会使所建模出来的对象过于僵硬，不符合实际情况。
10.与客户打交道的经验:
(1).他们通常非常了解他们的问题域（大多数我们永远都赶不上）
(2).一般情况下，他们不会像开发人员经常的那样在概念层次上表达事情，相反，他们会谈得十分的具体。
(3).他们经常用"总是"表示“通常”
(4).他们经常用"从不"表示“很少”
总之对于非常具体的问题，客户详细的回答一般是可信的，但是他们一般性的回答却不可信。
Posted in 技巧, 设计模式 | No Comments »
星期日, 5月 11th, 2008 228 次访问
1. 正确分析和设计要求我们在互相矛盾的关注点中找到平衡,必须决定问题的哪些方面是设计的重点,或者应该让系统防范哪些变化.寻找平衡必须成为做出决策的第一要务.不要让细节转移了你的注意力.分析人员都可以犯的常见错误是:在开发过程中过早的深入细节,因为处理细节是比较容易.细节的解决方案总是显而易见的,但并非肯定是最好的入手点.细节问题的处理应尽可能推后.
2. Facade模式简化了接口,而adapter模式则将一个已有的接口转化成另一个接口.
3. 优先使用对象组合,而不是类继承.
4. 过度使用继承:(以下作者的感悟,我觉得很有道理)
"在我还是一个初级的面向对象分析时,曾经很喜欢利用继承,使用特殊情况解决这里碰到的问题.我喜欢继承的思想,因为他们看起来新颖而且功能十分的强大.只要可以继承的地方都使用了继承.似乎对许多设计师来说这很正常,但是其实这是很幼稚的:有了新的"锤子",所有的东西看上去都成了钉子.糟糕的是许多面向对象的设计方式关注点都放在了通过特化处理,从已有的类派生新类上.正是对这种对对象的'is-ness'性质的过度关注,程序员往往会在巨大臃肿的类层次关系中创建对象,这种层次开始时可能还能正常工作,但是随着时间的推移将变得越来越难以维护.而当我成为一个有经验的面向对象设计人员之后,仍然深陷于继承的设计方式之中,还是根据'is-ness'性质观察类的特点,无论结构变得多么的复杂.用设计模式进行思考最终救我于泥潭之中,自此学会了用对象的职责而不是其结构来思考问题.有经验的设计分析师都已经了解到应该有选择的使用继承.才能发挥其优势.使用设计模式,将有助于加快这一学习进程.其中就包括从'为每种变化使用不同的特化'(继承)到'将变化转移到使用或拥有这种变化的对象中'(组合)的转变"
5. 一条规则,实现一次:
'有一条重要的实现策略应该遵循:规则只在一个地方实现.换言之,如果做什么事只有一条规则,只实现一次.这通常会使代码中出现许多小的方法,所增加的代价很小,却消除了重复,而且经常可以预防将来可以出现的许多问题。重复的害处不仅在于输入工作成倍增加，还因为将来有东西发生变化时，可能会忘记在所有需要地方进行修改.'
6.衡量设计质量的一种方法是:看它是否能很多好应对变化。
7。模式并不总能提供十全十美的解决方案,但是因为模式是众多设计人员多年的集体智慧结晶，所以它们通常优于你我自己有限时间所能提供的解决方案。
欢迎大家谈谈关于设计模式的一些想法
Posted in 设计模式 | 2 Comments »