《设计模式》.ppt

该【《设计模式》 】是由【相惜】上传分享，文档一共【39】页，该文档可以免费在线阅读，需要了解更多关于【《设计模式》 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。软件设计模式〔DesignPatterns〕(由简入深)?成为牛人!为什么一个相似的功能,大牛一会儿就搞定,然后悠闲地品着下午茶逛淘宝;而自己加班加点搞到天亮还做不完。为什么用户提出需求变更后,大牛只需潇洒地敲敲键盘,改改配置;而自己将代码改了又改,删了又建,几乎晕厥,最后只能推翻重来。为什么大牛写完的程序测试上线后,几乎完美运行,用户无懈可击;而自己的程序bug重重,改好一个却又引出另一个,按下葫芦浮起瓢,几近崩溃。精选课件为什么要学****设计模式?复用解决方案:通过复用已经公认的设计,:几个工程下好。确定通用术语:,或者自己表达得明白但对方又误解了你的意思了呢?看了设计模式你也许可以找到你想要的答案。改善团队的沟通和个人学****一个团队一起学****设计模式,有助于团队战斗力的提高。代码更易于修改与维护。因为设计模式都是久经考验的解决方案,它们的结构都是经过长期的开展形成的,善于应对变化。模式有助于提高思考层次。学****模式后,就算不用模式中的方法,也会更好的采取更好的策略去解决问题。-什么是设计模式?设计模式〔Designpattern〕是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。1970年建筑设计大师亚力山大。软件设计模式这个术语是在1990年代由ErichGamma等4人引入,用来解决同一问题的不同表相。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样。工程中合理的运用设计模式可以完美的解决很多问题,每种模式在现在中都有相应的原理来与之对应,每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的核心解决方案,这也是它能被广泛应用的原因。-23种设计模式创立型 创立对象时,不再由我们直接实例化对象;而是根据特定场景,由程序来确定创立对象的方式,从而保证更大的性能、更好的架构优势。创立型模式主要有简单工厂模式〔并不是23种设计模式之一〕、工厂方法、抽象工厂模式、单例模式、生成器模式、原型模式。结构型 用于帮助将多个对象组织成更大的结构。结构型模式主要有适配器模式、桥接模式、组合器模式、装饰器模式、门面模式、亨元模式和代理模式。行为型 用于帮助系统间各对象的通信,以及如何控制复杂系统中流程。行为型模式主要有命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板模式和访问者模式。、单一职责定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。问题由来:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障。解决方案:遵循单一职责原那么。分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责P2功能。这样,当修改类T1时,不会使职责P2发生故障风险;同理,当修改T2时,也不会使职责P1发生故障风险。遵循单一职责原的优点有:可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多;提高类的可读性,提高系统的可维护性;变更引起的风险降低,变更是必然的,如果单一职责原那么遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。、里氏代换原那么〔LiskovSubstitutionPrinciple〕子类可以扩展父类的功能,但不能改变父类原有的功能定义1:如果对每一个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换成o2时,程序P的行为没有发生变化,那么类型T2是类型T1的子类型。定义2:所有引用基类的地方必须能透明地使用其子类的对象。问题由来:有一功能P1,由类A完成。现需要将功能P1进行扩展,扩展后的功能为P,其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成,那么子类B在完成新功能P2的同时,有可能会导致原有功能P1发生故障。解决方案:当使用继承时,遵循里氏替换原那么。类B继承类A时,除添加新的方法完成新增功能P2外,尽量不要重写父类A的方法,也尽量不要重载父类A的方法。、依赖倒置原那么定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。问题由来:类A直接依赖类B,假设要将类A改为依赖类C,那么必须通过修改类A的代码来达成。这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责根本的原子操作;假设修改类A,会给程序带来不必要的风险。解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,那么会大大降低修改类A的几率。实际需要做到如下3点:低层模块尽量都要有抽象类或接口,或者两者都有。变量的声明类型尽量是抽象类或接口。使用继承时遵循里氏替换原那么。、接口隔离原那么定义:客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,那么类B和类D必须去实现他们不需要的方法。解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原那么。接口设计原那么:接口尽量小,但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实,但是如果过小,那么会造成接口数量过多,使设计复杂化。所以一定要适度。为依赖接口的类定制效劳,只暴露给调用的类它需要的方法,它不需要的方法那么隐藏起来。只有专注地为一个模块提供定制效劳,才能建立最小的依赖关系。提高内聚,减少对外交互。使接口用最少的方法去完成最多的事情。精选课件