业务对象上的静态工厂违反单一职责原则？答案

【问题标题】：Static factory on business object a violation of Single Responsibility Principle?业务对象上的静态工厂违反单一职责原则？
【发布时间】：2009-03-20 20:47:14
【问题描述】：

如果我将“数据访问”方法放在业务对象上，我是否违反了单一职责原则 (SRP)？我的直觉是，如果类本身存在 Load 方法，而不必猜测该方法恰好在哪个类中，那么 API 会感觉更加用户友好？

例子：

public class Image
{    
   public static Image FromFile(string filename)
   {
       return ImageLoader.LoadImage(filename)
   }

   public void SetPixel(int x, int y, Color color)
   {
   }
 }

【问题讨论】：

标签： oop single-responsibility-principle

【解决方案1】：

我认为这个本身没有任何问题，除了没有令人信服的理由让静态方法存在于 Image 类中（因为它不依赖于类中的任何内容，但在类本身上）。

如果你最终得到一堆加载方法，它们可能在不同的类中会更好

【讨论】：

【解决方案2】：

一般来说，我不认为知道如何通过单个路径（在本例中，从图像文件）创建自己的实例并确保有效状态必然会使 SRP 紧张。如果您有大量此类方法，那将是代码异味，然后您应该接受提示将它们分开。

【讨论】：

@John 您同意这是一种调用气味，当您开始为此添加一堆单独的方法时（即使它们在自己的类中），这种气味正是因为该类正在做几件事.
@Freddy：我的意思是，虽然可以合理地说从外部数据流中为自己补充水分可能不是你的责任，但这样的单个实例并不一定是坏事。跨度>

【解决方案3】：

我认为它是静态的这一事实使它不那么“令人震惊”地违反了 SRP，但我不是最大的 SOLID 纯粹主义者。这种启发式方法不应该过于虔诚...

【讨论】：

【解决方案4】：

在某种程度上，是的，但它并没有你想象的那么糟糕。任何原则都可以走极端，让人不舒服。

问题是，如果稍后您希望将它们分开，因为您希望该静态应用于其他图像，或者您想要实现可能适用于其他类型数据的更复杂的方法。

一般来说，重构 java 很容易，我建议您使用现在有意义的方法，只要记住在它可能会导致您撤消复杂性时重新访问它。

【讨论】：