软件设计模式(Software Design Pattern),又称设计模式,是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题,以及该问题的解决方案。也就是说,它是解决特定问题的一系列套路,是前辈们的代码设计经验的总结,具有一定的普遍性,可以反复使用。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。
在软件开发中,为了提高软件系统的可维护性和可复用性,增加软件的可扩展性和灵活性,程序员要尽量根据 7 条原则来开发程序,规范编码,从而提高软件开发效率、节约软件开发成本和维护成本。
开闭原则简单来说就是当应用的需求改变时,在不修改软件实体的源代码或者二进制代码的前提下,可以扩展模块的功能,使其满足新的需求。开闭原则也是面向对象程序设计的终极目标,它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。
开闭原则的实现方式:可以通过“抽象约束、封装变化”来实现开闭原则,即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层,而将相同的可变因素封装在相同的具体实现类中。因为抽象灵活性好,适应性广,只要抽象的合理,可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展,当软件需要发生变化时,只需要根据需求重新派生一个实现类来扩展就可以了。
里氏替换原则主要是对有关继承的一些原则规范,通俗来讲就是什么时候应该使用继承,什么时候不应该使用继承,以及其中蕴含的原理。里氏替换原则是继承复用的基础,它反映了基类与子类之间的关系,是对开闭原则的补充,是对实现抽象化的具体步骤的规范。子类可以扩展父类的功能,但不能改变父类原有的功能。也就是说:子类继承父类时,除添加新的方法完成新增功能外,尽量不要重写父类的方法。
里氏替换原则的实现方式:如果通过重写父类的方法来完成新的功能,这样写起来虽然简单,但是整个继承体系的可复用性会比较差,特别是运用多态比较频繁时,程序运行出错的概率会大大增加。如果程序违背了里氏替换原则,则继承类的对象在基类出现的地方会出现运行错误。这时其修正方法是:取消原来的继承关系,重新考虑设计它们之间的关系。
关于里氏替换原则的例子,最有名的是“正方形不是长方形”。当然,生活中也有很多类似的例子,例如,企鹅、鸵鸟和几维鸟从生物学的角度来划分,它们属于鸟类;但从类的继承关系来看,由于它们不能继承“鸟”会飞的功能,所以它们不能定义成“鸟”的子类。“玩具炮”炸不了敌人,所以不能定义成“炮”的子类等。
依赖倒置原则就是高层次模块不应该依赖低层次模块,如果两者都需使用则两者应该依赖它们的抽象;抽象不应该依赖细节,细节应该依赖抽象。其核心思想是:要面向接口编程,不要面向实现编程。依赖倒置原则是实现开闭原则的重要途径之一,它降低了客户与实现模块之间的耦合。
在软件设计和具体开发过程中,细节具有多变性,而抽象层则相对稳定,因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或者抽象类,而细节是指具体的实现类。使用接口或者抽象类的目的是制定好规范和契约,而不去涉及任何具体的操作,把展现细节的任务交给它们的实现类去完成。
依赖倒置原则的实现方式:
字面理解,单一职责原则就是自己只负责自己的事,不需要理会别人的事。如果了解面对对象编程,那么应该会很容易了解这个单一职责原则。在面对对象编程中,每个对象只负责自己的颗粒度比较细的任务,比如该提供数据的就只是提供数据,该负责提供服务的就只提供服务,或者只是维护对象之间的关系,这样的开发方式代码耦合度较低,较灵活,易扩展。当然也可以一个对象负责多个任务,但是任务多了修改起来就比较容易影响到其他的任务。在该原则下就要求一个对象不应该承担太多职责,如果承担了太多的职责,至少存在以下两个缺点:一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力;当客户端需要该对象的某一个职责时,不得不将其他不需要的职责全都包含进来,从而造成冗余代码或代码的浪费。
单一职责原则的实现方式:该原则核心就是控制类的粒度大小、将对象解耦、提高其内聚性。降低类的复杂度。一个类只负责一项职责。
接口隔离原则是对接口的使用进行约束规范的一个原则,它告诉我们要想把接口用好,关键在于隔离。隔离就是断绝接触、断绝往来(就像新冠肺炎)。那么我们使用接口时,要隔离什么东西呢?客户端不应该依赖它不需要的接口,这里的隔离是指客户端和它不需要的接口隔离,也就是客户端不要使用它不需要的接口,这个很容易理解,在实践中也很容易实现。我们着重看一下类间的依赖关系应该建立在最小的接口上,它要求“最小的接口”,也就是该接口中没有多余的方法,所以这里的隔离是指和多余的方法隔离。
接口隔离原则的优点:接口隔离原则是为了约束接口、降低类对接口的依赖性,遵循接口隔离原则有以下 5 个优点:
接口隔离原则的实现方法
在具体应用接口隔离原则时,应该根据以下几个规则来衡量:
迪米特法则可以简单说成:talk only to your immediate friends。 对于OOD来说,又被解释为下面几种方式:一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识,而且局限于那些与本单位密切相关的软件单位。迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖,因此,很容易使得系统的功能模块功能独立,相互之间不存在(或很少有)依赖关系。
迪米特法则不希望类之间建立直接的联系。如果真的有需要建立联系,也希望能通过它的友元类来转达。因此,应用迪米特法则有可能造成的一个后果就是:系统中存在大量的中介类,这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。
迪米特法则的实现方法:从迪米特法则的定义和特点可知,它强调以下两点:①从依赖者的角度来说,只依赖应该依赖的对象。②从被依赖者的角度说,只暴露应该暴露的方法。所以,在运用迪米特法则时要注意以下 几点:
它要求在软件复用时,要尽量先使用组合或者聚合等关联关系来实现,其次才考虑使用继承关系来实现。如果要使用继承关系,则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的,两者都是开闭原则的具体实现规范。通常类的复用分为继承复用和合成复用两种,继承复用虽然有简单和易实现的优点,但它也存在以下缺点:
采用组合或聚合复用时,可以将已有对象纳入新对象中,使之成为新对象的一部分,新对象可以调用已有对象的功能,它有以下优点:
合成复用原则的实现方法:合成复用原则是通过将已有的对象纳入新对象中,作为新对象的成员对象来实现的,新对象可以调用已有对象的功能,从而达到复用。
如有披露或问题欢迎留言或者入群探讨