java设计模式系列之六大设计原则

最新推荐文章于 2024-07-15 09:00:00 发布

早更人

最新推荐文章于 2024-07-15 09:00:00 发布

阅读量626

点赞数 1

分类专栏： java基础文章标签：设计原则

本文链接：https://blog.csdn.net/fengtaosky/article/details/80909426

版权

1 篇文章 0 订阅

订阅专栏

定义：
A Class should never have more than one reason to change.
应该有且仅有一个原因引起类的变更。

理由：
可维护性：仅在一个模块或者类种进行必要的修改。

实例：

class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}

这个类违反了SRP原则，因为它有三个原因去修改这个类：

我们不希望这个类受三种力量的影响，每次当账户要求修改小时报告时间格式，或者当DBA更改数据库模式，以及管理者更改工资计算规则时，我们都不希望更改Employee类，相反，我们希望讲这些功能分成不同的类，以便他们能够独立的更改。

定义：一个软件实体（如类）应该对扩展开放，对修改关闭。

好处：
通过对原有代码的最小化的修改来提高代码的可维护性和稳定性。

如何做：
1.编写可以扩展的类
2仅暴露需要修改的部分，隐藏其他所有的内容。

网络收集建议：
1.抽象行为：通过接口或抽象类可以约束一组可能变化的行为，并且实现对扩展开放。

典型架构： Plugin Architecture（插件架构，如我们使用的Idea，Eclipse等）
资源：
开闭原则（英文）

定义：所有引用基类的地方必须能透明地使用其子类的对象。也就是说所有父类出现的地方，都可以用子类来替换。

如何理解：
1.子类必须完全实现父类
2.覆盖或实现父类的方法时，输入参数可以被放大。
3.覆盖或实现父类的方法时，输出结果可以被缩小。

里氏替换原则，其实在告诉我们如何优雅的处理类继承之间的关系。

提示替换原则是很多其他设计模式的基础。它和开闭原则的联系尤为紧密，违背里氏替换原则就一定不符合开闭原则

定义：

A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。
B.抽象不应该依赖于具体实现，具体实现应该依赖于抽象。
依赖倒置实际上就是要求“面向接口编程”。

好处：
采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

依赖倒置原则：
场景一依赖无倒置（底层模块定义接口，高层模块负责实现）

依赖无倒置

从上图中，我们发现高层模块的类依赖于低层模块的接口。因此，低层模块需要考虑到所有的接口。如果有新的低层模块类出现时，高层模块需要修改代码，来实现新的低层模块的接口。这样，就破坏了开放封闭原则。

场景二依赖倒置（高层模块定义接口，低层模块负责实现）

在这个图中，我们发现高层模块定义了接口，将不再直接依赖于低层模块，低层模块负责实现高层模块定义的接口。这样，当有新的低层模块实现时，不需要修改高层模块的代码。

DIP优点：
系统更柔韧：可以修改一部分代码而不影响其他模块。
系统更健壮：可以修改一部分代码而不会让系统崩溃。
系统更高效：组件松耦合，且可复用，提高开发效率。

定义：客户端不应该依赖它不需要的接口；类见的依赖关系应该建立在最小的接口上。

接口隔离原则，其实告诉我们如何优雅的设计一个接口，具体包含4层含义：

接口要尽量小。但是在拆分接口的时候，首先必须满足单一职责原则。
接口要高内聚。
首先要明白什么是高内聚？高内聚就是提高接口、类、模块的处理能力，同时减少对外的交互（也就是少暴漏接口出去）。也就是说，尽量减少对外提供的接口，让提供的每个接口的处理能力增强。
定制服务。
接口设计。可以理解为对每个模块提供专用的接口。也可以理解为只提供访问者需要的方法，不需要的方法都不提供
接口设计是有限度的。
建议：
一个接口只服务于一个子模块或业务逻辑。
通过业务逻辑压缩接口中的public方法，接口时常去回顾。
已经被污染的接口，尽量去修改，若变更的风险较大，可以采用适配器模式进行转换处理