只有一个（公共）方法的类是否有问题？

我目前正在从事一个软件项目，该项目对视频监控镜头进行压缩和索引编制。压缩的工作方式是分割背景和前景对象，然后将背景另存为静态图像，并将前景另存为子画面。

最近，我开始复习我为该项目设计的一些课程。

我注意到有许多类只有一个公共方法。其中一些类是：

• VideoCompressor（使用一种compress方法，该方法接收类型的输入视频RawVideo并返回类型的输出视频CompressedVideo）。
• VideoSplitter（使用一种split方法，该方法接收类型的输入视频RawVideo并返回2个输出视频的向量，每个类型均为RawVideo）。
• VideoIndexer（使用index接收类型为type的输入视频RawVideo并返回类型为video的视频索引的方法VideoIndex）。

我发现自己实例每个班只是为了让像电话VideoCompressor.compress(...)，VideoSplitter.split(...)，VideoIndexer.index(...)。

从表面上看，我确实认为类名足以说明其预期功能，实际上它们是名词。相应地，它们的方法也是动词。

这真的有问题吗？

不，这不是问题，相反。这是班级模块化和明确责任的标志。从该类用户的角度来看，精益接口很容易掌握，并且会鼓励松耦合。这具有许多优点，但几乎没有缺点。我希望以这种方式设计更多组件！

它不再是面向对象的。由于这些类不代表任何内容，因此它们只是功能的容器。

这并不意味着它是错误的。如果功能足够复杂或具有通用性（即，参数是接口，而不是具体的最终类型），则可以将该功能放在单独的模块中。

从那里开始，取决于您的语言。如果该语言具有自由功能，则应将其作为模块导出功能。为什么不假装它是一堂课。如果该语言没有像Java这样的自由函数，则可以使用单个public方法创建类。好吧，这仅显示了面向对象设计的局限性。有时功能只是更好的匹配。

在一种情况下，您可能需要一个具有单个公共方法的类，因为它必须实现具有单个公共方法的接口。无论是用于观察者模式，依赖注入还是其他。在这里，它再次取决于语言。在具有一流函子（C ++（std::function或模板参数），C＃（委托），Python，Perl，Ruby（proc），Lisp，Haskell等）的语言中，这些模式使用函数类型，不需要类。Java没有（但是，在版本8中会）具有函数类型，因此您使用单方法接口和相应的单方法类。

当然，我不主张编写单个巨大的功能。它应该具有私有子例程，但是它们可以对实现文件（在C ++中为文件级静态或匿名名称空间）或仅在公共函数内部实例化的私有帮助器类（是否要存储数据？）私有。

可能有理由将给定方法提取到专用类中。这些原因之一是允许进行依赖注入。

假设您有一个名为的类VideoExporter，它最终应该能够压缩视频。一个干净的方法是拥有一个接口：

interface IVideoCompressor
{
    Stream compress(Video video);
}

可以这样实现：

class MpegVideoCompressor : IVideoCompressor
{
    // ...
}

class FlashVideoCompressor : IVideoCompressor
{
    // ...
}

并像这样使用：

class VideoExporter
{
    // ...
    void export(Destination destination, IVideoCompressor compressor)
    {
        // ...
        destination = compressor(this.source);
        // ...
    }
    // ...
}

一个糟糕的选择是拥有一个VideoExporter拥有大量公共方法并且可以完成所有工作的工作，包括压缩。这将很快成为维护方面的噩梦，很难添加对其他视频格式的支持。

这表明您要将函数作为参数传递给其他函数。我猜您的语言（Java？）不支持它；如果是这样，这并不是设计上的失败，而是您选择的语言的缺点。这是语言坚持要求所有事物都必须是一类的最大问题之一。

如果您实际上并没有传递这些伪函数，那么您只需要一个自由/静态函数。

我知道我参加晚会很晚，但是每个人似乎都错过了这一点：

这是一个众所周知的设计模式，称为：策略模式。

当有几种可能的策略可以解决子问题时，将使用策略模式。通常，您定义一个在所有实现上强制执行合同的接口，然后使用某种形式的依赖注入为您提供具体的策略。

例如，在这种情况下，您可以拥有interface VideoCompressor和然后有几个替代实现，例如class H264Compressor implements VideoCompressor和class XVidCompressor implements VideoCompressor。从OP尚不清楚其中是否包含接口，即使没有接口，也可能只是原作者在需要时打开了实施策略模式的大门。哪一个本身就是好的设计。

