??xml version="1.0" encoding="utf-8" standalone="yes"?> 读《大话设计模式》———?/span>11?/span>无熟人难办事Q——_c特法则 q米Ҏ(gu)则(LoDQ,如果两个cM必彼此直接通信Q那么这两个cd不应当发生直接的怺作用。如果其中一个类需要调用另一个类的某一个方法的话,可以通过W三者调用。[J&DP] 本法则强调的是,在类的设计上Q应该尽量保证类之间的松耦合。类之间的关pM应该必须是直接调用的Q而应该是通过抽象来实现各自的功能。就如同人际关系办事情,如果是必要针对个hQ那么没有熟人或者熟Z在,那就办不成了Q这U体制显然不好!比如Q希望政府办的事情,应该不需要知道要谁来处理Q只是统一向政府提个需求,然后他们内部zh处理好!q米Ҏ(gu)则,最知识原则?/span> 读《大话设计模式》———?/span>10?/span>模板Ҏ(gu)模式 模板Ҏ(gu)模式Q定义一个操作中的算法的骨架Q而将一些步聚gq到子类中。模板方法得子cd以不改变一个算法的l构卛_重定义该法的某些特定不聚。[DP] 模板Ҏ(gu)的优点:通过把不变的行ؓ攑ֈ父类Qƈ在父cM提供模板Ҏ(gu)Q父cMq可能内部调用一些细节函敎ͼ但是q些l节函数是虚函数Q由不同的子cdC同的具体功能。这样子cd成特定的行ؓQ但是不需要重复的代码?/span> 好了Q简单的模板Ҏ(gu)模式Q同h面向对象中承和多态的l合q用。学好了Q?/span> 读《大话设计模式》———?/span>9?/span>历复?/span>—?/span>原型模式 原型模式Q用原型实例指定创徏对象的种c,q且通过拯q些原型创徏新的对象。[DP] 原型模式其实是从一个对象再创徏另外一个可定制的对象,而且不需知道M创徏的细节。看到这些说明,我想q是不是可以理解为c++中的拯构造函数呢Q这可能是需求中最常见的模式了?/span> 如果从这个角度理解,无疑的,q个模式可以通过了。只是他告诉我们Q设计的时候考虑扚w生的情况,所以需要提供复制的Ҏ(gu)。至于文中所讲的复制和深复Ӟ好像C#中才考虑q个问题Qc++中指针引用等是必要特定处理的。学好了Q?/span> 读《大话设计模式》———?、雷锋依然在人间——工厂方法模?/font> 单工厂模式、工厂方法模式,q两者的区别我想思义Q前者讲的是q个模式用到一个简单工厂,但是后者强调的是工厂方法,其实意思就是该模式中工厂设计很重要?/font> 其实理解了简单工厂,基本上只要再E微看一下工厂模式的设计Q就很容易理解这两个模式。不q,g工厂Ҏ(gu)模式是简单工厂模式的改进版,单工厂没有存在的必要。但是事实ƈ非如此,在扩展不l常的时候,一个简单工厂就可以了。但是要是经常有怼功能的扩展需求,那么工厂Ҏ(gu)模式p有h(hun)g些?/font> 在代码Ş式上Q简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断Q根据客L的选择条g动态实例化相关的类Q对于客L来说Q去除了与具体品的依赖。但是,工厂Ҏ(gu)是把单工厂的内部逻辑判断Ud了客L代码来进行。所以,惌增加功能Q就同时需要修改客L代码。但是这样代码结构还是很清晰的,所以两者各有千U! 读《大话设计模式》———?、会修电(sh)脑不会修攉机?——依赖倒{原则 ?sh)脑比收x单吗Qؓ什么拆开两者,很明显,攉机看hq要比电(sh)脑更复杂呢?原来Q好的架构好的设计在哪里都是通用的!?sh)脑各部件缺一不可Q但是绝不是只针Ҏ(gu)一个或者某一cM品,所有不同品的厂商都只服从一个统一的标准,q样Q我们就看不出电(sh)脑中哪一个是高层了。CPUQ内存?或者主板?。。。都不是Q谁也不依赖谁,依赖的是一个统一的接口标准! 依赖倒{原则Q抽象不应该依赖l节Q细节应该依赖抽象。具体到一个实际问题编E,应该是定义好的接口,q个接口不属于哪一个具体的东西Q应该是一个高层的抽象Q然后就是针Ҏ(gu)口编E,而不要对实现~程?/font> 讲到q里Q似乎世界的一切问题都q刃而解Q一切显得是那样的轻而易举!慢!一定不要自负的轻视Ҏ(gu)Q好Q谁都很听话的服从这个抽象接口,那么q个抽象接口怎么来?一切都在变Q难道这个抽象类是可以q背q个哲学上绝对真理的特例家伙Q他可能自n都要不停的变Q完了,到哪里去找这样一Ҏ(gu)呀Q?/font> 标尺也是自己定义的!无非是会需要随实际情况变化吗?不要忘了Q我们已l学会的l技——开䏀封闭原则。我们保证提供基本功能的接口不变Q实际需求增加时Q只要做开放扩展即可,面向对象的承能帮助我们扑ֈ正确适用实际问题的方法,问题不就解决了吗Q恩Q这栯计ȝ出统一的抽象接口或者抽象类是满x们的需求的Q不q,q有关键的一点,q一pdcd要满一个原则:里氏代换原则Q子cd必须能够替换掉他们的父类型。这个原则在许多别的情况下,q不一定是完全满的,但是此处用做标尺的抽象类Q必要满Q子cd以扩展做更多的事情,但是父类已经定义好的接口子类必须有实玎ͼq且也必L做一致的事情?/font> 依赖倒{原则说明了:好的面向对象设计不应该是依赖具体实现中的那一部分Q应该是针对抽象~程而不是针对细节编E,即程序中所有的依赖关系都是l止于抽象类或者接口。那P高层、底层的改变都不会导致另外一部分要做变化了?/font> 从北京去U约喽,;-)Q还有陆路还要vz,哈哈Q变化再大我也不,因ؓ我做的是飞机Q不q,你要是愿意先客R再渡轮也可以的哦~都是交通工L抽象嘛!应该不会q有那个大侠想着依赖道\的,先穿跑鞋再换个泳去的吧~ 读《大话设计模式?--------------4、考研求职两不?---开?闭原则 开䏀封闭原则,是说软g实体Q类、模块、函数等{)应该可以扩展Q但是不可修攏V[ASD]。这个原则有两个特征Q对于扩展是开攄Q另一个是说对于更Ҏ(gu)闭的?/font> 本原则经q作者精辟的阐述Q马上就让我们在哲学上对一些问题的看法豁然开朗:看v来两个完全抵触的东西Q利用扩展与闭原则p很好的解冟뀂什么东西必d闭,什么东西可以扩展?L和业l是必须关闭修改的,但是制度却是可以扩展开攄Q难道这仅仅是一U计机理论吗?q简直是处事之道Q?/font> 如何应对变化Q——除非你_强大Q所有的人和事都无条件的服从你的Q否则就需要面Ҏ(gu)法预料的变化。事实上Q对未来变化的估计和处理能力正是智慧的体现。好像离E序设计来远了哦~a归正传,既然变化是无法避免的Q那么对已有的机制进行对应的修改也是必须的(真的?#8220;以不变应万变”么?Q。所以,“l对的修改关闭是不可能的。无论模块是多么?#8216;闭’Q都会存在一些无法对之封闭的变化。既然不可能完全闭Q设计h员必d于他设计的模块应该对那种变化闭做出选择。他必须先猜出最有可能发生的变化U类Q然后构造抽象来隔离那些变化[ASD]?#8221; “在我们最初编写代码时Q假讑֏化不会发生。当变化发生Ӟ我们创建抽象来隔离以后发生的同cd化[ASD].”q里同时也反映了一个问题:要架构好的程序,我们需要善于分析程序的变化Q善于ȝ善于抽象Q当遇到问题了,我们应该思考这一c问题,q作出抽象改善程序的架构Q提取出真正的封闭的和开攄部分?/font> 大鸟的ȝQ?#8220;开䏀封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处,也就是可l护、可扩展、可复用、灵zL好。开发h员应该仅对程序中呈现出频J变化的那些部分做出抽象Q然而,对于应用E序中的每个部分都刻意地q行抽象同样不是一个好L。拒l不成熟的抽象和抽象本n一样重要[ASD]?#8221; 很好Q从本设计模式学C很多很多Q远q超q了E序设计的范_哈哈Q考研的例子我觉得也很合适嘛。全力以赴是必须的,两手准备也是一U灵zR只要别忘了自己当前的重点——就像快乐一P得到成功的目标是关闭的,但过E是开攄Q?/font> 读《大话设计模式?---------------3、拍摄UFO------单一职责原则 作者对q个模式的运用和解释已经很清楚了“软g设计真正要做的许多内容,是发现职责q把那些职责怺分离[ASD].其实要去判断是否应该分离出类来,也不难,那就是如果你能够惛_多于一个的动机L变一个类Q那么这个类具有多于一个的职责[ASD],应该考虑cȝ职责分离?#8221; 读《大话设计模式?/font> 从本章我首先得到的第一个信息是Q策略模式的问题Q简单工厂模式也能实玎ͼ推而广之,同一个问题,可能许多模式都能实现Q但是这里d在一个更优的问题。至于真正用那个模式Q就是C++之父的那句话了:需要经验智慧了?/font> W二个马上引出问题的l论Q?#8220;面向对象的编E,q不是类多好Q类的划分是Z装Q但分类的基是抽象,h相同属性和功能的对象的抽象集合才是c?#8221;。这一句,我觉得是最深刻的道出类设计原则的精辟之语。意思:W一、类q多好Q设计一个类是有价值有意义的:是ؓ了封装(单工厂的那个工厂cd是一个纯装作用的类Q但大多数情况徏立一个类q需要别的理由,可能单工厂属于一个特例)。第二、何时设计类Q当处理的看g些杂乱无章的东西h相同的属性和功能Ӟ有必要创徏c,因ؓQ用对象实现某些功能在可l护可复用等斚w要比直接的函数过E似的编E要好得多。以上两点,可能是怎样实际问题抽象成cȝU诀了! 当时我看到现金收费工厂类Ӟ我心里已lؓ“菜鸟”拍案叫绝了。他的学习能力好强呀Q⊙H⊙b汗!然而,大鸟后面的那些一针见血的话同时也让我进入了沉思。。。当我们发现自己好不Ҏ(gu)掌握了一样东西,我们g认ؓ自己学得是易{经Q以后就可以以此横扫天下了,但是q没出山门,p路上的山贼给鄙视了。。。这可能是少林寺有了易筋l还要有72l技的原因。。?/font> 被鄙视的原因Q简单工厂模式只是解决了对象的创建问题,工厂需要包括所有的对象的创建,如果对象形式l常变化Q就需要经常改动工厂,以致代码重新~译。结论:面对对象形式不断变化的情况,应该采取比工厂模式更好的武功Q?/font> q怺q本U籍q不难找Q策略模?--它定义了法家族Q分别封装v来,让他们之间可以互相替换,此模式让法的变化,不会影响C用算法的客户。[DP] 问题Q在2.7{略模式解析之上的部分,作者最l利用的Ҏ(gu)是将{略模式与简单工厂模式结合v来用Q当然与之对比的单工厂模式显然稍逊一{V但是我个h的观Ҏ(gu)Q此处采用单U的{略模式而不是两者结合更好。即2.5的实玎ͼ因ؓ我认为:加入工厂模式同时将本问题中工厂模式的问题带q来了,{略模式的Context需要经帔R新编译;而相对于法l常变化的情况,算法选择交给客户端应该还是可取的。现对而言Q我认ؓ前者更好操作。不够,当我d本章最后时Q我才又一ơ发现我的孤陋寡闻!q有更好的招Q后面再学?/font> {略模式的关键之一----------Context:“{略模式的StrategycdơؓContext定义了一pd的可供重用的法或行为。承有助于析取些算法中的公共功?#8221;?/font> {略模式理解核心-------------“{略模式是用来装法?/font>Q但在实践中Q我们发现可以用它来装几乎Mcd的规则,只要在分析过E中听到需要在不同旉应用不同的业务规则,可以考虑使用{略模式处理q种变化的可能性[DPE]”?/font> 在基本的{略模式中,选择所用的具体实现的职责由客户端对象承担,q{l策略模式的Context对象[DPE]。这是策略模式本w纯_的定义Q所以,“选择所用最l怎样处理”q有很多文章可做Q?/font> “反射反射Q程序员的快?#8221;Q我以前又从来没有听q。。。怎么让我惌v了慕容家族的l技-----斗{星移了呢Q我的神呀Q?/font>
]]>
]]>
]]>
]]>
]]>
代理模式Qؓ其他对象提供一U代理以控制对这个对象的讉K[DP]?
如果从以上这个定义,我们q可以挖掘出另一U层ơ的意思:代理模式为真实对象的讉K提供了安全性屏障?
阅读全文
]]>
]]>
]]>
]]>
q个模式应该是最Ҏ(gu)理解的一个模式了。不q解释意义还是比较有深度的:有一个类而言Q应该仅有一个引起它变化的原因[ASD]。职责越单一Q功能就独立。也没有复杂度Q就更好l护Q也更利于复用了?/font>
]]>
----------------2?/font>商场促销-----{略模式
]]>
单工厂的q用Q如果将针对从一个父cȝ承的多个子类q行不同条g下的实例化和q用{,q个选择判断的条件可能比较多Q显CZؓ客户端代码显得冗余,或者那些子cLw就是不希望让客L看到的,此时这些判断放C个统一的工厂里面生产将是一U很好的装模式。记住:工厂只要一个,也就是说l常要选择处理许多同父cd象。一个工厂是只有自己的一个品线的,要生产本质差别不大但是种cȝ多的产品的工厂才有意义!内部q要进行很多很多复杂的加工处理才能形成产品Q相反,应该是简单处理就能得C品,q才是简单工厂模式。也是_是很单的处理最l得到某U品,甚至都不负责产品出厂后的l护工作。毕竟,他的定位只是一个小作坊Q用面向对象的思想Q一个类实现一个函数的功能Q?/p>
]]>