设计原则

分离关注点

分离关注点是开发时的指导原则。 此原则主张应根据软件执行的工作类型将软件分离。

从体系结构上来说，按此原则有逻辑地构建应用程序应将核心业务行为与基础结构及用户界面逻辑区分开。

封装

应用程序的不同部分应通过封装与应用程序中的其他部分隔离开。 只要不违反外部协定，应用程序组件和层应能在不中断其协作者的情况下调整其内部实现。 正确使用封装有助于在应用程序设计中实现松散耦合及模块化，因为只要维持相同的接口，就可以用替代实现来替代对象和包。

在类中实现封装的方式是限制对该类的内部状态的外部访问权限。 如果外部参与者想操作对象的状态，则应通过明确定义的函数（或属性 setter）来进行操作，而非直接访问该对象的私有状态。

依赖关系反转

应用程序中的依赖关系方向应该是抽象的方向，而不是实现详细信息的方向。

直接依赖项关系图:

应用依赖关系反转原则后，A 可以调用 B 实现的抽象上的方法，让 A 可以在运行时调用 B，而 B 又在编译时依赖于 A 控制的接口（因此，典型的编译时依赖项发生反转）。 运行时，程序执行的流程保持不变，但接口引入意味着可以轻松插入这些接口的不同实现。

反转依赖项关系图:

 

 依赖项反转是生成松散耦合应用程序的关键一环，因为可以将实现详细信息编写为依赖并实现更高级别的抽象，而不是相反。 因此，生成的应用程序的可测试性、模块化程度以及可维护性更高。 遵循依赖关系反转原则可实现依赖关系注入。

单一责任

 单一责任原则适用于面向对象的设计，但也可被视为类似于分离关注点的体系结构原则。遵循这一原则有助于生成更松散耦合和模块化的系统，因为许多类型的新行为可以作为新类实现，而不是通过向现有类添加其他责任。 添加新类始终比更改现有类安全，因为还没有任何代码依赖于新类。

在整体应用程序中，可以在高级别将单一责任原则应用于应用程序中的层。 显示责任应位于 UI 项目中，而数据访问责任应位于基础结构项目中。 业务逻辑应位于应用程序核心项目中，该项目易于测试，并且可以独立于其他责任进行逐步改进。