《精编》软件的可维护性与可复用性

上传人:tang****xu5 文档编号:133202096 上传时间:2020-05-25 格式:DOC 页数:25 大小:1.38MB
返回 下载 相关 举报
《精编》软件的可维护性与可复用性_第1页
第1页 / 共25页
《精编》软件的可维护性与可复用性_第2页
第2页 / 共25页
《精编》软件的可维护性与可复用性_第3页
第3页 / 共25页
《精编》软件的可维护性与可复用性_第4页
第4页 / 共25页
《精编》软件的可维护性与可复用性_第5页
第5页 / 共25页
点击查看更多>>
资源描述

《《精编》软件的可维护性与可复用性》由会员分享,可在线阅读,更多相关《《精编》软件的可维护性与可复用性(25页珍藏版)》请在金锄头文库上搜索。

1、模式:模式,即Pattern。其实就是解决某一类问题的方法论。把解决某类问题的方法总结归纳到理论高度,那就是模式。Alexander给出的经典定义是:每个模式都描述了一个在我们的环境中不断出现的问题,然后描述了该问题的解决方案的核心。通过这种方式,你可以无数次地使用那些已有的解决方案,无需再重复相同的工作。模式有不同的领域,建筑领域有建筑模式,软件设计领域也有设计模式。当一个领域逐渐成熟的时候,自然会出现很多模式。设计模式和面向对象的设计模式:设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被

2、他人理解、保证代码可靠性。设计模式最初来源于建筑学。GOF(“四人帮”,指Gamma, Helm, Johnson & Vlissides, Addison-Wesley四人)的设计模式(1995年出版)是第一次将设计模式提升到理论高度,并将之规范化,本系列文章主要就是讲解这23种经典的设计模式。面向对象设计的模式,顾名思义,就是在面向对象分析与设计中使用的设计模式,GOF23种设计模式同时也是面向对象的设计模式,本文不做区分。良好的设计模式运用可以实现软件设计的“高内聚、低耦合”,提高软件的复用性和可扩展性。框架:框架,即Framework。其实就是某种应用的半成品,就是一组组件,供你选用完

