在 C# 中，应该考虑重构类之前的多少行？

In C# how many lines before a class should be consider to be refactored?

提问by David Basarab

A good rule of thumb by is that I intelligently refactor any method over 50 lines.

一个好的经验法则是，我智能地重构任何超过 50 行的方法。

The count does not include comments and white space but actual code. The reason I also say intelligently is there are plenty of times where a class over 50 lines is acceptable and cannot or should not be changed.

计数不包括注释和空格，但包括实际代码。我也聪明地说的原因是很多时候超过 50 行的类是可以接受的，不能或不应该改变。

I do not have a rule of thumb for classes. Generally I don't check classes to see if they should be refactored.

我对课程没有经验法则。通常我不会检查类以查看它们是否应该重构。

On my currently project I have just about complete a class that is almost 4000 lines long. However no methods over 50, and most of the lines and methods are private and not acting on any data outside of the class.

在我目前的项目中，我刚刚完成了将近 4000 行长的课程。但是，没有超过 50 的方法，并且大多数行和方法都是私有的，不会作用于类之外的任何数据。

What is the rule of thumb for refactoring classes?

重构类的经验法则是什么？

采纳答案by Mark Sherretta

When the class violates the SRP, it's time to refactor.

当类违反SRP 时，就该重构了。

The single responsibility principle is a computer programming principle that states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility

单一责任原则是一种计算机编程原则，它规定每个模块或类都应对软件提供的功能的单个部分负责，并且该责任应完全由类封装。它的所有服务都应该严格地与​​该职责保持一致

回答by BobbyShaftoe

Refactoring is not so much about reducing the number of LOC, though that is a side effect, but improving the quality. Particularly, you want to try to follow the DRY (Don't Repeat Yourself) principle as much as you can, reasonably.

重构与其说是减少 LOC 的数量，但这是一种副作用，但可以提高质量。特别是，您希望尽可能合理地遵循 DRY（不要重复自己）原则。

回答by Ed Altorfer

I wouldn't say that there's any "rule of thumb" for refactoring large classes. Sometimes a class really encapsulates a lot of business logic and should be as large as it is. However, you might consider asking yourself a few questions:

我不会说重构大型类有任何“经验法则”。有时一个类确实封装了很多业务逻辑，应该尽可能大。但是，您可以考虑问自己几个问题：

1. (Assuming you're writing object oriented code) Is my code truly object-oriented? That is, does it follow the Single Responsibility Principle (thanks, Nebakanezer)? Is this class a helper class? If so, how could I refactor its methods into more appropriate object classes?

2. Do I have a solid architecture? That is, am I making use of abstraction and inheritance rather than re-inventing the wheel in every class? Are overloaded methods calling base methods as appropriate?

3. Do I really need all this code? Could some of the logic be externalized using xpath, lambda expressions, or some form of database driven expressions?

4. Is the code extensible? Is it easy to maintain? Was it well-architected from the beginning, or are we always making small patches to try to fix problems?

1. （假设您正在编写面向对象的代码）我的代码真的是面向对象的吗？也就是说，它是否遵循单一职责原则（感谢 Nebakanezer）？这个类是辅助类吗？如果是这样，我如何将其方法重构为更合适的对象类？

2. 我有可靠的架构吗？也就是说，我是否在使用抽象和继承而不是在每个类中重新发明轮子？重载方法是否适当地调用基方法？

3. 我真的需要所有这些代码吗？是否可以使用 xpath、lambda 表达式或某种形式的数据库驱动表达式将某些逻辑外部化？

4. 代码是否可扩展？容易维护吗？它是从一开始就设计得很好，还是我们总是制作小补丁来尝试解决问题？

I hope that this helps a little; it can be difficult to refactor large classes, but I think if you start looking through my questions, you may find pretty quickly that there is room for improvement in your code...I know I typically do.

我希望这会有所帮助；重构大型类可能很困难，但我认为如果您开始查看我的问题，您可能很快就会发现您的代码还有改进的空间……我知道我通常会这样做。

Especially look at #1--it's really common for people to create a ton of helper classes all over the place, which is very anti-object oriented (in my opinion). That's a different topic, but you may want to see what really -belongs- in the class you've made and what could/should be somewhere else.

尤其是看看#1——人们在各处创建大量的助手类真的很常见，这是非常反面向对象的（在我看来）。那是一个不同的主题，但您可能想看看什么真正属于您所创建的类，什么可以/应该在其他地方。

As a rule of thumb, if the class is maintainable and flexible, it may not need to be changed. :)

根据经验，如果类是可维护且灵活的，则可能不需要更改。:)

回答by David Hodgson

In C#, my rule of thumb for classes is anything over 500 lines is getting too long. I really like methods under 10 lines, and I guess under 20 is acceptable. I think it really depends on the context.

