大白话设计模式七大原则

Posted 程序员大帝

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了大白话设计模式七大原则相关的知识,希望对你有一定的参考价值。

点击蓝色“程序员大帝 ”关注我哟

加个“星标”,及时阅读最新技术文章

每日鸡汤,好喝

这是程序员大帝的第8 篇原创文章

前言

设计模式是前辈们用毕生心血专业填坑换来的经验,把这些经验加工精简,就成了设计模式,也就是套路。有了套路,就能让我们加快软件的开发速度和扩展性(听起来怎么好像是 PUA 的感觉大白话设计模式七大原则大白话设计模式七大原则)。


大白话设计模式七大原则

设计模式包含了大量的编程思想,真正掌握并不容易,在学习每种具体的模式之前,咱们今天先来看看需要遵循的七大原则。相信大家耐心看了之后肯定有收获,码字不易,别忘了「在看」,「转发」哦。

  • 单一职责原则

  • 开闭原则

  • 里氏替换原则

  • 依赖倒转原则

  • 合成复用原则

  • 接口隔离原则

  • 迪米特法则

正文

01 单一职责原则

一职责原则( Single Responsibility Principle )为我们提供了一个编写程序的准则,目的是把导致其变更因素的缩减到最少(比如你约妹子吃饭,起码提前看看天气预报再约时间)。


如果一个类承担的职责过多,就等于把这些职责耦合在一起。


一个职责的变化可能会影响或损坏其他职责的功能。而且职责越多,这个类变化的几率就会越大,类的稳定性就会越低。


所谓是闻道有先后,术业有专攻。做人也要避免样样都玩,样样都不精,在设计类的时候,要使其功能职责单一纯碎,把本职工作做到最好。

大白话设计模式七大原则

我们在软件开发中,需要面临很多任务,比如任务 T1,任务 T2,如果让一个类C负责这两个不同的任务。需求变更的时候,要对任务 T1 的代码修改来满足新的业务需求。


可会发现 T1 代码的修改竟然会导致原本能够正常运行的 T2 发生错误,而修复 T2 又不得不回过头再去对T1的修改,这便是因为类 C 的职责不够单一,把任务 T1 与任务 T2 耦合在一起导致的。

02 开闭原则

开闭原则( Open-Closed Principle )确的告诉我们:软件实现应该对扩展开放,对修改关闭。


简单来说,功能应该通过扩展来实现变化, 而不是通过修改已有的代码来实现变化。

为什么要遵循开闭原则?

(1)开闭原则堪称是最基础的设计原则,是精神领袖。在 Java 语言中,抽象类就是开闭原则的一种非常好的现。


(2)开闭原则可以提高维护性。一款应用的诞生到运行,开发软件可以说是一次性的工作,真正让人头疼的是在后期的维护与扩展。随着我们的应用越来越流行,用户越来越多,产品经理肯定要不停地提各种需求。


大白话设计模式七大原则


现在各大公司人员更新迭代速度明显加快,“每年输出一千名阿里工作10年以上的人才”。


连网友都翻出这句话编写段子:

“都是裁员,马老师说的就是那么大局观。华为:放弃平庸员工。腾讯:结构性优化。百度:鼓励狼性,淘汰小资。蔚来:局部优化,提高运营效率。科大讯飞:提前吃饭的员工需要被优化。京东:淘汰掉因身体原因不能拼搏的员工。


扯远了,如果你入职接手了别人的项目,如果让你从头开始读一遍原来的代码,然后再根据新的需求修改老代码,这是非常痛苦的事情,简直可以说是精神上的折磨和摧残。


但是如果我们仅仅是进行扩展,那么事情就会变得容易很多。


(3)开闭原则可以提高代码的复用性。在面向对象的设计中,所有的逻辑都是从原子逻辑组合而来,不是在一个类中独立实现一个业务逻辑。只有这样的代码才可以复用,粒度越小,被复用的可能性越大。

如何使用开闭原则?

万物皆发展变化,有变化就要有策略去应对,怎么快速应对呢?这就需要在设计之初考虑到所有可能变化的因素,然后留下接口,等待“可能”转变为“现实”。


使用 Java 编程时,抽象类和接口是这种思想最好的体现。通过对一组事物的通用描述,没有具体的实现,代表它可以有非常多的可能性,可以跟随需求的变化而变化。


同时我们为这些变化创建稳定的接口时,具体可以有两种操作方式:

  • 将相同的变化封装到一个接口或抽象类中。

  • 将不同的变化封装到不同的接口或抽象类中,不应该有两个不同的变化出现在同一个接口或抽象类中。

03 里氏替换原则

Java 中为我们提供了继承的实现,那么在整个系统中,里氏替换原则( Liskov Substitution Principle )指的是,如果一个地方可以接受某个基类,那么必然也可以接受这个基类的子类。


比如一个方法接收的参数是类型P,那么如果将其替换成 T 的子类 C,程序的行为不应该发生变化。


使用里氏原则也要遵循几个行为准则:

(1)假设类 B 继承类 A 时,B 可以添加新的方法完成新增的功能,但不要重写父类 A 的方法,也不要重载父类A的方法。


这里再说重载( overload )重写( override ) 的区别:


重写是子类对父类的允许访问的方法的实现过程进行重新编写, 返回值和形参都不能改变。即外壳不变,核心重写!


重载是在一个类里面,方法名字相同,而参数不同。返回类型可以相同也可以不同。


