软件工程-第9章第3节

软件工程西安电子科技大学出版社9.3面向对象的程序设计模式9.3.1程序设计模式程序设计模式分为创建型模式、结构型模式、行为型模式三种。1．创建型模式创建型模式分为五种：工厂模式、抽象工厂模式、单例模式、建造者模式、原型模式。(1)工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类，FactoryMethod使一个类的实例化延迟到了子类。9.3.1程序设计模式(2)抽象工厂模式：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们的具体类。(3)单例模式：保证一个类只有一个实例，并提供一个访问它的全局访问点。(4)建造者模式：将一个复杂对象的构建与它的示相分离，使得同样的构建过程可以创建不同的表示。(5)原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型来创建新的对象。9.3.1程序设计模式2.结构型模式结构型模式共有七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。(1)适配器模式：将一类的接口转换成客户希望的另外一个接口，适配器使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。(2)装饰器模式：动态地给一个对象增加一些额外的职责，就增加的功能来说，装饰器模式相比生成子类更加灵活。9.3.1程序设计模式(3)代理模式：为其他对象提供一种代理以控制对这个对象的访问。(4)外观模式：为子系统中一组接口提供一致的界面，此模式定义了一个高层接口，该接口使得子系统更加容易使用。(5)桥接模式：将抽象部分与它的实现部分相分离，使它们可以独立地变化。(6)组合模式：将对象组合成树形结构以表示部分整体的关系，组合使得用户对单个对象和组合对象的使用更具有一致性。(7)享元模式：运用共享技术有效地支持大量细粒度的对象。9.3.1程序设计模式3.行为型模式行为型模式共有11种：迭代器模式、观察者模式、模板方法、命令模式、状态模式、策略模式、职责链模式、中介者模式、访问者模式、解释器模式、备忘录模式。(1)迭代器模式：提供一种方法，顺序访问一个聚合对象的各个元素，而又不需要暴露该对象的内部表示。(2)观察者模式：定义对象间一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知自动更新。9.3.1程序设计模式(3)模板方法：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中，模板方法使得子类可以不改变算法的结构即可重定义该算法的某些特定步骤。(4)命令模式：将一个请求封装为一个对象，从而可以用不同的请求对客户进行参数化，对请求排队和记录请求日志，以及支持可撤销的操作。(5)状态模式：允许对象在其内部状态改变时改变他的行为。对象看起来似乎改变了他的类。(6)策略模式：定义一系列的算法，把它们一个个封装起来，并使它们可以互相替换，本模式使得算法可以独立于使用它们的客户。9.3.1程序设计模式(7)职责链模式：使多个对象都有机会处理请求，从而避免请求的送发者和接收者之间的耦合关系(8)中介者模式：用一个中介对象封装一些列的对象交互。(9)访问者模式：表示一个作用于某对象结构中的各元素的操作，使得可以在不改变各元素类的前提下定义作用于这个元素的新操作。(10)解释器模式：给定一个语言，定义其文法的一个表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。(11)备忘录模式：在不破坏对象的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。9.3.2设计原则1．开发封闭原则开发封闭原则也称开闭原则，就是让设计对扩展开放，对修改关闭。开闭原则的本质是指当一个设计中增加新的模块时，不需要修改现有的模块。在给出一个设计时，应当首先考虑到用户需求的变化，将应对用户变化的部分设计为对扩展开放，而设计的核心部分是经过精心考虑之后确定下来的基本结构，这部分应当是对修改关闭的，即不能因为用户的需求变化而再发生变化，因为这部分不是用来应对需求变化的。9.3.2设计原则如果设计遵守了开闭原则，那么这个设计一定是易维护的，因为在设计中增加新的模块时，不必去修改设计中的核心模块。遵守了开闭原则，则系统的核心类可以兼容任何后来扩充的类。9.3.2设计原则当设计某些系统时，经常需要面向抽象来考虑系统的总体设计，不需要考虑具体类，这样就容易设计出满足开闭原则的系统，在程序设计好后，首先对abstract类的修改关闭，否则，一旦修改了abstract类，比如，为它再增加一个abstract方法，那么abstract类所有的子类都需要做出修改；应当对增加abstract类的子类开放，即在程序中再增加子类时，不需要修改其他面向抽象类而设计的重要类。9.3.2设计原则开闭原则工厂模式是对具体产品进行扩展，有的项目可能需要更多的扩展性，要对这个工厂模式也进行扩展，那就成了“抽象工厂模式”。9.3.2设计原则2.里氏代换原则里氏代换原则是由麻省理工学院计算机科学实验室的Liskov女士在1987年的OOPSLA大会上发表的一篇文章《DataAbstractionandHierarchy》提出来的，主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中所蕴涵的原理。9.3.2设计原则2002年，软件工程大师罗伯特·C·马丁(RobertC.Martin)出版了一本《敏捷软件开发：原则、模式和实践(AgileSoftwareDevelopmentPrinciplesPatternsandPractices)》，在文中他把里氏代换原则最终简化为一句话—子类必须能够替换成它们的基类。我们把里氏代换原则解释得更完整一些：在一个软件系统中，子类应该可以替换任何基类能够出现的地方，并且经过替换以后，代码还能正常工作。9.3.2设计原则3．单一职责原则单一职责原则又称单一功能原则。它规定一个类应该只有一个发生变化的原因。该原则由RobertC.Martin于《敏捷软件开发：原则、模式和实践》一书中给出。马丁表示此原则是基于汤姆·狄马克(TomDeMarco)和MeilirPage-Jones的著作中的内聚性原则发展出来的。9.3.2设计原则所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。如果一个类承担的职责过多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。而如果想要避免这种现象的发生，就要尽可能地遵守单一职责原则。此原则的核心就是解耦和增强内聚性。9.3.2设计原则4.依赖倒转原则所谓依赖倒转原则(也称依赖倒置原则)，就是不论高层组件和低层组件都应该依赖于抽象，而不是具体实现类。这听起来更像是“针对接口编程，而不是针对实现编程”，但是这里依赖倒转原则更强调“抽象”的概念，不要让高层组件依赖低层组件，更不能依赖具体实现类，都要依赖于抽象。依赖倒转原则的核心在于“面向接口编程”，目的在于“解耦”。9.3.2设计原则依赖倒转原则中的倒转是指我们的思想要和一般的“自顶向下”结构化设计思想相反。面向过程的设计方法是从顶端，然后到实现类，例如，简单工厂模式中我们让工厂生产产品，但是又不想让工厂和具体实现类存在任何关系，否则就对具体实现类产生了依赖，这是我们不希望看到的结果。这时候我们就应该将思想倒转一下，不要从顶端开始，我们从具体的实现类开始，看看能够抽象出什么，然后一切都依赖抽象来进行，这样就与我们的目标相近了。9.3.2设计原则5.接口隔离原则接口隔离原则要求客户端不应该依赖它不需要的接口；类间的依赖关系应该建立在最小的接口上。例如，现在有一个接口，作用是编写一个网站，其中有两个方法：voidWriteWebsiteUI();//实现UI界面voidWriteWebsiteLogic();//实现逻辑代码9.3.2设计原则经验丰富的程序员可以把实现界面和后台逻辑一起实现。但是没有经验的程序员可能不管界面，那么这样一来就违反了单一职责原则和里氏替换原则，所以我们将编写网站的接口拆分成IWriteWebsiteUI及IWriteWebsiteLogic两个接口，这样的话，经验丰富的程序员实现这两个接口，而对应职责的程序员实现各自的接口就可以了。这样，在接口的复用上也达到了想要的效果。9.3.2设计原则单一职责原则与接口隔离原则的异同点在于：相似之处都是起到了瘦身的作用，减少耦合性；不同的地方当然是职责是一种能力，可能可以处理某一样事物但需要很多个接口。接口与职能还是有差别的。谢谢！西安电子科技大学出版社感谢谢谢，精品课件搜集