面向对象模式设计.docx

第一张PPT1. 什么是设计模式？设计模式是对软件工程是的基本要求 设计模式在生活中随处可见在房屋建设上不同的地区房屋建设有不同的风格，中式风格或欧式风格，不同的风格有不同的框架核结构 不同的武功也有不同的招式，不同的模式 模式不是死的 是经验丰富的大师有自己的模式 我们应该理解模式从而创造自己的模式这是关于模式最经典的定义，作者是建筑大师Christopher Alexander。(克里斯托夫亚历山大, ,其卓越才能与贡献不仅表现模式：每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。于建筑,在室内、计算机、信息产业结构、家具设计甚至哲学方面都卓有建树。他被广泛认为是计算机科学模式语言运动之父其创立的“模式语言”理论不仅在建筑设计方法论研究上具有划时代的意义,也对计算机等领域产生了重大影响。许多人质疑Alexander是站在建筑学的角度，其观点并未被广泛接受。“四人帮”的著作设计模式对软件模式的影响比Alexander的著作要大得多，而设计模式一书的四位作者中的三位在写书之前都没有读过Alexander的著作。建筑学本科学历和数学硕士学历。在哈佛研读他的博士学位)如果是第一次看到这句话，多数人会觉得有些抽象难懂。其实“模式”两个字只是一个代号，就像我叫李守宏，如果我改叫李四也没什么问题，只是我更喜欢李守宏这个名字，所以从Christopher开始，有了“模式”这个词，人们也都把关于“重复发生的问题的描述和解决办法”统称为模式。“模式”这个词是不局限于软件开发行业的，它几乎无处不在，它其实就是一种经验的积累，就象大多数人的教育经历都是从小学到初中再到高中再到大学，这也是一种模式，是中国的教育模式；现在越来越火的出国热，也是另一种模式，海外留学模式。因为GOF的设计模式：可复用面向对象软件的基础一书描述的23种经典设计模式，奠定了模式在软件行业的地位，从此人们提到“设计模式”就是默指“面向对象设计模式”，但是模式绝对不局限于软件行业，即使在软件行业，也不局限于GOF描述的23种设计模式，例如我们常用的MVC等。因为模式是一种经验的积累和总结，所以通过模式，我们可以站在巨人的肩膀上去思考问题、解决问题，熟练使用设计模式可以提高我们的工作效率，改善产品质量，最终带来经济效益。因此对于任何想开发出灵活高效、健壮的软件产品的个人或团体，熟练掌握并正确使用设计模式都是必须掌握的基本技能。2.设计模式的优点使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石脉络，如同大厦的结构一样。，设计模式有助于对框架结构的理解，成熟的框架通常使用了多种设计模式,如果你熟悉这些设计模式，毫无疑问，你将迅速掌握框架的结构，我们一般开发者如果突然接触EJBJ2EE等框架，会觉得特别难学，难掌握，那么转而先掌握设计模式，无疑是给了你剖析EJB或J2EE系统的一把利器。3 。模式的要素单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。设计模式的原则看了设计模式,最后看的总是感觉他们有很大的相似之处,就像是世界上万事万物都有其生存法则一样.仔细分析其实设计模式都是围绕一条主线来的。这就是设计模式的原则。你可以把设计原则比作一门语言。把设计模式当作这门语言编写出来的程序。如果你精通了语言剩下的编码就是很简单的事情了.对于层出不穷的设计模式,比如Gof的23种设计模式,MVC模式,到底应该怎样去学习,如果我们单纯的一个一个的研究设计模式本身,那么只能是越看越多,越来越乱.其实我们只要抓住设计模式的原则,就能很清楚的分析出它为什么会这么做.下面我来分析一下设计模式原则,以及在设计模式中的体现一:设计模式的核心原则是:开-闭原则( Open - Closed Principle 缩写:OCP ),一切的一切都是围绕着开-闭原则展开的开闭原则:说软件实体(类,模块,函数等)应该可以扩展,但是不可以修改 DH.意思是,在一个系统中,对于扩展是开放的,对于修改是关闭的,一个好的系统是在不修改源代码的情况下,可以扩展你的功能.而实现开闭原则的关键就是抽象化.在开-闭原则中,不允许修改的是抽象的类或者接口,允许扩展的是具体的实现类,抽象类和接口在开-闭原则中扮演着极其重要的角色.即要预知可能变化的需求.又预见所有可能已知的扩展.所以在这里抽象化是关键!当然对于修改,我们不可能完全避免,也不可能完全预知到未来的变化.所以我们要做到尽量去不要修改,或者少的修改就能达到我们的目标.例如:对于简单工厂模式.我们有能力预知到未来可能添加计算,所以,我们将运算类抽象出来.为了以后方便扩展.这里的运算类是不可以修改的.但是对于他的子类.我们是可以扩展的.二:依赖倒转原则A:高层模块不应该依赖底层模块 B:抽象不应该依赖细节,细节应该依赖抽象DH就是说要依赖抽象,而不要依赖具体的实现.如果说开闭原则是目标,依赖倒转原则是到达开闭原则的手段.如果要达到最好的开闭原则,就要尽量的遵守依赖倒转原则.可以说依赖倒转原则是对抽象化的最好规范!通俗的说就是只有抽象的东西才是最稳定的，也就是说，我们依赖的是它的稳定。如果将来“抽象”也不稳定了，那么谁稳定我跟谁，其实说白了不就是傍大款吗！比如我们在观察者模式中(Observer)这里的通知者,就不应该是具体.因为我们应当考虑到如果前台那里换了人怎么办?这个通知还可以是其他人通知.比如老板要通知去做某件事怎么办?为了让大家都能用这个通知.所以要设置成抽象的.这里的前台,老板都要依赖这个通知.也就是说.细节要依赖抽象.三:里氏代换原则:定义:子类型必须能够替换它们的父类型DH这个原则是对继承的一个约束,也就是说,继承中子类严格满足is a 的关系.这里我个人有深刻的体会.尤其是在看别人的UML图的时候.对你帮助很大.当你看到一个继承的时候.要习惯性的把他的父类和子类看成一个整体.这样会有助于你去理解各个类之间的关系.因为根据里氏代换原则.父类出现的地方子类也可以出现.比如我们再看工厂模式的时候,你看到有的书上简单工厂类关联着运算父类.有的书上是关联着运算类的子类.其实仔细想想他们都没有错,父类和子类的关联都是一样的,父类能出现的地方,子类就可以出现.在设计模式中的体现:设计模式中所有继承都能体现着这一原则.我举一个不符合原则的例子.四:单一职能原则再通俗一点地说就是，不该你管的事情你不要管，管好自己的事情就可以了，多管闲事害了自己也害了别人。(当然这里说的多管闲事跟见义勇为是两回事，我们提倡见义勇为！)这个就是说,一个类尽量做到了功能单一,比如在mvc中,判断数据的类和添加数据库的类一定要分开.单一职能的不是说职能多了我们实现不了,是为了后期的测试维护,每个类的很单一,我们找错误的时候就可以一步到位.添加新的功能的时候,也不用牵扯到很多的类.在设计模式中的体现:烤肉者就管烤肉,他也不管收钱,也不管记录.这样把地摊上的烤肉者分成服务员和烤肉的人.让职责单一.不容易出错.上边的都是几个原则,下面介绍两个法则:(1)迪米特法则:系统中的类,尽量不要与其他类互相作用,减少类之间的耦合度,因为在你的系统中,扩展的时候,你可能需要修改这些类,而类与类之间的关系,决定了修改的复杂度,相互作用越多,则修改难度就越大,反之,如果相互作用的越小,则修改起来的难度就越小.例如A类依赖B类,则B类依赖C类,当你在修改A类的时候,你要考虑B类是否会受到影响,而B类的影响是否又会影响到C类.如果此时C类再依赖D类的话,呵呵,(2)接口隔离法则:这个法则与迪米特法则是相通的,迪米特法则是目的,而接口隔离法则是对迪米特法则的规范.为了做到尽可能小的耦合性,我们需要使用接口来规范类,用接口来约束类.要达到迪米特法则的要求,最好就是实现接口隔离法则,实现接口隔离法则,你也就满足了迪米特法则.这里也体现了一个依赖原则,要尽量依赖抽象,不要依赖具体.设计模式中的体现:高层模块依靠接口和底层模块依赖.设计模式分为三种类型，共23种。一， 有一次我买了一个我很喜欢的杯子，然后我不管喝水，喝茶，还是喝酒，都用这一个杯子。此杯子在具有唯一性。于是我创建这个杯子的时候就想到用单例模式由于有些饮料需要细细品尝，比如说咖啡，于是我又买来了勺子，但是由于勺子这东西不是经常用，有时候不见了忘记了，每次都重新买一把，后来我就有了几把勺子（单例模式扩展用途，控制用户生成类的个数）：不知为何我和杯具结下了不解之缘，后来做了杯具商人，专门买各种各样的杯具生意，我要生产一批不同类型的杯具，于是乎我找到了一个专门生产杯具的工厂-简单工厂盛水-玻璃杯盛水-木杯 盛水-塑料杯); 盛水-金属杯简单工厂需要我口头告诉工厂我生产的类型，由于订单经常变，容易混淆杯具的类型，于是乎后来我们签订和合约，每次需要不同类型杯具的时候，我就将需要杯具的类型写在订单上(对应程序的配置文件中)-反射工厂：五，随着生意越做越大，订单的处理也变得不是很方便，一个工厂处理了所有的生产杯具的工作，简单工厂已经力不从心了，此时我们不得不针对每种不同的杯具选择不同的工厂为我们生产-工厂方法：六，生意是越做越大，光卖杯具已经满足不了我的胃口，于是乎想到卖勺子搭配，勺子和杯子的搭配这个得讲究，玻璃对玻璃，木头对木头这样子搭配，显得统一，但是如果勺子杯子分不同的厂来生产，这样子在我们货源中就会产生很多很