没有合适的资源?快使用搜索试试~ 我知道了~
Java_面向对象设计原则总结 一 类的设计原则 1 依赖倒置原则-Dependency Inversion Principle (DIP) 2 里氏替换原则-Liskov Substitution Principle (LSP) 3 接口分隔原则-Interface Segregation Principle (ISP) 4 单一职责原则-Single Responsibility Principle (SRP) 5 开闭原则-The Open-Closed Principle (OCP) 二 包的设计原则 6 重用发布等价原则-Release Reuse Equivalency Principle (REP) 7 无环依赖原则-The Acyclic Dependencies Principle (ADP) 8 稳定依赖原则-The Stable Dependencies Principle (SDP) 9 稳定抽象等价原则-The Stable Abstractions Principle (SAP) 10 共同封闭原则-The Common Closure Principle (CCP) 11 全部重用原则-The Common Reuse Principle (CRP)
资源推荐
资源详情
资源评论
Java 面向对象 16 种设计原则
一 类的设计原则
1 依赖倒置原则-Dependency Inversion Principle (DIP)
2 里氏替换原则-Liskov Substuon Principle (LSP)
3 接口分隔原则-Interface Segregaon Principle (ISP)
4 单一职责原则-Single Responsibility Principle (SRP)
5 开闭原则-The Open-Closed Principle (OCP)
二 包的设计原则
6 重用发布等价原则-Release Reuse Equivalency Principle (REP)
7 无环依赖原则-The Acyclic Dependencies Principle (ADP)
8 稳定依赖原则-The Stable Dependencies Principle (SDP)
9 稳定抽象等价原则-The Stable Abstracons Principle (SAP)
10 共同封闭原则-The Common Closure Principle (CCP)
11 全部重用原则-The Common Reuse Principle (CRP)
三 扩展原则
12 迪米特法则 -Least Knowledge Principle (LKP)
13 黑盒原则- BBP(Black Box Principle)
14 缺省抽象原则 -DAP(Default Abstracon Principle)
15 接口设计原则 -IDP(Interface Design Principle)
16 不要构造具体的超类原则 -DCSP(Don't Concrete Supperclass Principle)
1. Dependency Inversion Principle (DIP) - 依赖倒置原则
依赖:在程序设计中,如果一个模块 a 使用或调用了另一个模块 b,我们称模块 a 依赖模块 b。
高层模块与低层模块:往往在一个应用程序中,我们有一些低层次的类,这些类实现了一些基本
的或初级的操作,我们称之为低层模块;另外有一些高层次的类,这些类封装了某些复杂的逻
辑,并且依赖于低层次的类,这些类我们称之为高层模块。
依赖倒置原则的 2 个重要方针:
A. 高层模块不应该依赖于低层模块,二者都应该依赖于抽象
B. 抽象不应该依赖于细节,细节应该依赖于抽象
为什么叫做依赖倒置(Dependency Inversion)呢?
面向对象程序设计相对于面向过程(结构化)程序设计而言,依赖关系被倒置了。因为传统的结
构化程序设计中,高层模块总是依赖于低层模块。
问题的提出:
Robert C. Marn 在原文中给出了“Bad Design”的定义:
1. 系统很难改变,因为每个改变都会影响其他很多部分。
2. 当你对某地方做一修改,系统的看似无关的其他部分都不工作了。
3. 系统很难被另外一个应用重用,因为你很难将要重用的部分从系统中分离开来。
导致“Bad Design”的很大原因是“高层模块”过分依赖“低层模块”。一个良好的设计应该是系统的每
一部分都是可替换的。如果“高层模块”过分依赖“低层模块”,一方面一旦“低层模块”需要替换或者
修改,“高层模块”将受到影响;另一方面,高层模块很难可以重用。
比如,一个 Copy 模块,需要把来自 Keyboard 的输入复制到 Print,即使对 Keyboard 和 Print 的封
装已经做得非常好,但如果 Copy 模块里直接使用 Keyboard 与 Print,Copy 任很难被其他应用环境
(比如需要输出到磁盘时)重用。
问题的解决:
为了解决上述问题,Robert C. Marn 提出了 OO 设计的 Dependency Inversion Principle (DIP) 原则。
DIP 给出了一个解决方案:在高层模块与低层模块之间,引入一个抽象接口层。
High Level Classes(高层模块) --> Abstracon Layer(抽象接口层) --> Low Level Classes(低层模
块)
抽象接口是对低层模块的抽象,低层模块继承或实现该抽象接口。
这样,高层模块不直接依赖低层模块,高层模块与低层模块都依赖抽象接口层。
当然,抽象也不依赖低层模块的实现细节,低层模块依赖(继承或实现)抽象定义。
Robert C. Marn 给出的 DIP 方案的类的结构图:
PolicyLayer-->MechanismInterface(abstract)--MechanismLayer-->UlityInterface(abstract)--UlityLayer
类与类之间都通过 Abstract Layer 来组合关系。
2. Liskov Substuon Principle (LSP) - 里氏替换原则
所有引用基类的地方必须能透明地使用其子类的对象。也就是说,只有满足以下 2 个条件的 OO
设计才可被认为是满足了 LSP 原则:
A 不应该在代码中出现 if/else 之类对子类类型进行判断的条件。以下代码就违反 LSP 定义。
if (obj typeof Class1) {
do something
} else if (obj typeof Class2) {
do something else
}
B 子类应当可以替换父类并出现在父类能够出现的任何地方,或者说如果我们把代码中使用基类
的地方用它的子类所代替,代码还能正常工作。
里氏替换原则 LSP 是使代码符合开闭原则的一个重要保证。同时 LSP 体现了:
1) 类的继承原则:如果一个继承类的对象可能会在基类出现地方出现运行错误,则该子类不应
该从该基类继承,或者说,应该重新设计它们之间的关系。
2)动作正确性保证:从另一个侧面上保证了符合 LSP 设计原则的类的扩展不会给已有的系统引
入新的错误。
类的继承原则:
Robert C. Marn 举了 Rectangle 和 Square 的例子。这里沿用这个例子,但用 Java 语言对其加以重
写,并忽略了某些细节只列出下面的精要部分来说明 里氏替换原则 对类的继承上的约束。
1. class Rectangle {
2. double width;
3. double height;
4.
5. public double getHeight() {
6. return height;
7. }
8. public void setHeight(double height) {
9. this.height = height;
10. }
11. public double getWidth() {
12. return width;
13. }
14. public void setWidth(double width) {
15. this.width = width;
16. }
17. }
18.
19. class Square extends Rectangle {
20. public void setHeight(double height) {
21. super.setHeight(height);
22. super.setWidth(height);
23. }
24.
25. public void setWidth(double width) {
26. super.setHeight(width);
27. super.setWidth(width);
28. }
29. }
这里 Rectangle 是基类,Square 从 Rectangle 继承。这种继承关系有什么问题吗?
假如已有的系统中存在以下既有的业务逻辑代码:
void g(Rectangle r) {
r.setWidth(5);
r.setHeight(4);
if (r.getWidth() * r.getHeight() != 20) {
throw new RunmeExcepon();
}
}
则对应于扩展类 Square,在调用既有业务逻辑时:
Rectangle square = new Square();
g(square);
时会抛出一个 RunmeExcepon 异常。这显然违反了 LSP 原则。
动作正确性保证:
因为 LSP 对子类的约束,所以为已存在的类做扩展构造一个新的子类时,根据 LSP 的定义,不会
给已有的系统引入新的错误。
剩余21页未读,继续阅读
资源评论
yangxh101
- 粉丝: 1
- 资源: 13
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- (源码)基于SimPy和贝叶斯优化的流程仿真系统.zip
- (源码)基于Java Web的个人信息管理系统.zip
- (源码)基于C++和OTL4的PostgreSQL数据库连接系统.zip
- (源码)基于ESP32和AWS IoT Core的室内温湿度监测系统.zip
- (源码)基于Arduino的I2C协议交通灯模拟系统.zip
- coco.names 文件
- (源码)基于Spring Boot和Vue的房屋租赁管理系统.zip
- (源码)基于Android的饭店点菜系统.zip
- (源码)基于Android平台的权限管理系统.zip
- (源码)基于CC++和wxWidgets框架的LEGO模型火车控制系统.zip
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功