软件体系结构设计的六项原则

原始链接:

原文: 更改班级的理由不应该超过一个.

翻译: 更改班级的理由不应该超过一个.

理解: 对于一堂课，只有一个改变它的理由. 坦率地说，不同的阶级有不同的责任，每个阶级都有自己的责任. 这就像一个团队，每个人彼此分裂和合作，彼此不影响，并且做自己的事.

应用程序: 在进行系统设计时，如果发现一个类有两个职责，请问自己一个问题: 我们可以将这个类分为两个类吗？如果确实需要，则将其分开. 永远不要让课堂做得太多！

原始: 类，模块和函数之类的软件实体应打开以进行扩展，而封闭以进行修改.

翻译: 类，模块和函数之类的软件实体应打开以进行扩展，但应关闭以进行修改.

理解: 简而言之，可以扩展软件架构设计原则，不能修改. 换句话说，您可以扩展该类，但不能修改该类.

应用程序: 更改需求时，需要修改代码. 此时，您要做的是尝试通过继承或组合来扩展类的功能软件架构设计原则，而不是直接修改类的代码. 当然，如果您可以确保它不会对整个体系结构产生任何影响，则无需使其变得如此复杂，只需更改此类即可.

原始的: 使用对基类的指针或引用的函数必须能够在不知道的情况下使用派生类的对象.

翻译: 使用基类的指针或引用函数必须能够在不知道的情况下使用派生类的对象.

理解: 父类可以替换子类，但是子类不一定替换父类. 换句话说，您可以将所有父类替换为代码中的子类，该程序将不会报告错误，并且在运行时不会有任何异常，但不一定是正确的.

应用程序: 继承类时，请确保重写父类中的所有方法. 特别要注意父类的受保护方法（它们通常会被您覆盖）. 子类应尽量不要公开其公共方法. 该方法用于外部调用.

原始内容: 仅与您的直属朋友交谈.

翻译: 仅与您最直接的朋友交流.

理解: 最小化对象之间的交互，从而减少类之间的耦合. 简而言之，必须做到: 低耦合，高内聚.

应用程序: 设计系统时，请勿让一个类依赖于太多其他类. 您需要最小化依赖性. 否则，你甚至都不知道该死.

原文: 一类对另一类的依赖关系应取决于最小的接口.

翻译: 一类与另一类之间的依赖关系应取决于最小的接口.

理解: 请勿在外部公开不重要的接口. 换句话说，该接口是为其他人调用的，因此请不要让其他人感到尴尬，以确保该接口的实用性. 她也很好，我也是.

应用程序: 当需要在外部公开接口时，需要三思. 如果确实不需要外部提供，请将其删除. 一旦提供了它，就意味着您将来必须再做一件事，何必为自己找点事呢.

原文: 高级模块不应依赖于低级模块. 两者都应依赖抽象. 抽象不应依赖细节. 细节应该取决于抽象.

翻译: 高级模块不应依赖于低级模块，而应依赖于抽象. 抽象不应该依赖细节，细节应该依赖抽象.

理解: 应该是面向接口的编程，而不是面向实现的编程. 面向实现的编程等效于谈论事物，这是前向依赖关系（正常的人类思维）. 面向接口的编程等效于通过事物的外观来查看本质，这就是反向依赖关系，即依赖关系反转（程序员思维）.

应用程序: 并不是说所有类都必须具有相应的接口，而是如果有接口，请尝试使用该接口进行编程.

将以上六个原理的英文缩写放在一起就是SOLID（稳定），因此也称为SOLID原理. 只有满足这六个原则，才能设计出稳定的软件架构！但是毕竟，它们只是原则，它们只是我们四个人帮助我们的建议. 有时，我们仍然必须学会保持灵活性，不要试图变得不合理，否则我们只会使简单的问题复杂化

当您想扩展类的功能时，优先使用组合而不是继承. 这项原则在23种经典设计模式中经常使用，例如: 代理模式，装饰模式，适配器模式等. 可以看出，江湖的地位非常高！

当A模块依赖于B模块，B模块依赖于C模块，C依赖于A模块时，会发生循环依赖关系. 在设计中应该避免这个问题，可以通过引入“中介模型”来解决.

变量类应放在同一程序包中以隔离更改. 该原则是“开闭原则”的扩展.

如果重用包中的类，则等效于重用包中的所有类. 我们希望尽可能减小包装尺寸.

好莱坞明星经纪人通常都很忙. 他们不想被打扰. 他们经常说: 不要给我打电话，我会打电话给你. 译为: 不要与我联系，我会与您联系. 与软件设计相对应，最著名的是“控制反转”（或“依赖注入”）. 我们不需要在代码中主动创建对象，但是容器可以帮助我们创建和管理这些对象.

不要让重复的代码无处不在，要使它们有足够的重用性，因此请尽量封装.

不要使系统复杂，界面简单，功能实用，操作方便. 使它足够简单和足够傻.

模块内部需要高内聚力，模块之间需要低耦合.

尝试按惯例减少配置，以提高开发效率并尝试实现“零配置”. 许多开发框架都这样做.

定义接口时，您需要执行的是命令和查询，您应该将它们分开，而不是将它们摩擦在一起.

将一个复杂的问题分成多个简单的问题，然后一个个地解决这些简单的问题，然后解决这个复杂的问题. 困难在于如何分离.

模块或系统之间的交互基于合同（接口或抽象），而不依赖于具体的实现. 这个原则表明我们应该是面向合同的编程.

从一开始就不要设计非常复杂的系统，也不要陷入“过度设计”的深渊. 困难应该是使系统足够简单而不丢失可伸缩性.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-207703-1.html