17

例如，关于Single Responsibility原则：

让我们谈谈一个Radio类：

在此处输入图像描述

有人可能会争辩说，该Radio课程有两个职责，即音量和电台管理。这些操作将从使用它的客户端的完全不同区域调用。

因此我们有这个：

在此处输入图像描述

一切都好。

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

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

等一下 ！

如果我需要更改VolumeManager 类 - 我将不必重新编译Radio和StationManager. 但是我必须停止（在网络中）iis 以便应用程序使用新的 DLL，这将导致应用程序关闭。

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

即使我将使用 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”

4

7 回答 7

11

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

SOLID 是关于干净的代码和可维护性的。它与运行时无关，它与代码随着时间的推移变得越来越复杂且难以维护有关，这就是真正的成本所在。

于 2012-12-23T08:28:49.630 回答
7

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

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

于 2012-12-23T08:46:49.563 回答
3

与 C++ 相比，编译时间在 C# 中不是问题。一个大型 C++ 项目可能需要很长时间才能编译。当试图在一个区域进行更改导致重新编译不相关的组件时，这变得非常令人沮丧。单一职责引导更紧凑的依赖关系以这种方式改进编译问题。

于 2012-12-23T09:02:36.577 回答
3

我强烈推荐鲍勃叔叔关于 SOLID 原则的干净编码器视频。

独立部署背后的主要思想是，可以独立部署的模块也可以独立开发。通常您不会独立部署模块，但您确实受益于能够独立开发它们。

与对编译过程的影响有关，这可能与 C++ 相关，其中每个编译单元（cpp 文件）在代码依赖于更改时都需要重新编译，以及精心构建的依赖关系图，其中更改仅影响一个编译单元，会严重影响编译时间。无论如何，除非您使用的是较旧的硬件，否则您可能不应该优先考虑编译时间。

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

于 2012-12-23T09:56:22.360 回答
2

我不认为保存的编译是重要的，而是为什么没有它你可以逃脱。

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

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

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

于 2012-12-23T08:28:13.393 回答
1

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

于 2012-12-23T08:40:53.183 回答
0

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

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

长话短说：SOLID 原则与构建过程或重新编译无关，而是与依赖关系有关。但是，当您正确管理依赖项时，您肯定也会在这些领域受益（包括但限制构建和编译过程）。

于 2012-12-23T15:51:14.380 回答