类别或部分类：解决“上帝对象”代码嗅觉的模式？

Question

一个类太大而且难以使用。在Objective-C中，我很想用类别来打破课堂，但那时候：类别只是将一个装满太多垃圾的房子分成房间吗？我想，同样的问题适用于C＃中的部分类。

在什么条件下可以使用类别来解决“类太大”的代码异味？什么时候不正确，班级确实需要"be restructured or broken into smaller classes?"

Answer 1

引用的一个非常好的原则是SOLID principle。特别是“S”代表“单一责任”

  

单一责任原则

     

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

当课程变得太大时，他们可能会承担太多责任。您能否在班级的工作范围内定义两项或更多责任？如果是这样，请将其分为两个或更多类。然后，您可以使用façade或composite模式将其聚合回来。

换句话说：

• 根据单一责任原则
，您在课堂上的代码应分成不同的类别
• 原始God类成为复合或façade：它使用所有新类，向系统的其余部分公开相同的方法，但不实现任何功能本身，除了在新式SOLID调用中“转换”旧式的神级调用。

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

另见Jeff Atwood的这篇文章：

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

Answer 2

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

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

所以我不同意部分类会解决这个问题，它们主要是针对其他东西发明的，比如windows窗体，wpf，自动生成的代码。 它们在其他无法逻辑分割类的情况下也很有用，但通常应该避免使用。

我认为你应该将你的班级划分为几个班级，一个班级在1k LOC（代码行）之后开始闻到，如果班级被拆分成多个档案。

使用继承或将类拆分为由字段和属性连接的多个类。 在化学新闻提供的例子中，我会将它分成几个类，而不是几个文件。

Answer 3

我记得当我是新手时，我们有这个神级“BusinessService”，或类似的东西。任何时候有人把它锁在TFS中，你就不幸了。所以我有这个好主意，为什么我们不将它分成不同的类。我们最终得到了像“BusinessService1.cs”......“BusinessService6.cs”这样的东西。这是一个完全混乱，完全无法找到事情的地方。

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

Answer 4

将一个类拆分为partials没有错。它是少数开发人员利用的东西。

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

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

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

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

结束时：利用所提供的东西。如果你的课堂上的代码气味很大......你只有2个选择..重新编写它，或者将它拆分（如果它肯定需要这么大）。

我的意见无论如何。