必须知道的设计模式

引言

设计模式是面向对象思想的集大成,GOF在其经典著作中总结了23种设计模式,又可分为:创建型、结构型和行为型3个大类。对于软件设计者来说,一般的过程就是在熟练掌握语言背景的基础上,了解类库的大致框架和常用的函数和接口等,然后多再在百般锤炼中,提高对软件设计思想的认识。

软件设计者要清楚自己的定位和方向,一味的沉溺于技术细节的思路是制约个人技术走向成熟的毒药。因此,学习软件设计,了解软件工程,是每个开发人员必备的一课。笔者在此不想详细的描述各个设计模式的细节,我想google和baidu上的资料已经多如牛毛了。而且,争取的学习方法也不是了解所有的设计模式就可以无敌于天下。我所强调的学习方法就是在熟练掌握基本要素的基础上,了解大致的框架。这一条不仅是学习类库的方法,对设计模式来说是可行的。同时,切记的是在平时的积累中,不断的体会和实践。因此,本文的目的就是将23种模式中,必须掌握的几个最关键、最常用的设计模式,做以总结和简述。

1 Factory Pattern

上榜理由:将程序中创建对象的操作,单独出来处理,大大提高了系统扩展的柔性,接口的抽象化处理给相互依赖的对象创建提供了最好的抽象模式。

2 Facade Pattern

上榜理由:将表现层和逻辑层隔离,封装底层的复杂处理,为用户提供简单的接口,这样的例子随处可见。门面模式很多时候更是一种系统架构的设计,在我所做的项目中,就实现了门面模式的接口,为复杂系统的解耦提供了最好的解决方案。

3 Command Pattern

上榜理由:将请求封装为对象,从而将命令的执行和责任分开。通常在队列中等待命令,这和现实多么的相似呀。如果你喜欢发号施令,请考虑你的ICommond吧。

4 Strategy Pattern

上榜理由:策略模式,将易于变化的部分封装为接口,通常Strategy 封装一些运算法则,使之能互换。Bruce Zhang在他的博客中提到策略模式其实是一种“面向接口”的编程方法,真是恰如其分。

5 Iterator Pattern

上榜理由:相信任何的系统中,都会用到数组、集合、链表、队列这样的类型吧,那么你就不得不关心迭代模式的来龙去脉。在遍历算法中,迭代模式提供了遍历的顺序访问容器,GOF给出的定义为:提供一种方法访问一个容器(container)对象中各个元素,而又不需暴露该对象的内部细节。.NET中就是使用了迭代器来创建用于foreach的集合。

6 Adapter Pattern

上榜理由:在原类型不做任何改变的情况下,扩展了新的接口,灵活且多样的适配一切旧俗。这种打破旧框框,适配新格局的思想,是面向对象的精髓。以继承方式实现的类的Adapter模式和以聚合方式实现的对象的Adapter模式,各有千秋,各取所长。看来,把它叫做包装器一点也不为过,

7 Observer Pattern

上榜理由:定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。观察者和被观察者的分开,为模块划分提供了清晰的界限。在.NET中使用委托和事件可以更好的实现观察者模式,事件的注册和撤销不就对应着观察者对其对象的观察吗?

8 Bridge Pattern

上榜理由:把实现和逻辑分开,对于我们深刻理解面向对象的聚合复用的思想甚有助益。

9 Singleton Pattern

上榜理由:改善全局变量和命名空间的冲突,可以说是一种改良了的全局变量。这种一个类只有一个实例,且提供一个访问全局点的方式,更加灵活的保证了实例的创建和访问约束。.NET Frameeork已经封装了Singleton类,我们拿来即可。

总结

仁者见仁。以上只是笔者一家之言,更重要的真知灼见皆来源于实践,设计思想和模式的应用也来源于不断的学习和反复,我也将一如既往。此文只是开端,未来才是不断的探索。

时间: 2024-08-03 15:09:37

必须知道的设计模式的相关文章

Android UI设计的幻灯片:新的UI设计模式

文章描述:谷歌Android UI设计技巧:新的UI设计模式. 本系列文章原是Android的官方开发者博客的一份Android UI设计的幻灯片,51CTO的译者将这份教程5部分进行翻译整理,希望对Android开发者能有帮助.本文为<谷歌Android UI设计技巧>第四部分:新的UI设计模式. 本文为<谷歌Android UI设计技巧>第四部分:新的UI设计模式. [1] [2]  下一页

您的设计模式,我们的设计模式 java设计模式

http://download.csdn.net/download/yangxin00000000/3212729   您的设计模式,我们的设计模式 java设计模式