OP经常发现自己实例化类来调用方法的问题是她没有正确使用依赖项注入和策略模式的问题。与其在需要的地方实例化它，不如说包含类应该包含一个带有strategy对象的成员。并且该成员应该被注入，例如在构造函数中。

在许多情况下，策略模式仅使用一种doStuff(...)方法即可生成接口类（如您所示）。

public interface IVideoProcessor
{
   void Split();

   void Compress();

   void Index();
}

您所拥有的是模块化的，这很好，但是如果您将这些职责归为IVideoProcessor，那么从DDD的角度来看可能更有意义。

另一方面，如果拆分，压缩和索引没有任何关系，那么我将它们保留为单独的组件。

这是一个问题-您是在设计的功能方面，而不是数据上工作。您实际拥有的是3个独立的功能，这些功能已经过OO标准化。

例如，您有一个VideoCompressor类。为什么要使用旨在压缩视频的类-为什么没有在其视频类上压缩该类型每个对象包含的（视频）数据的Video类？

设计OO系统时，最好创建代表对象的类，而不是代表可以应用的活动的类。在过去，类被称为类型-OO是一种扩展语言并支持新数据类型的方法。如果您这样想OO，那么您将获得一种更好的类设计方法。

编辑：

让我尝试更好地解释一下自己，想象一下具有concat方法的字符串类。您可以实现这样的事情，其中​​从类实例化的每个对象都包含字符串数据，因此您可以说

string mystring("Hello"); 
mystring.concat("World");

但是OP希望它像这样工作：

string mystring();
string result = mystring.concat("Hello", "World");

现在在某些地方可以使用类来保存相关功能的集合，但这不是OO，这是一种使用语言的OO功能来帮助更好地管理代码库的便捷方法，但绝不是任何一种OO设计”。在这种情况下，对象是完全人为的，像这样简单地使用，因为该语言无法提供更好的方法来解决此类问题。例如。在诸如C＃之类的语言中，您将使用静态类来提供此功能-它重用了类机制，但是您不再需要实例化一个对象来仅调用其上的方法。最终您会string.IsNullOrEmpty(mystring)得到一些我认为比差的方法mystring.isNullOrEmpty()。

因此，如果有人问“我如何设计类”，我建议考虑类将包含的数据，而不是类所包含的功能。如果您追求“一个类是一堆方法”，那么最终您将编写“更好的C”样式代码。（如果要改进C代码，这不一定是一件坏事），但它不会为您提供最佳的OO设计程序。

该ISP（接口分离原则）说，没有客户端应该被迫依赖于它不使用方法。好处是多方面的，而且很明显。您的方法完全尊重ISP，这很好。

同样尊重ISP的另一种方法是，例如，为每个方法（或具有高内聚性的方法集）创建一个接口，然后让一个类来实现所有这些接口。这是否是更好的解决方案取决于方案。这样做的好处是，当使用依赖项注入时，您可以使一个客户端具有不同的协作者（每个接口一个），但最终所有协作者都将指向同一对象实例。

对了你说

我发现自己实例化了每堂课

，这些类似乎是服务（因此是无状态的）。您是否考虑过让它们单身？

是的，有问题。但并不严重。我的意思是，您可以像这样构造代码，并且不会发生任何不良情况，它是可维护的。但是这种结构存在一些弱点。例如，考虑如果视频的表示形式（如果您将其分组在RawVideo类中），则需要更新所有操作类。或者考虑一下，您可能会在运行时中看到多种视频表示形式。然后，您将必须将表示形式与特定的“操作”类进行匹配。同样从主观上讲，为要进行的每个操作拖拽一个依赖项也是很烦人的。并在每次您决定不再需要该操作或需要新操作时更新传递的依赖关系列表。

这实际上也违反了SRP。有些人只是将SRP视为划分职责的指南（并通过将每个操作视为不同的职责而走到了很远），但他们忘记了SRP也是划分职责的指南。根据SRP的职责，出于相同原因而进行的更改应归为一组，以便在发生更改时将其本地化为尽可能少的类/模块。对于大类，只要在同一个类中具有多个算法就没有问题，只要这些算法是相关的（即，共享一些在该类之外不应该知道的知识）。问题是大类的算法完全没有关联，并且由于不同的原因而改变/变化。