设计模式 王维雄

软件设计模式（DesignPatterns）可复用面向对象软件的基础内部培训王维雄等1/28/2020内容概括1.设计模式介绍2.常用设计模式分别讲（由简入深）3.案例4.交流1/28/2020为什么要学习设计模式？•成为牛人！–为什么一个相似的功能，大牛一会儿就搞定，然后悠闲地品着下午茶逛淘宝；而自己加班加点搞到天亮还做不完。–为什么用户提出需求变更后，大牛只需潇洒地敲敲键盘，改改配置；而自己将代码改了又改，删了又建，几乎晕厥，最后只能推翻重来。–为什么大牛写完的程序测试上线后，几乎完美运行，用户无懈可击；而自己的程序bug重重，改好一个却又引出另一个，按下葫芦浮起瓢，几近崩溃。1/28/2020为什么要学习设计模式？•复用解决方案:通过复用已经公认的设计,能够在解决问题时取得先发优势.避免重蹈覆辙.您是是否也有类似疑虑:几个项目下好。•确定通用术语:开发中的交流和协作都需要共同的词汇其础和对问题的共识.如果交流双方都学习过设计模式交流起来就会十分的舒服.不知道你有没有想表达又表达不清楚的设计思路,或者自己表达得明白但对方又误解了你的意思了呢?看了设计模式你也许可以找到你想要的答案。•改善团队的沟通和个人学习。一个团队一起学习设计模式,有助于团队战斗力的提高。•代码更易于修改与维护。因为设计模式都是久经考验的解决方案,它们的结构都是经过长期的发展形成的，善于应对变化。•模式有助于提高思考层次。学习模式后,就算不用模式中的方法，也会更好的采取更好的策略去解决问题。1/28/20201.1设计模式介绍-什么是设计模式？•设计模式（Designpattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。1970年建筑设计大师亚力山大。软件设计模式这个术语是在1990年代由ErichGamma等4人引入，用来解决同一问题的不同表相。•使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。•项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现在中都有相应的原理来与之对应，每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛应用的原因。1/28/20201.2设计模式介绍-23种设计模式•创建型创建对象时，不再由我们直接实例化对象；而是根据特定场景，由程序来确定创建对象的方式，从而保证更大的性能、更好的架构优势。创建型模式主要有简单工厂模式（并不是23种设计模式之一）、工厂方法、抽象工厂模式、单例模式、生成器模式、原型模式。•结构型用于帮助将多个对象组织成更大的结构。结构型模式主要有适配器模式、桥接模式、组合器模式、装饰器模式、门面模式、亨元模式和代理模式。•行为型用于帮助系统间各对象的通信，以及如何控制复杂系统中流程。行为型模式主要有命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板模式和访问者模式。1/28/20201.3设计模式的六大原则1、单一职责定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。遵循单一职责原的优点有：可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；提高类的可读性，提高系统的可维护性；变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。1/28/20201.3设计模式的六大原则2、里氏代换原则（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的方法。1/28/20201.3设计模式的六大原则3、依赖倒置原则•定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。•问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。•解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。实际需要做到如下3点：•低层模块尽量都要有抽象类或接口，或者两者都有。•变量的声明类型尽量是抽象类或接口。•使用继承时遵循里氏替换原则。1/28/20201.3设计模式的六大原则4、接口隔离原则•定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。•问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。•解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。接口设计原则：•接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。•为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。•提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。1/28/20201.3设计模式的六大原则5、迪米特法则（最少知道原则）•定义：一个对象应该对其他对象保持最少的了解。•问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。•解决方案：尽量降低类与类之间的耦合。设计原则：•只与直接的朋友通信，不要和陌生人说话。•过分的使用该原则，将导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。1/28/20201.3设计模式的六大原则6、开闭原则•定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。•问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。•解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。1/28/20201.4设计模式的六大原则总结•用抽象构建框架，用实现扩展细节–抽象合理（需求变更前瞻性和预见性），派生实现类•单一职责原则告诉我们实现类要职责单一；•里氏替换原则告诉我们不要破坏继承体系；•依赖倒置原则告诉我们要面向接口编程；•接口隔离原则告诉我们在设计接口的时候要精简单一；•迪米特法则告诉我们要降低耦合。•而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。1/28/20201.4设计模式如何学习？•《大话设计模式》•通俗易懂，笔法幽默诙谐•《深入浅出设计模式》•《软件秘笈：设计模式那点事》1/28/2020第一节课3种工厂模式•简单/静态工厂模式•工厂方法模式•抽象工厂模式工厂模式主要是为创建对象提供过渡接口，以便将创建对象的具体过程屏蔽隔离起来，达到提高灵活性的目的。这三种模式从上到下逐步抽象，并且更具一般性。GOF在《设计模式》一书中将工厂模式分为两类：工厂方法模式（FactoryMethod）与抽象工厂模式（AbstractFactory）。将简单工厂模式（SimpleFactory）看为工厂方法模式的一种特例，两者归为一类，简单工厂模式更像一种编程习惯，有必要讲讲。1/28/20203.1简单工厂模式代码无错就是优？案例：计算器1/28/20203.1简单工厂模式•规范后1/28/20203.1简单工厂模式•活字印刷-面向对象•易维护、扩展、灵活•易复用（不是复制）•封装1/28/20203.1简单工厂模式•松耦合，继承1/28/20203.1简单工厂模式•创造实例、结构图对象接口对象工厂客户端1/28/20203.1简单工厂模式//生产产品的工厂类publicclassProductFactory{publicstaticProductgenerateProduct(intwhich){//这个方法是static的if(which==1)returnnewProductA();elseif(which==2)returnnewProductB();}}///调用工厂方法publicClient{publicmethod1(){ProductFactory.generateProduct(1);}}/抽象产品publicinterfaceProduct{.....}//具体产品ApublicProductAimplementProduct{ProductA(){}}//具体产品BpublicProductBimplementProduct{ProductB(){}}1/28/20203.1简单工厂模式总结•不能满足实现功能，应时常考虑简练、易维护、扩展、复用。•简单工场实现了对责任的分割。•优势：让对象的调用者和对象创建过程分离，当对象调用者需要对象时，直接向工厂请求即可。从而避免了对象的调用者与对象的实现类以硬编码方式耦合，以提高系统的可维护性、可扩展性。•缺陷：当产品修改时，工厂类也要做相应的修改，比如要增加一种操作类，如求M数的N次方，就得改case,修改原有类，违背了开放-封闭原则。1/28/20203.2工厂方法模式•解决简单工厂模式的扩展问题1/28/20203.2工厂方法模式•FACTORYMETHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用FactoryMethod模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。•工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。1/28/20203.2工厂方法模式（4个角色）//抽象产品：产品Plant接口publicinterfacePlant{}//具体产品：PlantA，PlantBpublicclassPlantAimplementsPlant{publicPlantA(){System.out.println(createPlantA!);}publicvoiddoSomething(){System.out.println(PlantAdosomething...);}}publicclassPlantBimplementsPlant{publicPlantB(){System.out.println(cr