软构——可维护性

• 可维护性的常见度量指标

1. Maintainability  可维护性
2. Extensibility  可扩展性
3. Flexibility  灵活性
4. Adaptability  可适应性
5. Manageability  可管理性
6. Supportability  支持性

• 可维护性的五个rule：

1. Direct Mapping 直接映射
2. Few Interfaces 尽可能少的接口
3. Small Interfaces 尽可能小的接口
4. Explicit Interfaces 显式接口
5. Information Hiding 信息隐藏

• 可维护性构造原则

SRP单一责任原则：不多于一个原因使得ADT发生改变，否则要拆分开

 

OCP开放—封闭原则：对拓展开放（对开发者），对更改封闭（对使用者）。简单理解就是模块可以添加新的行为来适应需求变化，但是不能修改已有的代码实现新功能。关键在于抽象技术。
举例：假设我养了狗，我有一个喂养狗feed（）方法，后养了猫，我们不应该单独加一个cat.feed()，而是抽象一个pet类，我们只需要完成喂养宠物pet.feed()即可，这样就可以对狗和猫以及其他宠物的功能拓展，而没有修改我们作为主人的pet.feed()方法代码，这是OCP的一个例子。

 

LSP里式替换原则：子类型能够替换基类型，并且满足对输入，输出，异常等的要求（前面提过）前置更弱，后置更强，要能通过父类的测试用例，不能产生预期之外的结果。

Java中的编译器强制执行的规则（静态类型检查）：

1. 子类型可以增加方法，但不可删除方法
2. 子类型需要实现抽象类型中的所有未实现方法
3. 协变：子类型中重写的方法必须有相同或子类型的返回值或者符合co-variance的参数
4. 逆变：子类型中重写的方法必须使用同样类型的参数或者符合contra-variance的参数
5. 子类型中重写的方法不能抛出额外的异常

也适用于指定的行为（方法）:

1. Same or stronger invariants 更强的不变量
2. Same or weaker preconditions 更弱的前置条件
3. Same or stronger postconditions 更强的后置条件

ISP接口隔离原则：只提供必需的接口，不强迫用户依赖他们不需要的接口。需要接口足够细化，类之间的依赖关系应该建立在最小的接口上，建立单一接口，接口不要过分臃肿。接口要尽量细化，接口中要尽量少。

 

DIP依赖转置原则：具体依赖抽象，而非抽象依赖于具体。实际类之间不发生直接的依赖关系，而是通过抽象类或者接口实现，这样可以降低耦合度，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

 

• 小结

        我们开发软件并不是交付以后就撒丫子跑了不管事了，我们也需要在软件出现问题的时候能对其进行修改，在有新要求时能增添功能，这都需要我们的软件拥有极强的可维护性，只有如此才能使得我们能在出现各种情况下能用较小的力气完成维护工作。