软件的可维护性与可复用性
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
模式:
模式,即Pattern。事实上确实是解决某一类问题的方法论。把解决某类问题的方法总结归纳到理论高度,那确实是模式。Alexander给出的经典定义是:每个模式都描述了一个在我们的环境中不断出现的问题,然后描述了该问题的解决方案的核心。通过这种方式,你能够许多次地使用那些已有的解决方案,无需再重复相同的工作。模式有不同的领域,建筑领域有建筑模式,软件设计领域也有设计模式。当一个领域逐渐成熟的时候,自然会出现专门多模式。
设计模式和面向对象的设计模式:
设计模式(Design pattern)是一套被反复使用、多数人知晓的、通过分类编目的、代码设计经验的总结。使用设计
模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式最初来源于建筑学。GOF(“四人帮”,指Gamm a, Helm, Johnson & Vlissides, Addison-Wesley四人)的《设计模式》(1995年出版)是第一次将设计模式提升到理论高度,并将之规范化,本系列文章要紧确实是讲解这23种经典的设计模式。
面向对象设计的模式,顾名思义,确实是在面向对象分析与设计中使用的设计模式,GOF23种设计模式同时也是面向对象的设计模式,本文不做区分。良好的设计模式运用能够实现软件设计的“高内聚、低耦合”,提高软件的复用性和可扩展性。
框架:
框架,即Framework。事实上确实是某种应用的半成品,确实是一组组件,供你选用完成你自己的系统。简单讲确实是使用不人搭好的舞台,你来做表演。而且,框架一般是成熟的,不断升级的软件。框架一般处在低层应用平台(如J2EE)和高层业务逻辑之间的中间层。
架构:
架构(Architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。架构是一个系统的草图。架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现时期,这些
抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口来实现。
一些刚入门的程序员经常会混淆“框架”和“架构”这两个名词,那个地点做了一下解释。
我们什么缘故要使用设计模式呢?有人可能会讲为了设计出"高内聚低耦合"的软件。"高内聚低耦合"的软件实际上也确实是本文所讲的具有可维护性和可复用性的软件。
这篇文章要紧讲解两方面内容,这两方面是软件设计中专门重要,也是专门关键的内容,希望大伙儿认真考虑并深刻理解。第一部分确实是关于软件的可维护性和可复用性的相关内容,第二部分确实是在第一部分的基础上逐条讲解面向对象软件设计的差不多原则,本文内容差不多上些专门理论性的东西,这些理论是软件设计的基础。凡是有理论的地点,就有如何恰当的将理论应用到实践中去的问题,设计模式是关于学习OO设计原则的具体指导,也确实是讲设计模式确实是将这些理论应用到实践的一种成熟的方式。
软件的可维护性和可复用性
首先来上一段大师所讲的话,专门经典。
“通常认为,一个易于维护的系统,确实是复用率较高的系统;而一个复用率较高的系统,确实是一个易于维护的系统。然而实际上,可维护性和可复用性是两个独立的目标,就像两只奔驰的
兔子一样,并不总是方向一致的。关于面向对象的软件系统设计来讲,在支持可维护性(Maintainability)的同时,提高系统的可复用性(Reuseability)是一个核心的问题。”--《Jav a与模式》阎宏博士
软件系统的可维护性:
软件维护确实是软件的再生。一个好的软件设计,必须能够同意新的设计要求以比较容易和平稳的方式加入到已有
的系统中去,从而使那个系统能够不断的的焕发出活力。一个可维护性较好的系统,应当同意维护工作能够以容易、准确、安全和经济的形式进行。
【导致可维护性较低的缘故】
1、过于僵硬:在系统中加入一个新的功能,不管大小都专门难,不仅意味着建筑一个独立的新的模块,而且因为那个新功能会波及专门多其他模块,最后成跨越几个模块的改动。
2、过于脆弱:与软件的过于僵硬同时存在,是软件系统在修改已有代码时过于脆弱。对一个地点的修改,往往会导致看上去没有什么关系的另外一个地点发生故障。
3、复用率低:所谓复用,确实是指一个软件的组成部分,能够在同一个项目的不同地点甚至另一个项目中重复使用。复用率低,指当一段代码,函数,模块的功能能够在新的模块或新的系统使用,然而已有代码依靠于其他专门多东西,专门难分开。
4、黏度过高:一个改动能够保存原始设计意图和原始设计框架
的方式进行,也能够以破坏原始意图和框架进行。第一种方法对系统的以后有利,第二种方法是权宜之计,能够解决短期的问题,然而会牺牲中长期的利益。假如一个系统中使用第二种方法比使用第一种方法容易,那么确实是黏度过高。
【设计的目标】
1、可扩展性:新的性能能够专门容易地加入到系统中去,确实是可扩展性。这确实是系统“过于僵硬”的属性的方面。
2、灵活性:能够同意代码修改平稳地发生,而可不能波及到专门多其他的模块,这确实是灵活性。灵活性事实上确实是“过于脆弱”的属性的方面。
3、可插入性:能够专门容易地将一个类抽出去,同时将另外一个有同样接口的类加入进来,这确实是可插入性。事实上,这确实是“黏度过高”的方面。
软件系统的可复用性:
【软件复用的好处】
1、较高的生产效率;
2、较高的软件质量;
3、恰当使用复用能够改善系统的可维护性。
【传统的复用形式】
1、代码的剪贴复用;
2、算法的复用;
3、数据结构的复用。
【面向对象设计的复用】
在面向对象语言中,数据的抽象化,继承,封装和多态性使得一个系统能够在更高层次上提供可复用性。数据的抽象化和继承关系使得概念和定义能够复用;多态性使得实现和应用得到复用;而抽象化和封装能够保持和促进系统的可维护性,复用的重点转移到含有宏观商业逻辑的抽象层次上。在面向对象的设计里面,可维护性复用是以设计原则和设计模式为基础的。
提高系统可维护性和可复用性的设计原则
1、“开-闭”原则(Open-Closed Principle,或者OCP);
一个软件实体应该对扩展开放,对修改关闭;
在设计一个模块的时候,应当使那个模块能够在不被修改的前提下被扩展。换言之,应当能够在不必修改源代码的情况下改变那个模块的行为。那个原则实际上是对“对可变性的封闭原则“:找到一个系统的可变因素,将之封装起来。那个原则意昧着两点:1) 一个可变性不应当散落在代码的专门多角落里,而应当被封装到一个对象里面。同一种可变性的不同表象意昧着同一个继承等级结构中的具体子类。
继承就当被看作是封装变化的方法,而不应当被认为是从一般的对象生成专门对象的方法。
2) 一种可变性不应当与另一种可变性混合在一起。(所有类图的继承结构一般可不能超过两层,不然就意昧着将两种不同的可变性混合在了一起。)