面向对象分析设计原则.doc

面向对象分析设计原则.doc

ID:57662215

大小:47.50 KB

页数:5页

时间:2020-08-31

面向对象分析设计原则.doc_第1页
面向对象分析设计原则.doc_第2页
面向对象分析设计原则.doc_第3页
面向对象分析设计原则.doc_第4页
面向对象分析设计原则.doc_第5页
资源描述:

《面向对象分析设计原则.doc》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库

1、一、单一职责原则(SRP)      就一个类而言,应该仅有一个引起它变化的原因。软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离。测试驱动的开发实践常常会在设计出现臭味之前就迫使我们分离职责。      二、开闭原则(OCP)      软件实体(类、模块、函数)应该是可扩展的,但是不可修改的。也就是说:对于扩展是开放的,对于更改是封闭的。怎样可能在不改动模块源代码的情况下去更改它的行为呢?怎样才能在无需对模块进行改动的情况下就改变它的功能呢?关键是抽象!因此在进行面向对象设计时要尽量考虑接口

2、封装机制、抽象机制和多态技术。该原则同样适合于非面向对象设计的方法,是软件工程设计方法的重要原则之一。      三、替换原则(LSP)      子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从BertrandMeyer的DBC(DesignbyContract〔基于契约设计〕)的概念推出。      四、依赖倒置原则(DIP)1、高层模块不应该依赖于低层模块。二者都应该依赖于抽象。2、抽象不应该依赖于细节。细节应该依赖于抽象。在进行业务设

3、计时,与特定业务有关的依赖关系应该尽量依赖接口和抽象类,而不是依赖于具体类。具体类只负责相关业务的实现,修改具体类不影响与特定业务有关的依赖关系。在结构化设计中,我们可以看到底层的模块是对高层抽象模块的实现(高层抽象模块通过调用底层模块),这说明,抽象的模块要依赖具体实现相关的模块,底层模块的具体实现发生变动时将会严重影响高层抽象的模块,显然这是结构化方法的一个"硬伤"。面向对象方法的依赖关系刚好相反,具体实现类依赖于抽象类和接口。五、接口分离原则(ISP)采用多个与特定客户类有关的接口比采用一个通用的涵盖

4、多个业务方法的接口要好。  ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP,组件、类的可用性和移植性将大打折扣。这个原则的本质相当简单。如果你拥有一个针对多个客户的类,为每一个客户创建特定业务接口,然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。以上五个原则是面向对象中常常用到的原则。此外,除上述五原则外,还有一些常用的经验诸如类结构层次以三到四层为宜、类的职责明确化(一个类对应一个具体职责)等可供我们在进行面向对象设计参考。但就上面的几个原则看来,我们看到这些类在几何

5、分布上呈现树型拓扑的关系,这是一种良好、开放式的线性关系、具有较低的设计复杂度。一般说来,在软件设计中我们应当尽量避免出现带有闭包、循环的设计关系,它们反映的是较大的耦合度和设计复杂化。面向对象之代码复用规则1、对接口编程  "对接口编程"是面向对象设计(OOD)的第一个基本原则。它的含义是:使用接口和同类型的组件通讯,即,对于所有完成相同功能的组件,应该抽象出一个接口,它们都实现该接口。具体到JAVA中,可以是接口,或者是抽象类,所有完成相同功能的组件都实现该接口,或者从该抽象类继承。尽量使用接口。接口只

6、是对象打交道的入口,只有具有继承关系才使用抽象类。2、优先使用对象组合,而不是类继承  "优先使用对象组合,而不是类继承"是面向对象设计的第二个原则。并不是说继承不重要,而是因为每个学习OOP的人都知道OO的基本特性之一就是继承,以至于继承已经被滥用了,而对象组合技术往往被忽视了。只有有现实生活中的父子关系才使用继承。  相关的设计模式有:Bridge、Composite、Decorator、Observer、Strategy等。 3、将可变的部分和不可变的部分分离  "将可变的部分和不可变的部分分离"是面

7、向对象设计的第三个原则。如果使用继承的复用技术,我们可以在抽象基类中定义好不可变的部分,而由其子类去具体实现可变的部分,不可变的部分不需要重复定义,而且便于维护。如果使用对象组合的复用技术,我们可以定义好不可变的部分,而可变的部分可以由不同的组件实现,根据需要,在运行时动态配置。这样,我们就有更多的时间关注可变的部分。  对于对象组合技术而言,每个组件只完成相对较小的功能,相互之间耦合比较松散,复用率较高,通过组合,就能获得新的功能。4、减少方法的长度  通常,我们的方法应该只有尽量少的几行,太长的方法会难

8、以理解,而且,如果方法太长,则应该重新设计。对此,可以总结为以下原则:三十秒原则:  如果另一个程序员无法在三十秒之内了解你的函数做了什么(What),如何做(How)以及为什么要这样做(Why),那就说明你的代码是难以维护的,必须得到提高;一屏原则:如果一个函数的代码长度超过一个屏幕,那么或许这个函数太长了,应该拆分成更小的子函数;一行代码尽量简短,并且保证一行代码只做一件事那种看似技巧性的冗长代码只会增加代码

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。