这是否违反了 SOLID 原则？答案

【问题标题】：is this violating the SOLID principles?这是否违反了 SOLID 原则？
【发布时间】：2010-11-29 01:37:43
【问题描述】：

我的项目中有类似的东西，该项目已经完成了（它正在工作）我只是想知道 SOLID 原则是否可行

static public class Tools
{
    static public GetProduct(this id){...}

    static public GetProductCategory(this id){...}

    static public GetUser(this id){...}

    // I also have here methods like IsStringNull ...
    // IsNull IsFalse, lots of stuff, everything static
}

而且用法是这样的

var UserThatCreatedCategoryForThisProduct = 
      prodId.GetProduct().CategoryId.GetProductCategory().Creator.GetUser();

我知道这很明显它违反了 SRP，但是这个类是静态的，它包含彼此独立的静态方法，如果我为每个方法创建一个静态类，那就有点不一样了

【问题讨论】：

这些是扩展方法？语法看起来有点不对劲。
@peterchen：使用示例表明这绝对是计划，很好（我读了它，甚至没有注意到 - 这是一个非常糟糕的主意！）
+1 提出一个好问题：是的……这违反了 SRP。

标签： c# oop solid-principles

【解决方案1】：

据我所知，这里有很多 SOLID 违规行为！

违反单一职责原则 - 首先，您拥有多个类的数据访问方法，其次您拥有与它们交织在一起的辅助方法（IsStringNull、IsNull 等）。
违反接口隔离原则（如 Ruben 所述） - 如果我只关心产品，为什么我需要接触获得用户的方法？

我敢肯定还有其他一些，但这些是明显的。

更新现在有人评论了，我认为他们是对的；上面的代码看起来像是某种形式的扩展方法滥用。

例如，我不认为数据访问应该归于扩展方法，或者更糟的是，一个名为“工具”的类。

拥有一个抽象数据访问通用性的基类（在完全不同的命名空间和/或程序集上）可能更有意义，然后为每个唯一的域对象（例如，UserDAO、ProductDAO）继承一个数据访问类，等等）。请理解我在这里的假设是 GetProduct 或 GetUser 实际上是指 GetFromDatabase。

其余的辅助方法确实属于扩展，所以它们很好。

【讨论】：

其实我有这个DAO类，它们在Tools类的方法中使用
好吧，SRP。你的 Tool 类做的太多了。如果您有 DAO 类，您可以将它们组合在一个 UserManager 或 ProductManager 类中，所有 CRUD 和其他功能都在其中。扩展方法应该在不破坏现有类的情况下添加功能，而不是从它们的真实位置隐藏现有功能。

【解决方案2】：

根据您的示例，至少有一个 ISP 和一个 SRP，并且可能违反了 Demeter 法则（不是 SOLID 而是...）。

IMNSHO 你最好阅读关于 SOLID 的文章（或购买 Agile Principles, Patterns, and Practices in C# by Robert C. Martin and Micah Martin，它自始至终都非常出色，是我近年来读过的最有用的书籍之一），而不是在互联网上寻求这种类型的零碎建议的东西。

如果您想要捷径（但您不想要 - 书籍和 PDF 中有很好地解释事情的示例！），这些 Hanselminutes 与 Bob 叔叔的播客非常好：

编辑：从 Jon Limjap 和 ppiotrowicz 获取 SRP

【讨论】：

有什么选择？肯定不会让UserThatCreatedCategoryForThisProduct 成为 ProductID 的属性/扩展方法？！
peterchen，这实际上是一个非常深奥的话题，需要大量的培训和/或练习才能获得。不幸的是，从软件开发中的功能/程序思维方式到真正面向对象的思维方式的跳跃是一个巨大的差距。
@Jon - 很公平。尽管如此，对我来说，访问模式似乎是由数据结构强加的，通常比处理代码更坚实（请原谅双关语）。

【解决方案3】：

它在很多方面都违反了 SOLID 原则。

它没有遵循单一责任原则，因为我没有做至少 3 件不同的事情（退货、退货、字符串操作？）
不开放扩展违反了开放封闭原则

【讨论】：