第二周作业二 - 学习总结

概述

软件设计一般原则，是软件设计过程中一般问题解决思路的总结。按照原则去设计软件，能规避大部分常见问题，使设计出来的软件系统满足高内聚、低耦合的要求，并具备高可扩展性、可移植性、健壮性。

抽象

一个类包含两部分内容：成员变量和成员方法。抽象时可以从这两个维度单独或者综合考虑。既可以往上抽取到基类，又可以水平方向抽象，通过组合方式赋能给目标类。

基于 Java 的 Lambda 特性，函数可以被传递，不必再局限于 接口 来实现多态，可以进行更细粒度的差异化操作

1、开闭原则

对修改关闭，对扩展开放。

此原则要求不修改已有代码，只通过新增代码来实现新需求。这需要对系统功能有较高视野的把控，了解系统未来的发展方向，从而在关键设计处预留扩展点，且以较为合适的方式组织起来。

2、依赖倒置原则

高层模块不能依赖底层模块，而是大家都依赖抽象

抽象不能依赖实现，而是实现依赖抽象

对系统中的对象做合适的抽象，

框架只依赖抽象。一个抽象就是一个承诺，代表能完成一系列动作。基于这些先行承诺，系统可以在没有具体实现的情况下完成设计。

抽象设计类似于做计划，并不用等工作实际完成，我们只是定了一个必定能实现的承诺，基于这个承诺，我们就能设计出另外的承诺，所有的承诺通过交互、流程控制就能得出我们需要的系统。而设计这些承诺时，实际的工作并未展开，因为人具有想象力，我们假设承诺已经完成，就可以在脑中基于假设来构建假设，最终形成系统。当真正开始实践时，只需要完成当初的承诺，把抽象 一一落实，那整体系统必定会按照我们预想的那样 正常工作。

3、里氏替换原则

LSP

传统判断继承是否合适的标准：IS A，这是一种静态分析方式

里氏替换原则：任何地方使用父类的地方都可以用子类替换。这是动态分析，基于程序运行上下文中所有场景来检查。

结论：同时满足 IS-A 关系和里氏替换原则才是好的继承。不符合 IS-A 关系的继承，一定不满足里氏替换原则

Java 中单继承的限制，会对抽象设计造成一定的限制，因此有限通过组合来代替继承。A is a B，从另外一个角度可以理解为：A 具有 B 的特征、能力。除了继承，可以把 B 组合进 A，当需要使用 B 的能力时，A 委托 B 来完成。

违反

• 派生类中退化函数：子类中对函数做了退化？只能扩展？怎么做差异化？退化的标准是什么

• 子类抛出父类中不会产生的异常：是指不会抛出 方法签名之外的异常，还是不能抛出事实上的异常？

4、单一职责原则

Single Responsibility Principle,SRP

一个类只有一个职责，太多功能需要做拆分，拆分标准：一个类打开后代码量只占一屏，通常是职责单一的(太夸张了)。

完全做到 SRP 困难：通过接口隔离原则来实现。接口是隔离的，实现是合并的

5、接口隔离原则

不应该强迫使用端看到、依赖它们并不关心的方法：可以依据使用端角色对方法做分类，对接口做拆分。

此原则和 SRP 一起使用，相互促进，最显著的效果就是降低耦合。通过把一个大类拆分成小类，能隔离风险、隔离变化，也能从一定程度上满足 开闭原则。

总结

软件设计的这几个原则并不是孤立的，它们是系统的、相互关联、相互制约的，在实践中，根据实际场景可以有所偏颇。