4

类太大，难以处理。在Objective-C中，我很想使用类别来分解班级，但是：类别不只是将一个装满了太多垃圾的房子分成几个房间吗？我想，同样的问题也适用于 C# 中的部分类。

在什么情况下可以使用类别来解决“类太大”的代码异味？什么时候不正确，班级真的需要“重组或分解成更小的班级”？

4

4 回答 4

9

一个很好的参考原则是SOLID 原则。特别是“S”代表“单一责任”

单一责任原则

一个对象应该只有一个职责的概念。

当类变得太大时，它们很可能有太多的责任。你能在类的工作范围内定义两个或更多的职责吗？如果是这样，请将其分成两个或更多类。然后，您可以使用外观或复合模式将它们聚合回来。

换句话说：

  • 你在课堂上的代码应该根据单一责任原则分成不同的类
  • 原来的上帝类变成了一个组合或外观：它使用所有新类，向系统的其余部分公开相同的方法，但它本身不实现任何功能，除了“转换”旧式的上帝类调用新型 SOLID 调用。

这意味着从面向对象的角度来看，区域完全无法解决您的问题。事实上，它们实际上会适得其反，因为它们有助于隐藏问题。

另请参阅此 Jeff Atwood 文章：

http://www.codinghorror.com/blog/2008/07/the-problem-with-code-folding.html

编码恐怖区域

于 2011-11-05T09:26:38.677 回答
2

我必须承认我从未使用过 Objective-C，但当然，我使用过 C#。

也就是说，部分类与类是一样的，将一个类拆分为多个文件不会使类变小，只是在文件中拆分。该类的用法将是相同的。

所以我不同意部分类会解决这个问题，它们主要是为了其他东西而发明的，比如 Windows 窗体、wpf、自动生成的代码。它们在类不能被逻辑拆分但通常应该避免的其他情况下也很有用。

我认为你应该把你的班级分成几个班级，一个班级在 1k LOC（代码行）之后开始闻起来，如果班级被分成多个文件也是如此。

使用继承或将类拆分为由字段和属性连接的多个类。在由 chemicalNova 提供的示例中，我会将其拆分为多个类，而不是多个文件。

于 2011-11-05T08:07:11.923 回答
1

我记得当我还是个新手的时候，我们有这个神级“BusinessService”，或者类似的东西。每当有人将其锁定在 TFS 中时，您就会不走运。所以我有了这个绝妙的主意，我们为什么不把它分成部分类。我们最终得到了类似“BusinessService1.cs”..“BusinessService6.cs”的东西。这完全是一团糟，找到东西在哪里是一种完全的挫败感。

我认为每次你需要使用部分类，这是一个设计错误。如果 Microsoft 强迫您这样做（wpf、winforms 等） - 这是他们的设计错误。

于 2011-11-05T08:32:57.963 回答
-2

将类拆分为部分没有任何问题。很少有开发人员利用它。

就个人而言，我喜欢将较大的类拆分为部分，其中每个部分的业务方面都具有相似的功能 - 但前提是在设计时看起来所说的类会变得相当大。否则，我将相关功能拆分为区域。

例如，如果我要在数据层中有一个“UserService”，我可能会将其拆分为几个部分，如下所示：

UserServiceQueries.cs
UserServiceUpdates.cs
UserServiceInserts.cs
UserServiceLogicalFunctions.cs

..但是，它们包含“UserService”的部分类。我通常不经常使用 ORM，所以这对我来说是完美的，因为每个相关功能都可以变得非常大（显然这是一个基本示例）。

最后：利用所提供的东西。如果你从你的类中得到代码味道很大..你只有两个选择..重新编写它，或者拆分它（如果它肯定需要这么大）。

反正我的意见。

于 2011-11-05T08:02:23.050 回答