读《大话设计模式》———?/span>11?/span>无熟人难办事Q——_c特法则
q米Ҏ则(LoDQ,如果两个cM必彼此直接通信Q那么这两个cd不应当发生直接的怺作用。如果其中一个类需要调用另一个类的某一个方法的话,可以通过W三者调用。[J&DP]
本法则强调的是,在类的设计上Q应该尽量保证类之间的松耦合。类之间的关pM应该必须是直接调用的Q而应该是通过抽象来实现各自的功能。就如同人际关系办事情,如果是必要针对个hQ那么没有熟人或者熟Z在,那就办不成了Q这U体制显然不好!比如Q希望政府办的事情,应该不需要知道要谁来处理Q只是统一向政府提个需求,然后他们内部zh处理好!q米Ҏ则,最知识原则?/span>
读《大话设计模式》———?/span>10?/span>模板Ҏ模式
模板Ҏ模式Q定义一个操作中的算法的骨架Q而将一些步聚gq到子类中。模板方法得子cd以不改变一个算法的l构卛_重定义该法的某些特定不聚。[DP]
模板Ҏ的优点:通过把不变的行ؓ攑ֈ父类Qƈ在父cM提供模板ҎQ父cMq可能内部调用一些细节函敎ͼ但是q些l节函数是虚函数Q由不同的子cdC同的具体功能。这样子cd成特定的行ؓQ但是不需要重复的代码?/span>
好了Q简单的模板Ҏ模式Q同h面向对象中承和多态的l合q用。学好了Q?/span>
读《大话设计模式》———?/span>9?/span>历复?/span>—?/span>原型模式
原型模式Q用原型实例指定创徏对象的种c,q且通过拯q些原型创徏新的对象。[DP]
原型模式其实是从一个对象再创徏另外一个可定制的对象,而且不需知道M创徏的细节。看到这些说明,我想q是不是可以理解为c++中的拯构造函数呢Q这可能是需求中最常见的模式了?/span>
如果从这个角度理解,无疑的,q个模式可以通过了。只是他告诉我们Q设计的时候考虑扚w生的情况,所以需要提供复制的Ҏ。至于文中所讲的复制和深复Ӟ好像C#中才考虑q个问题Qc++中指针引用等是必要特定处理的。学好了Q?/span>
读《大话设计模式》———?、雷锋依然在人间——工厂方法模?/font>
单工厂模式、工厂方法模式,q两者的区别我想思义Q前者讲的是q个模式用到一个简单工厂,但是后者强调的是工厂方法,其实意思就是该模式中工厂设计很重要?/font>
其实理解了简单工厂,基本上只要再E微看一下工厂模式的设计Q就很容易理解这两个模式。不q,g工厂Ҏ模式是简单工厂模式的改进版,单工厂没有存在的必要。但是事实ƈ非如此,在扩展不l常的时候,一个简单工厂就可以了。但是要是经常有怼功能的扩展需求,那么工厂Ҏ模式p有hg些?/font>
在代码Ş式上Q简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断Q根据客L的选择条g动态实例化相关的类Q对于客L来说Q去除了与具体品的依赖。但是,工厂Ҏ是把单工厂的内部逻辑判断Ud了客L代码来进行。所以,惌增加功能Q就同时需要修改客L代码。但是这样代码结构还是很清晰的,所以两者各有千U!
读《大话设计模式》———?、会修电脑不会修攉机?——依赖倒{原则
电脑比收x单吗Qؓ什么拆开两者,很明显,攉机看hq要比电脑更复杂呢?原来Q好的架构好的设计在哪里都是通用的!电脑各部件缺一不可Q但是绝不是只针Ҏ一个或者某一cM品,所有不同品的厂商都只服从一个统一的标准,q样Q我们就看不出电脑中哪一个是高层了。CPUQ内存?或者主板?。。。都不是Q谁也不依赖谁,依赖的是一个统一的接口标准!
依赖倒{原则Q抽象不应该依赖l节Q细节应该依赖抽象。具体到一个实际问题编E,应该是定义好的接口,q个接口不属于哪一个具体的东西Q应该是一个高层的抽象Q然后就是针Ҏ口编E,而不要对实现~程?/font>
讲到q里Q似乎世界的一切问题都q刃而解Q一切显得是那样的轻而易举!慢!一定不要自负的轻视ҎQ好Q谁都很听话的服从这个抽象接口,那么q个抽象接口怎么来?一切都在变Q难道这个抽象类是可以q背q个哲学上绝对真理的特例家伙Q他可能自n都要不停的变Q完了,到哪里去找这样一Ҏ呀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另一个是说对于更Ҏ闭的?/font>
本原则经q作者精辟的阐述Q马上就让我们在哲学上对一些问题的看法豁然开朗:看v来两个完全抵触的东西Q利用扩展与闭原则p很好的解冟뀂什么东西必d闭,什么东西可以扩展?L和业l是必须关闭修改的,但是制度却是可以扩展开攄Q难道这仅仅是一U计机理论吗?q简直是处事之道Q?/font>
如何应对变化Q——除非你_强大Q所有的人和事都无条件的服从你的Q否则就需要面Ҏ法预料的变化。事实上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个模式应该是最Ҏ理解的一个模式了。不q解释意义还是比较有深度的:有一个类而言Q应该仅有一个引起它变化的原因[ASD]。职责越单一Q功能就独立。也没有复杂度Q就更好l护Q也更利于复用了?/font>
作者对q个模式的运用和解释已经很清楚了“软g设计真正要做的许多内容,是发现职责q把那些职责怺分离[ASD].其实要去判断是否应该分离出类来,也不难,那就是如果你能够惛_多于一个的动机L变一个类Q那么这个类具有多于一个的职责[ASD],应该考虑cȝ职责分离?#8221;
读《大话设计模式?/font>
----------------2?/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汗!然而,大鸟后面的那些一针见血的话同时也让我进入了沉思。。。当我们发现自己好不Ҏ掌握了一样东西,我们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利用的Ҏ是将{略模式与简单工厂模式结合v来用Q当然与之对比的单工厂模式显然稍逊一{V但是我个h的观Ҏ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>