3、成你自己的系统。简单说就是使用别人搭好的舞台,你来做表演。而且,框架一般是成熟的,不断升级的软件。框架一般处在低层应用平台(如J2EE)和高层业务逻辑之间的中间层。架构:架构(Architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。架构是一个系统的草图。架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口来实现。一些刚入门的程序员经常会混淆“框架”和“架构”这两个名词,这里做了一下解释。我们为什么要使用设计模式呢

4、?有人可能会说为了设计出高内聚低耦合的软件。高内聚低耦合的软件实际上也就是本文所说的具有可维护性和可复用性的软件。这篇文章主要讲解两方面内容,这两方面是软件设计中很重要,也是很关键的内容,希望大家认真思考并深刻理解。第一部分就是关于软件的可维护性和可复用性的相关内容,第二部分就是在第一部分的基础上逐条讲解面向对象软件设计的基本原则,本文内容都是些很理论性的东西,这些理论是软件设计的基础。凡是有理论的地方,就有如何恰当的将理论应用到实践中去的问题,设计模式是对于学习OO设计原则的具体指导,也就是说设计模式就是将这些理论应用到实践的一种成熟的方式。软件的可维护性和可复用性首先来上一段大师所说的话,

5、很经典。“通常认为,一个易于维护的系统,就是复用率较高的系统;而一个复用率较高的系统,就是一个易于维护的系统。但是实际上,可维护性和可复用性是两个独立的目标,就像两只奔跑的兔子一样,并不总是方向一致的。对于面向对象的软件系统设计来说,在支持可维护性(Maintainability)的同时,提高系统的可复用性(Reuseability)是一个核心的问题。”Java与模式阎宏博士 软件系统的可维护性:软件维护就是软件的再生。一个好的软件设计,必须能够允许新的设计要求以比较容易和平稳的方式加入到已有的系统中去,从而使这个系统能够不断的的焕发出活力。一个可维护性较好的系统,应当允许维护工作能够以容易、

6、准确、安全和经济的形式进行。【导致可维护性较低的原因】1、过于僵硬:在系统中加入一个新的功能,不管大小都很难,不仅意味着建造一个独立的新的模块,而且因为这个新功能会波及很多其他模块,最后成跨越几个模块的改动。2、过于脆弱:与软件的过于僵硬同时存在,是软件系统在修改已有代码时过于脆弱。对一个地方的修改,往往会导致看上去没有什么关系的另外一个地方发生故障。3、复用率低:所谓复用,就是指一个软件的组成部分,可以在同一个项目的不同地方甚至另一个项目中重复使用。复用率低,指当一段代码,函数,模块的功能可以在新的模块或新的系统使用,但是已有代码依赖于其他很多东西,很难分开。4、黏度过高:一个改动可以保存原

7、始设计意图和原始设计框架的方式进行,也可以以破坏原始意图和框架进行。第一种方法对系统的未来有利,第二种办法是权宜之计,可以解决短期的问题,但是会牺牲中长期的利益。如果一个系统中使用第二种方法比使用第一种方法容易,那么就是黏度过高。【设计的目标】1、可扩展性:新的性能可以很容易地加入到系统中去,就是可扩展性。这就是系统“过于僵硬”的属性的方面。2、灵活性:可以允许代码修改平稳地发生,而不会波及到很多其他的模块,这就是灵活性。灵活性其实就是“过于脆弱”的属性的方面。3、可插入性:可以很容易地将一个类抽出去,同时将另外一个有同样接口的类加入进来,这就是可插入性。其实,这就是“黏度过高”的方面。 软件

8、系统的可复用性:【软件复用的好处】1、较高的生产效率;2、较高的软件质量;3、恰当使用复用可以改善系统的可维护性。【传统的复用形式】1、代码的剪贴复用;2、算法的复用;3、数据结构的复用。【面向对象设计的复用】在面向对象语言中,数据的抽象化,继承,封装和多态性使得一个系统可以在更高层次上提供可复用性。数据的抽象化和继承关系使得概念和定义可以复用;多态性使得实现和应用得到复用;而抽象化和封装可以保持和促进系统的可维护性,复用的重点转移到含有宏观商业逻辑的抽象层次上。在面向对象的设计里面,可维护性复用是以设计原则和设计模式为基础的。提高系统可维护性和可复用性的设计原则1、“开闭”原则(Open-C

9、losed Principle,或者OCP);一个软件实体应该对扩展开放,对修改关闭;在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展。换言之,应当可以在不必修改源代码的情况下改变这个模块的行为。这个原则实际上是对“对可变性的封闭原则“:找到一个系统的可变因素,将之封装起来。这个原则意昧着两点:1) 一个可变性不应当散落在代码的很多角落里,而应当被封装到一个对象里面。同一种可变性的不同表象意昧着同一个继承等级结构中的具体子类。继承就当被看作是封装变化的方法,而不应当被认为是从一般的对象生成特殊对象的方法。2) 一种可变性不应当与另一种可变性混合在一起。(所有类图的继承结构一般不

10、会超过两层,不然就意昧着将两种不同的可变性混合在了一起。)这个原则是总的原则,其它几条是这个原则的手段和工具。2、里氏替代原则(Liskov Substitution Principle,或者LSP);如果对于每一个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换成o2时,程序P的行为没有变化,那么类型T2是类型T1的子类型。换言之,一个软件实体如果使用的是一个基类的话,那么一定适用于其子类,而且它根本不能察觉出基类对象和子类对象的区别。反过来代换不成立。3、依赖倒转原则(Dependency Inversion Principle,或者DIP)

