应用系统基本设计原则 - SOLID

应用系统的设计应该遵循一些基本的设计原则，这能帮助你有效地创建一个低成本、高可用、高可扩展的应用程序。在这里，我们引入一个SOLID设计原则，SOLID由如下几点构成：

• Single Responsibility Principle（单一职责原则）
• Open Close Principle（开-闭原则）
• Liskov Substitution Principle（里氏替换原则）
• Interface Segregation Principle（接口分离原则）
• Dependency Inversion Principle（依赖反转原则）

下面简要介绍一下这几个“原则”。

• 单一职责原则：每个类应该只有一个独一无二的职责，或者说每个类只能有一个主要功能，由此派生出一个结论：每个类应该尽可能少地依赖于其它类
• 开-闭原则：每个类，应该对“扩展”进行开放，而对“修改”进行封闭，也就是支持扩展，而不是支持修改：类中的方法可以通过继承关系进行扩展，而不会改变类本身的代码
• 里氏替换原则：子类可以被基类型（基类或者接口）替换。应用程序依赖抽象运行，其行为不会因为具体实现的改变而更改，应用程序应该依赖于抽象（基类或者接口），而不是具体实现。接下来将要讨论到的“依赖注入（Dependency Injection）”就与这条原则有关
• 接口分离原则：接口的职责也应该是单一的，接口中应该包含哪些方法，需要进行严格的评估，如果其中某些方法的职责与接口的本身定义不相符合，则应该将其分离到其它接口中。类需要根据其调用者所需要的不同接口类型，来暴露不同的接口
• 依赖反转原则：抽象不能依赖于具体，而具体则应该依赖于抽象。类之间的直接依赖应该用抽象来取代，这样做的一个优点是，我们可以实现自上而下的设计方式：在下层的具体实现还没有确定的情况下，只要能够在抽象层面将接口确定，就能够完成上层的设计与开发，这同样给可测试性带来便捷

除了以上所述的SOLID原则之外，还有以下几个关键的设计原则可供参考：

• 组件设计应该是高内聚的：相信大家都很熟悉这点了，就不多说了。例如：不要将数据访问逻辑写进领域模型的业务逻辑中，这与上述“单一职责原则”是密切相关的
• 将Cross-Cutting的代码从特定于应用程序的逻辑中分离开来：Cross-Cutting的代码是一些面向横面的代码，比如安全、操作管理、日志以及测量/计量系统等。将这些代码与应用系统业务逻辑混在一起会增加系统的复杂性，给将来的扩展和维护造成很大的麻烦。这与“面向方面编程（Aspect-Oriented Programming，AOP）”有关
• 关注点分离（Separation of Concerns，SoC）：将应用系统分成多个子部分（子系统），各个部分之间的功能尽量不要重复，其目的就是为了减少交互点，以实现高内聚和低耦合
• Don’t Repeat Yourself（DRY）：一个特定的功能只能在某个特定的组件中实现一次，同样的功能不要在多个组件中重复多次
• 避免YAGNI（You Ain’t Gonna Need It）效应：只考虑和设计必须的功能，避免过度设计