软件的可维护性与可复用性Word格式文档下载.docx
《软件的可维护性与可复用性Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《软件的可维护性与可复用性Word格式文档下载.docx（42页珍藏版）》请在冰豆网上搜索。
设计模式最初来源于建筑学。
GOF（“四人帮”，指Gamma,Helm,Johnson&
Vlissides,Addison-Wesley四人）的《设计模式》（1995年出版）是第一次将设计模式提升到理论高度，并将之规范化，本系列文章要紧确实是讲解这23种经典的设计模式。
面向对象设计的模式，顾名思义，确实是在面向对象分析与设计中使用的设计模式，GOF23种设计模式同时也是面向对象的设计模式，本文不做区分。
良好的设计模式运用能够实现软件设计的“高内聚、低耦合”，提高软件的复用性和可扩展性。
框架:
框架，即Framework。
事实上确实是某种应用的半成品，确实是一组组件，供你选用完成你自己的系统。
简单讲确实是使用不人搭好的舞台，你来做表演。
而且，框架一般是成熟的，不断升级的软件。
框架一般处在低层应用平台（如J2EE）和高层业务逻辑之间的中间层。
架构：
架构（Architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。
架构是一个系统的草图。
架构描述的对象是直接构成系统的抽象组件。
各个组件之间的连接则明确和相对细致地描述组件之间的通讯。
在实现时期，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。
在面向对象领域中，组件之间的连接通常用接口来实现。
一些刚入门的程序员经常会混淆“框架”和“架构”这两个名词，那个地点做了一下解释。
我们什么缘故要使用设计模式呢？
有人可能会讲为了设计出"
高内聚低耦合"
的软件。
"
的软件实际上也确实是本文所讲的具有可维护性和可复用性的软件。
这篇文章要紧讲解两方面内容，这两方面是软件设计中专门重要，也是专门关键的内容，希望大伙儿认真考虑并深刻理解。
第一部分确实是关于软件的可维护性和可复用性的相关内容，第二部分确实是在第一部分的基础上逐条讲解面向对象软件设计的差不多原则，本文内容差不多上些专门理论性的东西，这些理论是软件设计的基础。
凡是有理论的地点，就有如何恰当的将理论应用到实践中去的问题，设计模式是关于学习OO设计原则的具体指导，也确实是讲设计模式确实是将这些理论应用到实践的一种成熟的方式。
软件的可维护性和可复用性
首先来上一段大师所讲的话，专门经典。
“通常认为，一个易于维护的系统，确实是复用率较高的系统；
而一个复用率较高的系统，确实是一个易于维护的系统。
然而实际上，可维护性和可复用性是两个独立的目标，就像两只奔驰的兔子一样，并不总是方向一致的。
关于面向对象的软件系统设计来讲，在支持可维护性（Maintainability）的同时，提高系统的可复用性（Reuseability）是一个核心的问题。
”－－《Java与模式》阎宏博士
软件系统的可维护性：
软件维护确实是软件的再生。
一个好的软件设计，必须能够同意新的设计要求以比较容易和平稳的方式加入到已有的系统中去，从而使那个系统能够不断的的焕发出活力。
一个可维护性较好的系统，应当同意维护工作能够以容易、准确、安全和经济的形式进行。
【导致可维护性较低的缘故】
1、过于僵硬：
在系统中加入一个新的功能，不管大小都专门难，不仅意味着建筑一个独立的新的模块，而且因为那个新功能会波及专门多其他模块，最后成跨越几个模块的改动。
2、过于脆弱：
与软件的过于僵硬同时存在，是软件系统在修改已有代码时过于脆弱。
对一个地点的修改，往往会导致看上去没有什么关系的另外一个地点发生故障。
3、复用率低：
所谓复用，确实是指一个软件的组成部分，能够在同一个项目的不同地点甚至另一个项目中重复使用。
复用率低，指当一段代码，函数，模块的功能能够在新的模块或新的系统使用，然而已有代码依靠于其他专门多东西，专门难分开。
4、黏度过高：
一个改动能够保存原始设计意图和原始设计框架的方式进行，也能够以破坏原始意图和框架进行。
第一种方法对系统的以后有利，第二种方法是权宜之计，能够解决短期的问题，然而会牺牲中长期的利益。
假如一个系统中使用第二种方法比使用第一种方法容易，那么确实是黏度过高。
【设计的目标】
1、可扩展性：
新的性能能够专门容易地加入到系统中去，确实是可扩展性。
这确实是系统“过于僵硬”的属性的方面。
2、灵活性：
能够同意代码修改平稳地发生，而可不能波及到专门多其他的模块，这确实是灵活性。
灵活性事实上确实是“过于脆弱”的属性的方面。
3、可插入性：
能够专门容易地将一个类抽出去，同时将另外一个有同样接口的类加入进来，这确实是可插入性。
事实上，这确实是“黏度过高”的方面。
软件系统的可复用性：
【软件复用的好处】
1、较高的生产效率；
2、较高的软件质量；
3、恰当使用复用能够改善系统的可维护性。
【传统的复用形式】
1、代码的剪贴复用；
2、算法的复用；
3、数据结构的复用。
【面向对象设计的复用】
在面向对象语言中，数据的抽象化，继承，封装和多态性使得一个系统能够在更高层次上提供可复用性。
数据的抽象化和继承关系使得概念和定义能够复用；
多态性使得实现和应用得到复用；
而抽象化和封装能够保持和促进系统的可维护性，复用的重点转移到含有宏观商业逻辑的抽象层次上。
在面向对象的设计里面，可维护性复用是以设计原则和设计模式为基础的。
提高系统可维护性和可复用性的设计原则
1、“开－闭”原则（Open-ClosedPrinciple，或者OCP）；
一个软件实体应该对扩展开放，对修改关闭；
在设计一个模块的时候，应当使那个模块能够在不被修改的前提下被扩展。
换言之，应当能够在不必修改源代码的情况下改变那个模块的行为。
那个原则实际上是对“对可变性的封闭原则“：
找到一个系统的可变因素，将之封装起来。
那个原则意昧着两点：
1）一个可变性不应当散落在代码的专门多角落里，而应当被封装到一个对象里面。
同一种可变性的不同表象意昧着同一个继承等级结构中的具体子类。
继承就当被看作是封装变化的方法，而不应当被认为是从一般的对象生成专门对象的方法。
2）一种可变性不应当与另一种可变性混合在一起。
（所有类图的继承结构一般可不能超过两层，不然就意昧着将两种不同的可变性混合在了一起。
）
那个原则是总的原则，其它几条是那个原则的手段和工具。
2、里氏替代原则（LiskovSubstitutionPrinciple，或者LSP）；
假如关于每一个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有变化，那么类型T2是类型T1的子类型。
换言之，一个软件实体假如使用的是一个基类的话，那么一定适用于其子类，而且它全然不能察觉出基类对象和子类对象的区不。
反过来代换不成立。
3、依靠倒转原则（DependencyInversionPrinciple，或者DIP）；
要依靠于抽象，不要依靠于具体。
开闭原则是目标，而达到这一目标的手段是依靠倒转原则。
抽象层次包含的是应用系统的商务逻辑和宏观的、对整个系统来讲重要的战略性决定，是必定性的体现，那么抽象层次就应当是较为稳定的，应当是复用的重点；
也应当是维护的重点；
而具体层次则含有一些次要的与实现有关的算法和逻辑，以及战术性的决定，带有相当大的偶然性选择。
具体层次的代码是会经常有变动的，不能幸免出现错误。
4、接口隔离原则（InterfaceSegregationPrinciple，或者ISP）；
使用多个专门的接口比使用单一的总接口要好。
换言之，从一个客户类的角度讲：
一个类对另一个类的依靠性应当是建立在最小的接口上的。
接口隔离原则与迪米特法则（下面讲到）差不多上对一个软件实体与其他的软件实体的通信限制。
迪米特原则要求尽可能地限制通信的宽度和深度，接品隔离原则要求通信的宽度尽可能地窄。
如此做的结果使一个软件系统在功能扩展过程当中，可不能将修改的压力传递到其他对象。
一个接口相当于剧本中的一种角色，而此角色在一个舞台上由哪一个演员来演则相当于接口的实现。
因此，一个接口应当简单地代表一个角色，而不是多个角色。
假如系统涉及到多个角色的话，那么每一个角色都应当由一个特定的接口代表。
5、组合/聚合复用原则（Composition/AggregationPrinciple，或者CARP）；
组合/聚合原则确实是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；
新的对象通过向这些对象的委派达到得复用已有功能的目的。
要尽量使用组合/聚合，尽量不要使用继承。
6、迪米特法则（LawofDemeter，或者LoD）；
一个软件实体应当尽可能少的与其他实体发生相互作用。
模块之间的交互要少。
如此做的结果是当系统的功能需要扩展时，会相对更容易地做到对修改的关闭。
一个对象应当对其他对象有尽可能少的了解。
7、单一职责原则（SingleResponsibilityPrinciple，或者SRP）
在设计中为每种职责设计一个类，彼此保持正交，互不干涉。
那个原则比较容易理解，那个地点不在多讲。
小结
当我们掌握了C#的语法，当我们了解了面向对象的封装、继承、多态等特性，当我们能够用各种框架与技术构建桌面以及Web应用时，这并不意味着我们能够写出面向对象的程序，不意味着我们能够专门好的实现代码复用，弹性维护，不意味着我们能够实现在维护、扩展基础上的代码复用。
使用面向对象语言开发的程序不一定是面向对象的，使用面向过程的语言开发的程序也不一定不是面向对象的。
要想开发出一个具有可维护性和可复用性的软件系统，那是需要优秀的设计和长时刻的运行才能完成的，事实上我们能够观看一下，任何一个优秀的软件产品差不多上通过长时刻的设计，运行，维护，修改等最后才成为成功的产品，版本上也在不断的更新。
衡量一个软件开发者是不是一个好的软件开发者，不是看他是否实现了软件的必要功能，而是要看你的软件在满足功能需求的情况下是否做到了复用性和可扩展性，这关于一个大型系统尤其重要。
我们不要静止的看待一个软件，而一定要把软件过程放在时刻轴上来观看与设计它，只有放在时刻轴上经得住考验的软件系统才是成功的。
软件的复用性和可扩展性关于大型系统是必要的，我们在设计自己的软件系统时，甚至在编写代码时更需要考虑一下如此做是否遵循了系统设计的原则，是否有利于系统的可维护性和可复用性，是否达到了常讲的“高内聚低耦合”呢？
设计模式正是解决这一问题的王道。
从下文开始我们将结合实例关于GoF23种设计模式进行一一讲解。
现在我们正式进入GoF23种设计模式中的创建型模式的讲解中来，创建型模式要紧解决对象如何创建的问题，提倡创建对象的责任和使用对象的责任分离，以达到更好对创建对象的操纵的目的，创建型模式要紧包括抽象工厂（AbstractFactory），建筑者（Builder），工厂方法（FactoryMethod），原型（Prototype），单子（Singleton）。
这篇文章要紧分为两大部分内容，在第一部分中我将介
升级会员 