S.O.L.I.D原则和汇编？

Question

例如，关于Single Responsibility原则：

我们来谈谈Radio课程：

有人可能会说Radio类有两个职责，即量和站管理。这些操作将使用它从客户端的完全不同的区域调用。

因此我们有这个：

一切都很好。

但我总是看到这样的句子：

  

所以现在当我们需要更改时，所有代码都依赖于   破坏的组件不甚至需要重新编译。

等一下！

如果我需要更改VolumeManager课程，我将不必重新编译Radio和StationManager。 但我必须停止（在网络上）iis才能让应用程序使用新的DLL，而 会导致应用程序停止

此外，在console中，我将不得不终止整个程序以更改dll，因为它被进程锁定（当应用程序运行时你无法更改dll - 文件被锁定）< / p>

即使我将使用GAC - 我也必须停止该程序以便对该dll进行操作。

那么它能拯救我什么？ 编译就是 - 右键单击​​并构建。多数民众赞成

我没有看到提及的好处：“你只需要编译破碎的类.. ”

我错过了什么？

http://www.gontu.org/solid-single-responsibility-principle/查找单词“build”

http://epic.tesio.it/doc/manual/solid_principles.html查找单词“recompiled”

http://www.dananhudson.com/?tag=solid查找单词“recompile”

Answer 1

忘记编译时间，忘记重启应用程序。

SOLID是关于清洁代码和可维护性的。它不是关于运行时的任何事情，而是关于代码随着时间的推移变得越来越复杂并且难以维护，这就是真正的成本。

Answer 2

如果您可以证明更改的范围有限，则有些情况下，在政治上更容易将更新部署到现有应用程序：例如，如果只需要更新一个DLL。 （请注意，这并不意味着每个类都应该在自己的DLL中。但很可能，不是所有你的类都在同一个DLL中）

然而，另一个优点是更多概念：如果我不必重新编译DLL，那么我肯定知道我没有破坏其中的任何内容。必须触及的代码越少，我引入错误的可能性就越小。

Answer 3

与C ++相比，C＃中的编译时间不是问题。一个大的C ++项目可能需要很长时间才能编译。当尝试在一个区域中进行更改导致重新编译不相关的组件时，它变得非常令人沮丧。单一职责指导更加紧凑的依赖关系，从而改善编译问题。

Answer 4

我强烈推荐Bob叔叔关于SOLID原则的clean coders视频。

独立可部署性的主要思想是，可以独立部署的模块也可以独立开发。通常，您不会独立部署模块，但您可以从独立开发模块中受益。

与编译过程的影响相关，这可能与C ++相关，其中每个编译单元（cpp文件）需要在依赖于更改的代码和精心构造的依赖图时重新编译，其中更改仅影响更改一个编译单元，会严重影响编译时间。无论如何，除非您正在使用旧硬件，否则您可能不应该将编译时间作为优先事项。

关于在修改和部署独立模块时必须停止应用程序（Web或控制台） - 这可以通过使用插件框架来避免，该框架可以动态地将新的/更改的程序集加载到应用程序中 - 并且SOLID原则可以是适用于构建插件及其接口的方式。请记住，这可能会增加更多的复杂性，我建议避免这种情况，只需在部署时重新启动应用程序。

Answer 5

我不认为保存的编辑是重要的，而不是为什么可以在没有它的情况下离开。

因为某个更改包含在您应用的有限区域内。这本身就是一件好事 - 在一个设计良好的系统中，我不必理解完整的应用程序以改变它的行为，我认为这才是最重要的。

dll被锁定或IIS重新启动受影响的App-Pool（我可能会说它做得很好）这一事实可能会在未来的系统中得到缓解。

事实上，通过一些影子复制和App-Domain hokey-pokey，您可以编写一个程序，在交换dll时不需要重新启动。

Answer 6

我认为设计模式的重点在于灵活性。如果您曾经决定实现各种类型的StationManager和VolumeManager，则必须在Radio类中不更改任何代码。唯一的变化将由无线电课程的实例化强加。为此，您仍然需要重新启动应用程序，但是您的类中没有任何意大利面条代码，并且有多个if-else语句。没有代码会改变，你只需为新类添加新代码。这也符合另一个重要的设计原则：开放/封闭原则（SOLID中的O）：代码应该是可以扩展的，但不能用于修改。即使您遵循所有良好的设计实践，您仍然需要重新启动应用程序才能进行更改

Answer 7

实际上，与编译和构建过程相关的参数对.NET平台并不重要。但它对某些其他平台或/和语言非常重要。

例如，在C ++世界中，这种好处可以通过开发团队提高生产力，因为它可以在编译期间节省小时。在C ++世界中，使用Bridge Pattern或Pimpl idiom可以节省大量时间，因为头文件中的每个更改（即使在私有部分中）都会导致重新编译所有依赖项（直接或间接）。在这种情况下，SOLID原则的构建或编译方面可能非常有用。

长话短说：SOLID原则不是关于构建过程或重新编译，而是关于依赖关系。但是当你正确地管理你的依赖关系时，你肯定会在这些方面获益（包括但限制构建和编译过程）。