.net 在一个类中只有共享的函数/方法是一种好的做法吗？

对不起，标题太长了。下面是我在windows窗体应用程序中经常遇到的一个示例情况。我的应用程序中的大部分代码都以UI为中心，所以我的大部分代码都在主类（MainWindow）中。下面是我计划如何分解代码的一个类比。当用户执行操作时，我必须将压缩文件写入磁盘。所以看起来是这样的。这是一种好的做法吗。这只是为了更好地组织我的代码

Public class MainForm

    Private Sub TempButton_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles TempButton.Click
         Compression.CompressFile(fileStream)
    End Sub

End Class


Public Class Compression

     Private Sub New
          'Private constructor
     End Sub

     Public Shared Sub CompressFile(ByVal inFile as stream)

     End Sub

     Public Shared Sub DeCompressFile(ByVal inFile as stream)

     End Sub

End Class

---

这是一种常见的模式

---

但是，这样的函数应该放在

模块中（或者C#中的
静态类中）。
如果类的方法不需要类对象的实例，那么最好将这些方法共享

一个类中只有共享的函数/方法是一种好的做法吗

不是。通常开发人员称这些助手类为。从一开始看起来还可以，但很快这些助手类就会疯狂地增长，并包含很多责任。这些助手类本质上是静态的。这些是面向对象设计的SRP（单一责任原则）。我称之为神课。他们什么都知道：）

您应该更喜欢使用公共基类或抽象类。
这个问题可能更适合UMI的代码审查。如果它们与类相关，那么将它们分开可以获得什么？@RobbieDee:与哪个类相关？如果共享函数仅与类相关，那么根据定义，它们属于类，而不是单独的模块或静态类…@RobbieDee对我来说，这听起来像是一个实用函数，它并不真正属于任何类，因此将其放在自己的类中通常更为简洁。如果它们仅与类相关，则它们属于类。拥有通用的实用模块/类违背了面向对象的一般精神。听起来他/她所描述的是一个真正的单身汉，所以长话短说，一个充满共享函数的类是完全可以接受的。是的，我同意他/她……）事实上，这是非常普遍和完全可以接受的。我知道，这就是所谓的单身模式。我是一个考虑独生子女邪恶的人：问题是很多没有经验的程序员在单体风格中写这样的助手类，这对任何人都没有帮助……我自己认为助手类邪恶……