[Head First设计模式]云南米线馆中的设计模式——模版方法模式

系列文章 [Head First设计模式]山西面馆中的设计模式--装饰者模式 [Head First设计模式]山西面馆中的设计模式--观察者模式 [Head First设计模式]山西面馆中的设计模式--建造者模式 [Head First设计模式]饺子馆(冬至)中的设计模式--工厂模式 [Head First设计模式]一个人的平安夜--单例模式 [Head First设计模式]抢票中的设计模式--代理模式 [Head First设计模式]面向对象的3特征5原则 [Head First设计模式]鸭子

[设计模式实践之路](1)单例模式

[简介] 单例模式(Singleton)保证一个类仅有一个实例,并提供一个访问它的全局访问点.      实现单例模式的一个最好的方法就是让类自身负责保存它的唯一实例.这个类可以保证没有其他实例可以创建,并且它可以提供一个访问该实例的方法. [特点] 单例模式具有一下特点: 单例类只有一个实例 单例类必须自己创建自己的唯一实例 单例类必须给所有其他对象提供这一实例 [分类] 主要的就是懒汉单例,饿汉单例 [懒汉单例] package Mode; /** * Java设计模式之单例模式 * @au

设计模式[1]-Memento

开始研究设计模式.一个非常perfect的设计模式示意图http://www.mcdonaldland.info/2007/11/28/40/ Type: Behavioral Memento:模式在不破坏封装性的情况下,捕获一个对象的内部状态传递到外部,使得稍后可以将该对象恢复到这个状态.代码参考了http://www.cppblog.com/converse/archive/2006/08/09/11063.html #include <iostream> #include <str

设计模式之观察者模式(关于OC中的KVO\KVC\NSNotification)

学习了这么久的设计模式方面的知识,最大的感触就是,设计模式不能脱离语言特性.近段时间所看的两本书籍,<大话设计模式>里面的代码是C#写的,有一些设计模式实现起来也是采用了C#的语言特性(C#的API,抽象类,在OC中是没有抽象类.没有多继承关系),<设计模式之禅>里面的代码是JAVA写的,与OC差距也是比较大. 但是我想,这些都不是问题,学习设计模式主要学习的是其中的思想,并将之改造成自己所熟悉语言的模式,大同小异.所需要注意的是,在学习的过程中,将之与语言结合起来,多思考.多实践

关于23种设计模式的有趣见解(转载)

好东西不得不转 在网上看见了这篇文章,作者以轻松的语言比喻了java的32种模式,有很好的启发作用. 创建型模式 1.FACTORY-追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说"来四个鸡翅"就行了.麦当劳和肯德基就是生产鸡翅的Factory 工厂模式:客户类和工厂类分开.消费者任何时候需要某种产品,只需向工厂请求即可.消费者无须修改就可以接纳新产品.缺点是当产品修改时,工厂类也要做相应的修改.如:

工厂设计模式 Factory

Factory 主要用来实例化有共同接口的类,工厂模式可以动态决定应该实例化那一个类. 例如:汽车销售商场 该模式将创建对象的过程放在了一个静态方法中来实现.在实际编程中,如果需要大量的创建对象,该模式是比较理想的. public class Demo1 { public static void main(String[] args) { System.out.println("买宝马"); Car bmw = CarFactory("BMW"); bmw.run(

《设计模式》学习笔记2——简单工厂模式

定义 简单工厂模式并不属于GoF(Gang of Four四人组)23中设计模式,有些地方的解释说因为简单工厂模式太简单,所以23中设计模式就没有单独列出. 但是简单工厂模式在实际的应用中却很常用,因此在刘伟老师的<设计模式>一书中就还是列了出来. 简单工厂模式引用书中的定义如下: 简单工厂模式(Simple Factory Pattern):定义一个工厂类,它可以根据参数的不同返回不同类的实例,被创建的实例通常都具有共同的父类.因为在简单工厂模式中用于创建实例的方法是静态(static)方法

设计模式概要

看设计模式有段时间了,但是有没有多少机会使用.结果陷入到了"看了忘忘了再看"的恶性循环, 虽然我们本来就应该温故知新的.我们能不能找到一些更好的方法呢? 有一种叫做"自顶向下"的思路我们都很熟悉的可以拿来试试. 设计的原则要学设计模式,设计的原则就不得不学.这里只做简单的介绍.需要更加详细的说明可以参考吕震宇的博客,非常的不错!1. 单一职责原则(The Single-Responsibility Principle) 一个类只有一个引起变化的原因.可以想象,如果一