软件工程相关

软件开发模型

瀑布模型

瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动。前一阶段的任务完成后，才能开始进行后一阶段的工作，不可回溯性 ，上一阶段的开发结果是下一阶段开发的输入。
缺点：
1、确定软件需求后才能进行后续的软件开发工作，但多数场合给出大型软件项目的全部需求是困难的。
2、由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，失去了及时纠正的机会，增加了开发的风险；
3、早期的错误可能要等到开发后期的测试阶段才能发现，由于测试时间短，测试不充分，可能会把缺陷遗留给线上带来严重的后果。

V模型

软件的分析、设计过程与软件测试过程一一对应，强化了软件设计和测试的关系，加强了软件的质量保证。缺点：开发周期长。

快速原型模型

快速原型的基本思想是快速建立一个能反映用户主要需求的原型系统给用户使用。开发人员按照用户使用后的意见快速地修改原型系统，然后再次请用户试用……反反复复地改进，直到原型系统满足用户的要求。
缺点： 快速建立的系统结构加连续修改可能导致产品质量低下，软件可维护性差，对于用户合作要求高，如果合作不好，反而会拖延开发进度 不适用于开发大型系统。

增量模型

又称演化模型。增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品。第一个增量往往是实现基本需求的核心产品。
缺点：由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这对系统的设计和开发提出了较高的要求。

软件设计原则

1. 开闭原则：指的是对扩展开放，对修改封闭。这个原则的核心思想是通过扩展已有的代码来实现新的功能，而不是对已有的代码进行修改。
2. 单一职责原则：要求一个类只负责一个单一的职责或功能。这样的设计可以使代码更加清晰、可维护和可扩展。
3. 依赖倒置原则：核心思想是要求高层模块不应该依赖于低层模块，二者应该依赖于抽象(接口或抽象类)。抽象不应该依赖于细节，细节应该依赖于抽象。
4. 迪米特法则：核心思想是一个对象应当尽可能少地了解其他对象，从而降低系统的耦合性，提高系统的模块化。
5. 里氏替换原则：子类对象必须能够替换父类对象，而不影响原有程序的正确性。
6. 接口隔离原则：核心思想是为每个类创建专门的接口，而不是为所有依赖类创建一个通用的接口。

设计模式

1. 工厂方法模式：定义了一个用于创建对象的接口，让子类决定实例化哪一个类。
   比如我们可以实现一个车的抽象接口（比如 Car），然后客户端可以通过不同的工厂类（如 MercedesFactory 或 BMWFactory）来创建不同品牌的车，而无需直接依赖具体的车类。
2. 抽象工厂模式：提供一个接口，用于创建一系列相关或相互依赖的对象，而无需指定它们的具体类。
   比如我们可以使用抽象工厂模式来实现一个交通工具抽象工厂，能够生产不同品牌的汽车（Car）和自行车（Bike）。在这个模式中，不同品牌的工厂（例如，奔驰工厂和宝马工厂）可以生产属于自己品牌的汽车和自行车，客户端无需直接依赖具体的汽车类或自行车类。
3. 单例模式：确保一个类只有一个实例，并提供一个全局访问点。
4. 原型模式：通过复制现有对象来创建新对象。
5. 适配器模式：将一个类的接口转换成客户希望的另一个接口。比如现在我想手机充电，但是插座不适配，我就需要一个转接头，这个转接头就是适配器所做的行为。
6. 装饰器模式：核心在于能够在不改变现有类的前提下，动态地给对象添加新的功能。装饰器模式可以看作是对继承的替代方案，通过组合而非继承来扩展对象的功能。
7. 观察者模式：定义对象间的一种一对多的依赖关系，使得当一个对象状态改变时，所有依赖它的对象都会得到通知并自动更新。
8. 状态模式：允许对象在其内部状态发生改变时改变它的行为。
9. 外观模式：为多个复杂的子系统提供一个一致的接口，来隐藏系统的复杂性，从而使得这些子系统更加容易被访问。