Archive for the ‘设计模式’ Category
星期日, 6月 22nd, 2008 290 次访问
第三界"敏捷中国"的会议主题是精益软件思维，听了Martin Fowler（重构的作者）和ThoughtWorks同事的精彩演讲，收获不少。在此分享一下学习心得。敏捷的最大好处是减少浪费，通过对质量的严格控制减少返工的浪费，通过频繁的反馈减少误解的浪费。这种与浪费做战的态度，与精益(Lean)思想同出一处。1）何为'精益':以上摘自: http://blog.vsharing.com/tiger_wing/A387321.html精益生产（Lean Production，简称LP）是美国麻省理工学院数位国际汽车计划组织（IMVP）的专家对日本“丰田JIT（Just InTime）生产方式”的赞誉之称，精，即少而精，不投入多余的生产要素，只是在适当的时间生产必要数量的市场急需产品（或下道工序急需的产品）；益，即所有经营活动都要有益有效，具有经济性。精益生产是当前工业界最佳的一种生产组织体系和方式。2)怎么从传统工业中的精益生产到软件互联网行业的精益开发呢？软件行业是一个新兴的快速发展的行业，他与传统行业存在很多不同的思维方式，但是存在更多的共同点，很多在软件行业中的做法借鉴了传统行业，并且在软件行业中收效很大。比如软件设计的精典著作《设计模式》则借鉴了建筑领域的著作《建筑模式》.软件行业学习制造业的精益思想也是理所当然.(以下笔记摘自路宁的精采演讲)2.1 精益工厂的环境是干净，井井有条的工厂搞得像医院一个干净有条理,而不像一般的工厂一样到到处是油污，到处散落零件。目的是更加方便的找出质量的死角，无限放大工作流程中的失误。我们程序员的工作环境也是如此，工作环境不仅指一个公司的工作环境，还指一个程序员个体的编码环境。如果工作环境是无序的，零乱的，那么在这个环境里面的工作人员怎么不会被外界的环境所影响呢？程序员的编码环境也如此，如果每天发费大量的时间在你混乱的文件路径中查找你在中的工作材料,怎么会有时间集中精神把一件事件做到位呢？（哈哈！从现在开始把当天要进行开发的工作目录设置为根目录）2.2 最大程度的了解团队的信息。
Posted in 感悟, 设计模式 | 2 Comments »
星期二, 5月 13th, 2008 231 次访问
8.switch语句本身常常说明:
(1).需要多态行为;
(2)存在职责错放.应该考虑用一种更为通用的解决方案,比如抽象代替switch语句,或者将职责赋于其它对象.
9.使用设计模式常见的错误:
(1)浮于表面:仅仅对低层情况有一些肤浅的理解，就草草选择一个模式。
(2)偏见:对于模式过于偏信。根据已经选定的模式/模型来解释所有的数据，不愿意对自己的偏见有任何的怀疑。
(3)错选: 不理解模式适用的背景和条件（对各模式的分类关系理解不全）,选择了错误的模式。
(4)误判：不熟悉各种模式，因为无知导致误判。
(5)削足适履：忽略了实际的，具体实例行为中的例外情况，因为它们似乎不符合模式中所表达的理论。很可能会使所建模出来的对象过于僵硬，不符合实际情况。
10.与客户打交道的经验:
(1).他们通常非常了解他们的问题域（大多数我们永远都赶不上）
(2).一般情况下，他们不会像开发人员经常的那样在概念层次上表达事情，相反，他们会谈得十分的具体。
(3).他们经常用"总是"表示“通常”
(4).他们经常用"从不"表示“很少”
总之对于非常具体的问题，客户详细的回答一般是可信的，但是他们一般性的回答却不可信。
Posted in 技巧, 设计模式 | No Comments »
星期日, 5月 11th, 2008 306 次访问
1. 正确分析和设计要求我们在互相矛盾的关注点中找到平衡,必须决定问题的哪些方面是设计的重点,或者应该让系统防范哪些变化.寻找平衡必须成为做出决策的第一要务.不要让细节转移了你的注意力.分析人员都可以犯的常见错误是:在开发过程中过早的深入细节,因为处理细节是比较容易.细节的解决方案总是显而易见的,但并非肯定是最好的入手点.细节问题的处理应尽可能推后.
2. Facade模式简化了接口,而adapter模式则将一个已有的接口转化成另一个接口.
3. 优先使用对象组合,而不是类继承.
4. 过度使用继承:(以下作者的感悟,我觉得很有道理)
"在我还是一个初级的面向对象分析时,曾经很喜欢利用继承,使用特殊情况解决这里碰到的问题.我喜欢继承的思想,因为他们看起来新颖而且功能十分的强大.只要可以继承的地方都使用了继承.似乎对许多设计师来说这很正常,但是其实这是很幼稚的:有了新的"锤子",所有的东西看上去都成了钉子.糟糕的是许多面向对象的设计方式关注点都放在了通过特化处理,从已有的类派生新类上.正是对这种对对象的'is-ness'性质的过度关注,程序员往往会在巨大臃肿的类层次关系中创建对象,这种层次开始时可能还能正常工作,但是随着时间的推移将变得越来越难以维护.而当我成为一个有经验的面向对象设计人员之后,仍然深陷于继承的设计方式之中,还是根据'is-ness'性质观察类的特点,无论结构变得多么的复杂.用设计模式进行思考最终救我于泥潭之中,自此学会了用对象的职责而不是其结构来思考问题.有经验的设计分析师都已经了解到应该有选择的使用继承.才能发挥其优势.使用设计模式,将有助于加快这一学习进程.其中就包括从'为每种变化使用不同的特化'(继承)到'将变化转移到使用或拥有这种变化的对象中'(组合)的转变"
5. 一条规则,实现一次:
'有一条重要的实现策略应该遵循:规则只在一个地方实现.换言之,如果做什么事只有一条规则,只实现一次.这通常会使代码中出现许多小的方法,所增加的代价很小,却消除了重复,而且经常可以预防将来可以出现的许多问题。重复的害处不仅在于输入工作成倍增加，还因为将来有东西发生变化时，可能会忘记在所有需要地方进行修改.'
6.衡量设计质量的一种方法是:看它是否能很多好应对变化。
7。模式并不总能提供十全十美的解决方案,但是因为模式是众多设计人员多年的集体智慧结晶，所以它们通常优于你我自己有限时间所能提供的解决方案。
欢迎大家谈谈关于设计模式的一些想法
Posted in 设计模式 | 2 Comments »
星期四, 5月 8th, 2008 283 次访问
设计模式是程序员自身修炼的宝典,一直没有时间系统的学习.主要原因是没有认知其重要性.最近花了点时间看了设计模式解析,通俗易懂.个人觉得是一本好书,过一段时间再认真学习一篇.学习设计模式最好的时机是在有一年左右的编码经验以后.因为只有在有一定的编码经验才能感同身受,更易理解模式其更深层的道理.
下面就来解答一下学习设计模式的理由:
1.复用解决方案: 通过复用已经公认的设计,能够在解决问题时取得先发优势.避免重蹈覆辙.您是是否也有类似疑虑:几个项目下好像解决方案大体可以公用.但是就是没有总结.工作好像一直在重复
2. 确定通用术语: 开发中的交流和协作都需要共同的词汇其础和对问题的共识.如果交流双方都学习过设计模式交流起来就会十分的舒服.不知道你有没有想表达又表达不清楚的设计思路,或者自己表达得明白但对方又误解了你的意思了呢?看了设计模式你也许可以找到你想要的答案
3. 改善团队的沟通和个人学习.一个团队一起学习设计模式,有助于团队战斗力的提高.
4. 代码更易于修改与维护. 因为设计模式都是久经考验的解决方案,它们的结构都是经过长期的发展形成的.善于应对变化.
5.学习模式后,就算不用模式中的方法.也会更好的采取更好的策略去解决问题.
难道你还不心动吗?
Posted in 设计模式 | 2 Comments »
星期日, 5月 4th, 2008 223 次访问
singleton是一个十分常用的模式,也十分简单.不过到现在才知道这种模式叫singleton模式.
现在把singleton模式做一下记录.
模式意图:
保证一个类仅有一个实例,并提供一个访问它的全局访问点.
问题:
几个不同的客户对象需要引用一个对象.而且希望确保这种类型的对象数目不超过1个
实现原理:
1.添加一个类的私有的静态成员变量,引用所需的对象.
2.添加一个公共的静态方法,它在成员变量的值为null时实例化这个类,然后返回成员变量的值.
3.将构造函数的状态设置为保护或私有,从而防止任何人实例化这个类,绕过静态构造函数的机制
Singleton模式的C++片段
class SingletonTest{
private static Singleton s_instance;
...
Posted in 设计模式 | 2 Comments »