常见的架构设计原则总结

[TFdream]

转载 常见的架构设计原则总结：https://mp.weixin.qq.com/s/B1t29lHUaD4N0mDCvZjIPg

通用原则

• KISS原则（Keep it simple and stupid） 最小代价（努力）原则 尽可能在一开始的时候，作出正确的选择，因为一旦这个架构设计出现，后面的人很有可能不愿意为了更好的架构而改进，而是遵循已有的设计。
• 最小意外原则 好的设计应该避免意外，遵守通用的规范和习惯，代码也是。这些意外其实是软件架构和设计中的复杂因素。最小意外也就意味着尽可能的简单。
• DRY原则（Dont repeat yourself） 重复是软件的原罪之一，“Dont repeat yourself” 告诉我们应该尽可能的消灭重复和冗余。重复使得软件的阅读，修改，测试变得复杂，消灭重复，是使软件变得简单的手段之一。

面向对象的设计原则

一、单一职责原则（SRP）

概念

一个类只负责一项职责

问题由来

类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。

解决方案

遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

职责扩散

• 所谓职责扩散，就是因为某种原因，职责P被分化为粒度更细的职责P1和P2
• 职责扩散会引起对单一职责的冲突

类级别和方法级别的单一职责

• 类级别 比较严格，整个类应该只负责一个职责
• 方法级别 当修改类代价比较大时，可以采用方法级别的单一职责。即一个类中不同方法负责不同职责

优点

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

二、开闭原则（OCP）

概念

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。 开闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定灵活的系统。

问题由来

在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。

解决方案

当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

如何做到开闭原则

用抽象构建框架，用实现扩展细节。

三、里氏替换原则（LSP）

概念

• 所有引用基类的地方必须能透明地使用其子类的对象
• 通俗讲，子类可以扩展父类的功能，但不能改变父类原有的功能

问题由来一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。

在实际编程中，我们常常会通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的几率非常大。如果非要重写父类的方法，比较通用的做法是：原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合，组合等关系代替。

总结

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
• 子类中可以增加自己特有的方法。
• 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
• 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

三、接口隔离原则（ISP）

概念

客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上

问题由来