11、;要依赖于抽象,不要依赖于具体。开闭原则是目标,而达到这一目标的手段是依赖倒转原则。抽象层次包含的是应用系统的商务逻辑和宏观的、对整个系统来说重要的战略性决定,是必然性的体现,那么抽象层次就应当是较为稳定的,应当是复用的重点;也应当是维护的重点;而具体层次则含有一些次要的与实现有关的算法和逻辑,以及战术性的决定,带有相当大的偶然性选择。具体层次的代码是会经常有变动的,不能避免出现错误。4、接口隔离原则(Interface Segregation Principle,或者ISP);使用多个专门的接口比使用单一的总接口要好。换言之,从一个客户类的角度讲:一个类对另一个类的依赖性应当是建立在最小的接

12、口上的。接口隔离原则与迪米特法则(下面讲到)都是对一个软件实体与其他的软件实体的通信限制。迪米特原则要求尽可能地限制通信的宽度和深度,接品隔离原则要求通信的宽度尽可能地窄。这样做的结果使一个软件系统在功能扩展过程当中,不会将修改的压力传递到其他对象。一个接口相当于剧本中的一种角色,而此角色在一个舞台上由哪一个演员来演则相当于接口的实现。因此,一个接口应当简单地代表一个角色,而不是多个角色。如果系统涉及到多个角色的话,那么每一个角色都应当由一个特定的接口代表。5、组合/聚合复用原则(Composition/Aggregation Principle,或者CARP);组合/聚合原则就是在一个新的对

13、象里面使用一些已有的对象,使之成为新对象的一部分;新的对象通过向这些对象的委派达到得复用已有功能的目的。要尽量使用组合/聚合,尽量不要使用继承。6、迪米特法则(Law of Demeter,或者LoD);一个软件实体应当尽可能少的与其他实体发生相互作用。模块之间的交互要少。这样做的结果是当系统的功能需要扩展时,会相对更容易地做到对修改的关闭。一个对象应当对其他对象有尽可能少的了解。7、单一职责原则(Single Responsibility Principle,或者SRP)在设计中为每种职责设计一个类,彼此保持正交,互不干涉。这个原则比较容易理解,这里不在多说。小结当我们掌握了C#的语法,当我

14、们了解了面向对象的封装、继承、多态等特性,当我们可以用各种框架与技术构建桌面以及Web应用时,这并不意味着我们可以写出面向对象的程序,不意味着我们可以很好的实现代码复用,弹性维护,不意味着我们可以实现在维护、扩展基础上的代码复用。使用面向对象语言开发的程序不一定是面向对象的,使用面向过程的语言开发的程序也不一定不是面向对象的。要想开发出一个具有可维护性和可复用性的软件系统,那是需要优秀的设计和长时间的运行才能完成的,其实我们可以观察一下,任何一个优秀的软件产品都是经过长时间的设计,运行,维护,修改等最后才成为成功的产品,版本上也在不断的更新。衡量一个软件开发者是不是一个好的软件开发者,不是看他

15、是否实现了软件的必要功能,而是要看你的软件在满足功能需求的情况下是否做到了复用性和可扩展性,这对于一个大型系统尤其重要。我们不要静止的看待一个软件,而一定要把软件过程放在时间轴上来观察与设计它,只有放在时间轴上经得住考验的软件系统才是成功的。软件的复用性和可扩展性对于大型系统是必要的,我们在设计自己的软件系统时,甚至在编写代码时更需要考虑一下这样做是否遵循了系统设计的原则,是否有利于系统的可维护性和可复用性,是否达到了常说的“高内聚低耦合”呢?设计模式正是解决这一问题的王道。从下文开始我们将结合实例对于GoF23种设计模式进行一一讲解。现在我们正式进入GoF23种设计模式中的创建型模式的讲解中来,创建型模式主要解决对象如何创建的问题,提倡创建对象的责任和使用对象的责任分离,以达到更好对创建对象的控制的目的,创建型模式主要包括抽象工厂(Abstract Factory),建造者(Builder),工厂方法(Factory Method),原型(Prototype),单子(Singleton)。这篇文章主要分为两大部分内容,在第一部分中我将介绍抽象工厂模式的原型,包括抽象工厂的意图,可以解决的问题,原型代码和UML等,再结合一个生活中的小例子进行原型的说明。第二部分我会结合实际项

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 行业资料 > 其它行业文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号