设计模式六大原则(3):依赖倒转原则

来自:点击打开链接

依赖倒置原则又称依赖倒置原则

抽象不应该依赖细节,细节应该依赖于抽象。说白了,就是针对接口编程,不要针对实现编程

依赖倒置原则包含三层含义

1)高层模块不应该依赖低层模块,两者都应该依赖其抽象;

2)抽象不应该依赖细节;

3)细节应该依赖抽象。

看了上面的解释相信大家会和我一样会有一些疑问在脑海里(你存在我深深的脑海里大笑)下面来详细说一说吧:

1)为什么要针对接口编程,而不是针对实现编程呢?

很简单的一个例子,我们现在使用的电脑有各式的品牌,联想、神舟、戴尔等等,

电脑需要用到鼠标,键盘;假设鼠标、键盘是针对某一个品牌的机器实现去做的话,那么我们将会遇到什么问题呢?

那么我们市面上的键盘和鼠标就都是各式各样的,有一天鼠标,或键盘坏了,我们要怎么去买呢?难道记住这个电脑是什么品牌,什么型号,还有什么类型的去买么?这样会疯掉的。现在我们的电脑基本上都是使用USB接口的了,无论是键盘也好,鼠标也好,我们只要买USB接口的就可以使用了,同时,使用USB接口还可以有其他的扩展,只要实现了,这个接口,实现怎么样都没关系,例如,实现了USB接口的小台灯,只要接上USB线就可以照明了;又如实现了USB

接口的充电器,接到我们的电脑上就可以充电了。 

2)高层模块不应该依赖低层模块,两者都应该依赖其抽象又如何理解呢?这个问题也可以这么问:为什么要叫倒置(倒转)呢?

在面向过程的开发中,为了使用常用的代码可以复用,一般都会把这些常用的代码写成许许多多函数的程序库,这样我们做新项目的时候,就去调用这些函数就可以了。

例如:我们做的项目大多要访问数据库,所以我们就把数据库的代码写成了函数,每次做新项目时就去调用这些函数,这也就是高层依赖于低层模块了。

问题就出现在这里了,我们在做新项目的时候,会发现业务逻辑的高层模块是一样的,我们希望能重用这些高层模块,但是这些高层模块和低层模块的数据库绑定在一起了,这样我们就没办法复用这些高层模块了,这样就抓狂大哭

如果我们的高层模块和低层模块都依赖于抽象,具体一点就是依赖于接口或抽象类,只要接口够稳定,那么任何一个的更改都不用担心其他受到影响了。

3)为什么依赖了抽象的接口或是抽象类,就不怕更改了呢?要解决这个问题,先看看里氏替换原则。


基于SSM框架的智能家政保洁预约系统,是一个旨在提高家政保洁服务预约效率和管理水平的平台。该系统通过集成现代信息技术,为家政公司、家政服务人员和消费者提供了一个便捷的在线预约和管理系统。 系统的主要功能包括: 1. **用户管理**:允许消费者注册、登录,并管理他们的个人资料和预约历史。 2. **家政人员管理**:家政服务人员可以注册并更新自己的个人信息、服务类别和服务时间。 3. **服务预约**:消费者可以浏览不同的家政服务选项,选择合适的服务人员,并在线预约服务。 4. **订单管理**:系统支持订单的创建、跟踪和管理,包括订单的确认、完成和评价。 5. **评价系统**:消费者可以在家政服务完成后对服务进行评价,帮助提高服务质量和透明度。 6. **后台管理**:管理员可以管理用户、家政人员信息、服务类别、预约订单以及处理用户反馈。 系统采用Java语言开发,使用MySQL数据库进行数据存储,通过B/S架构实现用户与服务的在线交互。系统设计考虑了不同用户角色的需求,包括管理员、家政服务人员和普通用户,每个角色都有相应的权限和功能。此外,系统还采用了软件组件化、精化体系结构、分离逻辑和数据等方法,以便于未来的系统升级和维护。 智能家政保洁预约系统通过提供一个集中的平台,不仅方便了消费者的预约和管理,也为家政服务人员提供了一个展示和推广自己服务的机会。同时,系统的后台管理功能为家政公司提供了强大的数据支持和决策辅助,有助于提高服务质量和管理效率。该系统的设计与实现,标志着家政保洁服务向现代化和网络化的转型,为管理决策和控制提供保障,是行业发展中的重要里程碑。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值