网站建设软件 优帮云,竞价网站单页面,电影制作公司,phpcms网站模板最近又在首页看到几篇设计模式相关的学习随笔。回想起来#xff0c;这几年在园子里发布的有关设计模式的随笔都有一个共同的特点。那就是Factory和Singleton居多#xff0c;如果是系列的#xff0c;也往往是从这两个模式开始的。由于能够坚持把《设计模式》中所有模式都写完…
最近又在首页看到几篇设计模式相关的学习随笔。回想起来这几年在园子里发布的有关设计模式的随笔都有一个共同的特点。那就是Factory和Singleton居多如果是系列的也往往是从这两个模式开始的。由于能够坚持把《设计模式》中所有模式都写完的非常少所以基本上也很少见到有关其它模式的随笔。 这种情况也很好理解因为《设计模式》这本书就是按照这个顺序来的。最先讲述的就是Abstract Factory模式于是它排第一也无可厚非排第二的Builder基本不太容易见到第三的Factory Method由于也叫“Factory”所以往往和Abstract Factory放在一起或者干脆就混淆了 第四的Prototype也不是太容易见到第五位的Singleton简单易懂易学易用。而再往后的模式恐怕作者们就没什么耐心学下去了……这可能就是为什么Factory和Singleton出现频率如此之多的原因吧。 《设计模式》已经出版超过15年了到今天已经不是什么新鲜的东西了可以说正在由“绝招”慢慢向着“基本功”转变着。然而这种学习模式的方式方法却实在令人担忧。 Abstract Factory在实际中并不常见因为它需要你有两套并行的继承体系需要对同一个抽象有多于一种的实现方式。这种复杂的系统可以说不是每个领域每个开发人员都能遇到的。在某些特定的领域可能很常见但是在大多数领域并不需要这么复杂的对象创建方法。这就造成了很多人“杀鸡用宰牛刀”用复杂的方式解决不那么复杂的问题。后果是增加了不必要的复杂度给系统维护增加了困难。 另一个模式Singleton由于实现简单意图“似乎”也很明显。被很多人用来作为“优化”的一种方式。通过这种方式来节省内存空间减少对象实例。但是单一实例本身就等同于全局变量而全局变量在几十年前就已经被证明是“反模式”了用另一种形态的全局变量来代替另一种形态的全局变量有什么好处么问题在与Singleton的“意图”并不在于优化而是在于“妥协”。Singleton的目的在于保证对象有单一的实例这是因为对象必须要有单一的实例如果存在多个实例可能会引发错误。也就是说Singleton以牺牲程序的清晰和可维护性来达到保证程序正确的目的。这跟本就和优化八竿子打不着这完全是一种设计上的妥协牺牲一些好处来获取更大的好处。如果仅仅是为了节省几个对象实例而非程序的正确才使用Singleton那就是丢了西瓜拣芝麻。况且节省那几个实例也跟本就不可能对程序的性能有太大的影响特殊领域除外。 人的时间是有限的23个模式也不是都那么常用哪些模式才是最经常用到的才是最值得学习的呢 第一梯队IteratorObserverTemplate MethodStrategy
IteratorLINQforeach这不都是Iterator么。
ObserverMVC的核心.NET中事件就是Observer。
Strategy对同一个行为有不同实现的时候如果考虑将行为的实现委托不是.NET中的委托给另一个类那就用到了Strategy。通过这种方式可以简单的替换算法的实现类来达到更换算法的目的。
代码 class Foo { private IBar bar; public Foo(IBar bar) { this.bar bar; } public void DoSomething() { //some code bar.DoWhatYouWant(); //some code } } class A : IBar { public void DoWhatYouWant() { //do in As way } } class B : IBar { public void DoWhatYouWant() { //do in Bs way } } Template Method一个算法的同一个步骤有不同的实现通过继承来实现。这种方式通过创建子类来改变算法的实现和行为。ASP.NET WebForm中Page的OnInitOnLoad等事件就是Template Method
代码 class Foo { public void DoSomething() { //some code DoWhatYouWant(); //some code } protected abstract void DoWhatYouWant(); } class A: Foo { protected override void DoWhatYouWant(); { //do in As way } } class B: Foo { protected override void DoWhatYouWant(); { //do in Bs way } } 面向对象的一个重要特点就是多态也就是对于同一个动作有不同的行为。Strategry通过委托的方式将一个算法的不同实现委托给其它类Template Method通过继承的方式让子类实现算法的可变部分基类则处理算法的流程和不变部分。近年来组合优于继承的观点已经成为主流因此Strategy的处境频率相对高一些但是Template Method在解决简单问题的时候更好用只要注意继承层次不要太多3就好。 第二梯队AdapterFacadeDecorator
Adapter当你需要使用第三方库但是又不想太依赖于它的API以便于今后在需要时可以方便的切换到另一个库的时候你就需要在你的代码和第三方API之间放置一个抽象层也就需要用Adapter模式了。比如你想使用log4net如果直接在代码中到处引用log4net的API将来有一天需要切换到另一个库比如EntLib你的改动量可就大了去了。如果在一开始就自己设计一个API在代码中使用自己的API再用Adapter模式将log4net的API包装到自己的API中如果有一天想要切换到Entlib只要为EntLib在写一个Adapter就行了。对于IoC框架也是一样的。不过需要注意的是如果第三方库的API接口非常庞大使用Adapter就会很麻烦因为你需要包装太多的东西那么使用Adapter可能就不是一个太好的主意。或许谨慎考虑确定一个不太可能会变化的第三方库更好一些。
Facade基本上用于简化API隐藏细节在一个系统中高层模块调用低层模块时如果低层模块API比较复杂而高层模块并不需要这种复杂度那么加一个Facade可以简化高层模块使用API的难度。
Decorator为一个类的行为增加行为比如ASP.NET MVC中的Action Filter。 第三梯队CommandStateComposite
Command统一接口Undo/Redo。
State当你的model有多种状态model的行为在每种状态下并不一样的时候就需要用State。如果你有多个相似的Switch那也可能意味着需要用State来代替Switch。
CompositeASP.NET WebForm的Page和Control就是一个例子。 这些模式和分类只是凭我的感觉并没有任何实际的数据做支持而我的感觉也只来源于我所接触到的领域和代码。 希望同学们也可以提供自己接触到的代码中最常见到和用到的模式。
