软件设计模式论文模板

1软件设计模式的浅析摘要：如果说，数学是思维的体操，那设计模式，就是面对对象编程思维的体操。通过学习软件设计模式可以让你找到“封装变化”、“对象间松散耦合”、“针对接口编程”的感觉，从而设计出易维护、易扩展、易复用、灵活性好的程序。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。关键词：设计模式；设计方案；面向对象概述软件设计模式是软件工程课程学习课程中重要的一门科目，本课由高亮老师带领我们学习，书本教材参考的是清华大学出版社出版的大话设计模式，本书以大鸟，菜鸟两个虚构的人物之间的对话，有趣的讲解了23种设计模式。本书通篇都是以情景对话的形式，用一个又一个的小故事或编程事例来组织的，共分为四个部分，第一部分三面向对象的意义和好处以及几个重要的设计原则，通过小菜的面试失败引出，第二部分是详细讲解了23个设计模式：第三部分是对设计模式的总结，利用小菜梦到的超级模式大赛的场景，把所有的面向对象和模式概念都拟人化来趣味性的总结设计模式之间的异同和关键点，第四部分是附录，主要是针对对面向对象不熟悉的读者的一个补充，通过一个例子的演变介绍了类。封装，继承，多态，接口，事件的概念。本门主要详细介绍三种设计模式和探讨他们之间的关联。观察者模式、抽象工厂模式，状态模式。[1]进入90年代，面向对象范型（OO范型）受到了研究界和工业界的普遍重视并获得广泛应用。OO为软件测试提出了很多新问题，但当前对OO软件测试的研究还很薄弱。能否找到有效的适用于OO软件的测试技术，很大程度上决定着OO能否真正走向成功。[2]观察者模式概述：观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。将一个系统分割成一个一些类相互协作的类有一个不好的副作用，那就是需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合，这样会给维护、扩展和重用都带来不便。观察者就是解决这类的耦合关系的。模式中的角色1抽象主题（Subject）：它把所有观察者对象的引用保存到一个聚集里，每个主题都可以有任何数量的观察者。抽象主题提供一个接口，可以增加和删除观察者对象。2具体主题（ConcreteSubject）：将有关状态存入具体观察者对象；在具体主题内部状态改2变时，给所有登记过的观察者发出通知。3抽象观察者（Observer）：为所有的具体观察者定义一个接口，在得到主题通知时更新自己。4具体观察者（ConcreteObserver）：实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题状态协调。图1观察者模式类图总的来讲，观察者模式所做的工作其实就算再接除耦合。让耦合的双方都依赖于抽象而不是依赖于具体。从而使得各自的变化都不会影响另一边的变化。观察者模式的效果有以下的优点：第一、观察者模式在被观察者和观察者之间建立一个抽象的耦合。被观察者角色所知道的只是一个具体观察者列表，每一个具体观察者都符合一个抽象观察者的接口。被观察者并不认识任何一个具体观察者，它只知道它们都有一个共同的接口。由于被观察者和观察者没有紧密地耦合在一起，因此它们可以属于不同的抽象化层次。如果被观察者和观察者都被扔到一起，那么这个对象必然跨越抽象化和具体化层次。第二、观察者模式支持广播通讯。被观察者会向所有的登记过的观察者发出通知，观察者模式有下面的缺点：第一、如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。第二、如果在被观察者之间有循环依赖的3话，被观察者会触发它们之间进行循环调用，导致系统崩溃。在使用观察者模式是要特别注意这一点。第三、如果对观察者的通知是通过另外的线程进行异步投递的话，系统必须保证投递是以自恰的方式进行的。第四、虽然观察者模式可以随时使观察者知道所观察的对象发生了变化，但是观察者模式没有相应的机制使观察者知道所观察的对象是怎么发生变化的。抽象工厂模式抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的一种形态。抽象工厂模式是指当有多个抽象角色时，使用的一种工厂模式。抽象工厂模式可以向客户端提供一个接口，使客户端在不必指定产品的具体的情况下，创建多个产品族中的产品对象。根据LSP原则，任何接受父类型的地方，都应当能够接受子类型。因此，实际上系统所需要的，仅仅是类型与这些抽象产品角色相同的一些实例，而不是这些抽象产品的实例。换言之，也就是这些抽象产品的具体子类的实例。工厂类负责创建抽象产品的具体子类的实例。抽象工厂模式与工厂方法模式的区别抽象工厂模式是工厂方法模式的升级版本，他用来创建一组相关或者相互依赖的对象。他与工厂方法模式的区别就在于，工厂方法模式针对的是一个产品等级结构；而抽象工厂模式则是针对的多个产品等级结构。在编程中，通常一个产品结构，表现为一个接口或者抽象类，也就是说，工厂方法模式提供的所有产品都是衍生自同一个接口或抽象类，而抽象工厂模式所提供的产品则是衍生自不同的接口或抽象类。在抽象工厂模式中，有一个产品族的概念：所谓的产品族，是指位于不同产品等级结构中功能相关联的产品组成的家族。抽象工厂模式所提供的一系列产品就组成一个产品族；而工厂方法提供的一系列产品称为一个等级结构。抽象工厂模式的优点：抽象工厂模式除了具有工厂方法模式的优点外，最主要的优点就是可以在类的内部对产品族进行约束。所谓的产品族，一般或多或少的都存在一定的关联，抽象工厂模式就可以在类内部对产品族的关联关系进行定义和描述，而不必专门引入一个新的类来进行管理。抽象工厂模式的缺点：抽象工厂模式的最大缺点就是产品族扩展非常困难，为什么这么说呢？我们以通用代码为例，如果要增加一个产品C，也就是说有产品家族由原来的2个，增加到3个，看看我们的程序有多大改动吧！抽象类AbstractCreator要增加一个方法CreateProduct()，然后，两个实现类都要修改，想想看，这在项目中的话，还这么让人活！严重违反了开闭原则，4抽象工厂模式的使用场景抽象工厂模式的使用场景定义非常简单：一个对象族（或是一组没有任何关系的对象）都有相同的约束，则可以使用抽象工厂模式，什么意思呢？例如一个文本编辑器和一个图片处理器，都是软件实体，但是*nix下的文本编辑器和WINDOWS下的文本编辑器虽然功能和界面都相同，但是代码实现是不同的，图片处理器也是类似情况，也就是具有了共同的约束条件：操作系统类型，于是我们可以使用抽象工厂模式，产生不同操作系统下的编辑器和图片处理器。无论是简单工厂模式，工厂方法模式，还是抽象工厂模式，他们都属于工厂模式，在形式和特点上也是极为相似的，他们的最终目的都是为了解耦。在使用时，我们不必去在意这个模式到底工厂方法模式还是抽象工厂模式，因为他们之间的演变常常是令人琢磨不透的。经常你会发现，明明使用的工厂方法模式，当新需求来临，稍加修改，加入了一个新方法后，由于类中的产品构成了不同等级结构中的产品族，它就变成抽象工厂模式了；而对于抽象工厂模式，当减少一个方法使的提供的产品不再构成产品族之后，它就演变成了工厂方法模式。所以，在使用工厂模式时，只需要关心降低耦合度的目的是否达到了。图2抽象工厂模式结构图状态模式定义：当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。状态模式主要解决的是当控制一个对象状态的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简化。5状态模式：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。在很多情况下，一个对象的行为取决于一个或多个动态变化的属性，这样的属性叫做状态，这样的对象叫做有状态的(stateful)对象，这样的对象状态是从事先定义好的一系列值中取出的。当一个这样的对象与外部事件产生互动时，其内部状态就会改变，从而使得系统的行为也随之发生变化。模式中的角色1.上下文环境（Context）：它定义了客户程序需要的接口并维护一个具体状态角色的实例，将与状态相关的操作委托给当前的ConcreteState对象来处理。2.抽象状态（State）：定义一个接口以封装使用上下文环境的的一个特定状态相关的行为。3.具体状态（ConcreteState）：实现抽象状态定义的接口。适用场景1.一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为。2.一个操作中含有庞大的多分支结构，并且这些分支决定于对象的状态。优点：1.状态模式将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。2.所有状态相关的代码都存在于某个Concertestate中，所以通过定义新的子类很容易地增加新的状态和转换。3.状态模式通过把各种状态转移逻辑分不到State的子类之间，来减少相互间的依赖。缺点：1.状态模式的使用必然会增加系统类和资源对象的个数。2.状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。图3状态模式结构图各种模式之间的关系有统一的设计原则:61、单一职责原则:一个类，只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。例如：要实现逻辑和界面的分离。2、开闭原则:开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。3、里氏代换原则:面向对象设计的基本原则之一。里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。from：百度百科4、依赖倒转原则:就是要依赖于抽象，不要依赖于具体。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。实现开闭原则的关键是抽象化，并且从抽象化导出具体化实现，如果说开闭原则是面向对象设计的目标的话，那么依赖倒转原则就是面向对象设计的主要手段。from：百度百科5、接口隔离原则:这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。6、合成复用原则:合成复用原则就是指在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用其已有功能的目的。简言之：要尽量使用组合/聚合关系，少用继承。7、迪米特法则:也叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。也就是说一个软件实体应当尽可能少的与其他实体发生相互作用。这样，当一个模块修改时，就会尽量少的影响其他的模块，扩展会相对容易，这是对软件实体之间通信的限制，它要求限制软件实体之间通信的宽度和深度7展望和总结在现代社会，人们越来越离不开软件，越来越多的软件被开发出来贡人们使用，新的软件淘汰旧的不符合潮流的软件，学好软件设计模式是一个编程员对完美代码的追求的要求。善用不同的符合要求的软件设计模式，研发出更好的代码结构，现在软件开发离不开团队的共同努力，使用软件设计模式能够更快更省力的开发。没有一个良好的软件设计模式，想要设计一个符合要求的软件几乎是不可能的。软件模式有好多种，善于变化的使用，追求更加完美分代码