在 C# 中，我对类的经验法则是超过 500 行的任何东西都变得太长了。我真的很喜欢 10 行以下的方法，我想 20 行以下是可以接受的。我认为这真的取决于上下文。

回答by Gary.Ray

My rule of thumb is for methods, more than classes - If I can't see the whole method on screen it needs to be refactored. Of course, the traditional smellsapply.

我的经验法则是方法，而不是类 - 如果我在屏幕上看不到整个方法，则需要重构。当然，传统的气味也适用。

回答by Garrett

Refactor whenever you have the opportunity to:

只要有机会就重构：

• introduce the appropriate design patterns in lieu of spaghetti code
• reduce code complexity and increase readability
• remove redundant code by introducing a single method call
• extricate UI from business logic

• 引入适当的设计模式来代替意大利面条式代码
• 降低代码复杂度并提高可读性
• 通过引入单个方法调用来删除冗余代码
• 从业务逻辑中提取 UI

etc, etc.

等等等等。

EDIT: Obviously, the decision to refactor should take into account time, potential pay-off, other responsibilities, etc.

编辑：显然，重构的决定应该考虑时间、潜在的回报、其他责任等。

回答by Steve

Don't let LOC be your primary metric. 50 lines seems really small to me. With 50 line files, you will end up having an unfriendly number of class files in the solution. Your productivity will be dampened by all the navigation you will be doing between files and your IDE will always be littered with too many tabs. I personally try to organize classes into logical groups by namespace first. On a class by class basis, I try to make the code smaller and easier to read. Sometimes, class files do get large. I start to get a sick feeling when the class file is 2000+ lines. Anything less than that, I deal with on a case by case basis.

不要让 LOC 成为您的主要指标。50 行对我来说似乎很小。对于 50 行文件，您最终将在解决方案中拥有不友好数量的类文件。您将在文件之间进行的所有导航都会降低您的工作效率，并且您的 IDE 将始终充斥着过多的选项卡。我个人尝试首先按命名空间将类组织成逻辑组。在逐个班级的基础上，我尝试使代码更小且更易于阅读。有时，类文件确实会变大。当类文件超过 2000 行时，我开始感到恶心。比这少的任何事情，我都会根据具体情况处理。

回答by James

I tend to look at the cyclomatic complexity of each member instead of number of lines of code for the entire class.

我倾向于查看每个成员的圈复杂度，而不是整个类的代码行数。

回答by Tetsujin no Oni

This class could be a candidate for the refactoring exercise of "extract an object that you don't think is there"?

这个类可能是“提取一个你认为不存在的对象”的重构练习的候选人吗？

Perhaps, for example, you could extract a method object that would allow you to refactor several of the 50 line methods into members of an extracted class?

例如，也许您可​​以提取一个方法对象，允许您将 50 行方法中的几个重构为提取类的成员？

Alternatively, encapsulating some of those private methods that contain business logic in a new object that collaborates with this one might provide a new way to reuse either this object, or the extracted one.

或者，将一些包含业务逻辑的私有方法封装在与此对象协作的新对象中，可能会提供一种新方法来重用此对象或提取的对象。

One line is enough to consider refactoring. 40 each 50 line methods is starting to scream "I'm too complicated, there's another object hiding in here" to my ear.

一行就足以考虑重构。40 每 50 行方法开始在我耳边尖叫“我太复杂了，这里藏着另一个对象”。

回答by ruslander

If your classes have broken one of following "rules", you should consider to refactor.

如果您的课程违反了以下“规则”之一，您应该考虑重构。

You are looking for SOLID, more detailed screencasts can be found here.

您正在寻找SOLID，可以在此处找到更详细的截屏视频。

• SRP: single responsibility principle, there should never be more than one reason for a class to change.

• OCP: open closed principle, software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.

• LSP: liskov substitution principle, functions that use references to base classes must be able to use objects of derived classes without knowing it.

• ISP: interface segregation principle, clients should not be forced to depend upon interfaces that they do not use.

• DIP: dependency inversion principle:

  • high level modules should not depend upon low level modules. Both Should depend upon abstractions.

  • abstractions should not depend upon details. Details should depend upon abstractions.

• SRP：单一职责原则，一个类改变的原因永远不应该超过一个。

• OCP：开放封闭原则，软件实体（类、模块、函数等）应该对扩展开放，对修改封闭。

• LSP：liskov 替换原则，使用基类引用的函数必须能够在不知情的情况下使用派生类的对象。

• ISP：接口隔离原则，不应该强迫客户端依赖他们不使用的接口。

• DIP：依赖倒置原理：

  • 高级模块不应该依赖于低级模块。两者都应该依赖于抽象。

  • 抽象不应该依赖于细节。细节应该取决于抽象。