每个重载的方法(或者构造函数)都必须有一个独一无二的参数类型列表。


最常用的地方就是构造器的重载。


(2)如果随着业务的扩展,需要对基类 A 和子类 B 进行重构,应该让它们去继承一个更加通用的基类。


(3)里氏替换原则可以正着用,但是不能反着用,在子类出现的地方,父类未必可以胜任。

04 依赖倒转原则

大家刚听到这些名词都会觉得云里雾里,依赖倒转原则( Dependency Inversion Principle )简单来说就是:

(1)高层模块不应该依赖于低层模块,二者都应该依赖于抽象。


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


还不明白?


其实大家在平时编程时候已经不自觉地使用了依赖倒转原则,核心思想就是面向接口编程。


接口就是一种抽象,只要不修改接口声明,大家可以放心大胆调用,至于接口的内部实现则无需关心,可以随便重构。


这里,接口就是抽象,而接口的实现就是细节。


只要接口是稳定的,那么任何一个的更改都不用担心其他的受到影响,这就使得无论高层模块还是低层模块都可以很容易地被复用。

大白话设计模式七大原则

依赖倒转原则是一种通识,具体用哪种语言来编写程序并不重要,设计的出发点就是为了应对变化的问题。


再举一个生活中的例子,电脑里的内存卡槽,其实就是一种接口。只要符合这个接口的要求,无论是用金士顿的内存,还是其它牌子的内存,无论是4G的,还是8G的,都可以很方便、轻松的插到电脑上使用。

大白话设计模式七大原则

05 接口隔离原则

通过上面几个规则我们已经知道,面向接口编程促进了代码的解耦,并使架构体系更加鲁棒。


但一个东西再好吃也要适度,所以就提出了接口隔离原则 Interface Segregation Principle 。主要目的是为了对接口的使用进行约束规范,它告诉我们要想把接口用好,关键在于隔离。


隔离,指断绝接触、断绝往来。

大白话设计模式七大原则

那么我们使用接口时,要隔离什么东西呢:

(1)客户端不应该依赖它不需要的接口,这个很容易理解,在实践中也很容易实现。


(2)类间的依赖关系应该建立在最小的接口上,它要求“最小的接口”,也就是该接口中没有多余的方法,所以这里的隔离是指和多余的方法隔离。


综上所述,接口隔离原则告诉我们,不要把一大堆方法塞进一个接口里,导致这个接口变得臃肿无比。应该要根据实际需要,让接口中只有用得上的方法,也就是说要细化我们的接口。


接口隔离原则的要点,就是要细化我们的接口。那么这样做具体有什么好处呢:

  • 避免接口污染

  • 提高灵活性

  • 提供定制服务

  • 实现高内聚

06 合成复用原则

合成复用原则(Composite Reuse Principle)字面意思说的很清楚,写代码时应该尽量使用对象组合,而不是使用继承来达到复用的目的。


使用继承来实现复用非常简单,但没有足够的灵活性,只能在有限的环境中使用。


假设一个子类继承了父类的所有方法,但是如果父类当中有方法被改变了,子类当中就找不到相应的方法,造成子类出错。


为了避免这种情况的出现,第一是父类专门为扩展而设计,几乎不会改变,并提供完整的文档,第二是父类和子类在同一个包下面,都由同一个程序员负责,保证好父类的改变能够及时通知到子类当中。


显而易见,无论哪种方式都不够灵活。


组合复用的耦合度相对较低,可以在运行时动态选择性地调用成员对象进行操作,使系统更加灵活,一个类的变化对其他类造成的影响相对较少。


因此一般首选使用组合/聚合来实现复用;其次才考虑继承,在使用继承时,需要严格遵循里氏代换原则,有效使用继承会有助于对问题的理解,降低复杂度,而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度,因此需要慎重使用继承复用。


07 迪米特原则

迪米特原则(Law of Demeter)也被称为最少知识原则,一个对象应该对其他实体依赖越少越好。迪米特法则的核心在于类间的解耦,只有弱耦合之后类的复用率才会提高。


我们用人际交往来说,大家平时肯定和自己朋友交流得最多,但朋友之间也是有距离的。


对别人不能暴露太多,否则二次修改的时候,会让影响的范围增大,这也要求类间public方法不能肆无忌惮的暴露。


信息的隐藏可以使各个子系统之间脱耦,从而允许它们独立地被开发、优化、使用和修改。


依赖的模块越少,它能够独立在其他地方使用的能力越强。构建一个大规模的系统时,信息的隐藏显得尤其重要。

大白话设计模式七大原则

如果模块A和模块B都强依赖于模块C,那么A和B的开发进度都可能就会需要跟着C来走,一个功能C无法完成,A和B也无法继续开发。


同时如果和陌生人交往时,要抱有一定的戒心,有互相相信的朋友作为中间人最好。


如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用,而是通过引入一个第三者发生间接交互。

大白话设计模式七大原则

大白话设计模式七大原则

程序员大帝




原创不易,感谢点赞、在看和转发的热心小伙伴~

以上是关于大白话设计模式七大原则的主要内容,如果未能解决你的问题,请参考以下文章

设计模式 - 七大设计原则

设计模式----七大原则和UML类图

设计模式七大原则

面向对象七大设计原则

-设计模式七大基本原则分析+实战+总结(详细)

设计模式的七大设计原则