软件设计师考试笔记-(2)

最新推荐文章于 2024-03-23 23:48:42 发布

Albert_GW

最新推荐文章于 2024-03-23 23:48:42 发布

阅读量113

点赞数 1

分类专栏：软件设计师文章标签： java 设计模式

本文链接：https://blog.csdn.net/weixin_45295678/article/details/113561950

版权

软件设计师专栏收录该内容

20 篇文章 9 订阅

订阅专栏

1.软件工程基础知识(2)

1.2设计原则

软件开发设计有7 种设计原则，是开发者必须尽量遵循的原则，各种原则要求的侧重点不同。其中，开闭原则是总纲，它告诉我们要对扩展开放，对修改关闭；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；单一职责原则告诉我们实现类要职责单一；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合度；合成复用原则告诉我们要优先使用组合或者聚合关系复用，少用继承关系复用。

1.2.1 开闭原则

1.2.1.1 定义

（Software entities should be open for extension，but closed for modification），这就是开闭原则的经典定义。
本身的含义是：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展已有模块的功能，使其满足新的需求。

1.2.1.1 作用意义

开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。
1、提高代码的可复用性：当粒度越小，被复用的可能性就越大；在面向对象的程序设计中，根据原子和抽象编程就可以提高代码的可复用性。
2、提高软件的可维护性：遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护。
3、提高软件测试效率：测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运行。

1.2.2 里氏替换原则

1.2.2.1 定义

（Inheritance should ensure that any property proved about supertype objects also holds for subtype objects）继承必须确保超类所拥有的性质在子类中仍然成立。

主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。

子类可以扩展父类的功能，但尽量不要改变父类原有的功能。（也就是少使用重写功能）

1.2.2.2 作用意义

实现开闭原则的重要方式之一。
克服了继承中重写父类造成的可复用性变差的缺点。
是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。

1.2.3 依赖倒置原则

1.2.3.1 定义

（High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions）。高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。

其核心思想是：要面向接口编程，不要面向实现编程。

1.2.3.2 作用意义

是实现开闭原则的重要途径之一。
降低类间的耦合性。
提高系统的稳定性。
减少并行开发引起的风险。
提高代码的可读性和可维护性。

1.2.4 单一职责原则

1.2.4.1 定义

（There should never be more than one reason for a class to change）。应该有且仅有一个引起它变化的原因。

该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：
一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；
当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。

单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。

1.2.4.2 作用意义

降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
提高类的可读性。复杂性降低，自然其可读性会提高。
提高系统的可维护性。可读性提高，那自然更容易维护了。
变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。

1.2.5 接口隔离原则

1.2.5.1 定义

（Clients should not be forced to depend on methods they do not use）。客户端不应该被迫依赖于它不使用的方法。

（The dependency of one class to another one should depend on the smallest possible interface）。一个类对另一个类的依赖应该建立在最小的接口上。

要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：
单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。

1.2.5.2 作用意义

将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。
如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。
使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。