我对面向对象的6大设计原则的理解

程序员都知道编程有 3 大类:面向过程、面向对象、面向函数。面向对象是被讨论的最多的,个人认为,这是因为 Java 之类的编程语言有强大的用户基础,本质还是因为比较符合人的直觉。

说到面向对象,大家可能就会很快想到了 23 种设计模式,可只有少部分人会想到面向对象的 6 大原则,所以本文我分享一下我对于 6 大原则的看法。

6 大原则是内功心法,23 种设计模式是武术套路,它们的本质是为了更好地面对需求的变化。

很多人对于设计模式背诵的滚瓜烂熟,但是却没有办法评价自己的代码质量,尤其是根据自己的想法整了一大堆设计模式之后,很难分辨自己是规范编程还是过度设计。

其实,设计模式是立足于 6 大设计原则上的。

6 大设计原则对应 6 个规则,取首字母缩写就是 SOLID 。

1. 单一职责原则 (Single Responsibility Principle)

描述:一个类只有一个引起修改的原因。

理解:我们都知道要软件开发要解耦合,减耦合的理想状态就是一个类只负责一个功能。

软件开发要做好拥抱变化的准备。

比如,1 个月前,你做了一个类,负责用户模块。

后来需求变动,登录增加了微信账号登录,你得改你的用户模块。

后来需求变动,注册增加了手机动态码验证,你的修改你的用户模块。

后来需求变动,登录增加了github 登录,你的修改你的用户模块。

后来需求变动,登录增加了weibo 登录验证,你得修改你的用户模块。

后来需求变动,… 你已经麻木了。

你会发现,你的用户模块越来越臃肿了。

但是,如果你一早就实现 2 个类,一个负责登录,一个负责注册。

那么登录需求的变化不会影响注册的代码,反之已然。

虽然,代码没有减少多少,但你可以明确感受到职责分明,所以开发会更轻松一点。

在这里插入图片描述

2. 开闭原则 (Single Responsibility Principle)

描述:一个软件实体,应该对扩展开放,对修改关闭。

理解:很多人可能对这个概念感到有些玄乎,其实很好理解的。

假设你是乙方,你给甲方的交付物是一个 SDK,有一天客户想要增加一个功能,现在有 2 种方案可以选择:

  1. 你重新开发一个新的 API 供客户调用。
  2. 建议客户利用现成的 SDK 扩展一个新的 API 自己解决问题。

说具体点,比如客户临时提出一个美颜的需求。

你评估了自己的 SDK 里面发现有人脸检测 API,有区域调色 API,有图像锐化 API,这个很轻易组装一个美颜的 API,所以你不需要从头开发出来。

这就体现了开闭原则,开对于于需求,对需求的变动保持开发,闭对于已有的成果,不轻易破坏原有代码的稳定性。

在这里插入图片描述

3. 里氏替换原则(Liskov Substitution Principle)

描述:所有引用基类的地方必须能透明地引用其子类。

理解:举个简单的例子,假如一个会议的参会要求是,你必须是农民。那么,可以定义农民为基类。所以,只要是集成了农民的子类比如花农、果农、种植水稻的农民都可以参加这个会议。

在这里插入图片描述

4. 迪米特法则(Law of Demeter)

描述:只和你的直接朋友对话,不和陌生人对话。

理解:这一个原则很具人生哲学代表性。本质还是为了解耦,避免不必要的耦合,降低复杂度,并且提高安全性。我们熟悉的谍战片都是这个模式,卧底只和一个上线对话。

在这里插入图片描述

5. 接口隔离原则(Interface Segregation Principle)

描述:客户端不应该依赖于它不需要的接口,不同的类之间的关系应该建立在最少的接口基础上。

理解:这其实就是解耦合的的具体体现。举个生动的例子。

我认为接口应该是一种承诺,或者是协议。

甲方给乙方一系列接口,就算给了承诺。

但甲方多变,乙方做好心理打算就好了,有些话听听就好了,提取最有用的信息,完成自己的任务,万一需求变动,再改也方便,如果一开始就整那些有的没的的东西,甲方再改动需求时,影响的范围会更大。

另外有种情况是,甲方有好几个乙方,不同的乙方需要一起协同。

这要求不同乙方之间约定好对话窗口,目的也是降低耦合度,保护自己尽可能少受需求变动之苦。

6. 依赖倒置原则(Dependence Inversion Principle)

描述:上层不应该依赖于底层,底层应该依赖于上层。抽象不应该依赖于细节,细节应该依赖于抽象。

理解:听起来挺拗口的,其实也好理解。

dip)

我是一个人,我从广州去深圳,我说我依赖汽车、火车、自行车,这站在软件角度都不对的,因为我太依赖于细节了,这样面对不了未来的需求变化,所以应该有更好的解决方法。

正确的应该是,我依赖于交通工具这个接口或者是抽象类。

那么,我坐飞机、自行车、汽车、火车都满足情况,未来可能还有地铁、轻轨等等,这就是面向未来的编程方式。

也是底层依赖上层,细节依赖抽象的意思。

依赖倒置的意思是,本来 Person 依赖于具体的实现类,后来引进了交通工具这个抽象类,自行车、汽车、火车这些交通工具反而要依赖于接口,这个从被依赖到依赖别人的改变就看做是依赖关系的倒置,所以叫依赖倒置。

最后,拥抱变化不是一句空话,你得反映到代码中来。

frank909 CSDN认证博客专家 CV(computer vision)
爱阅读的程序员,专注于技术思考和分享。关注架构设计、Android 开发、AI、数学、自动驾驶领域,个人公号:Frankcall
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页
实付 19.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值