在C#中，我应该考虑在类之前重构多少行？一个好的经验法则是，我会智能地重构超过50行的任何方法。该计数不包括注释和空格，但包括实际代码。我之所以聪明，是因为有很多时候超过50行的类是可以接受的，不能也不应该更改。我对上课没有经验法则。一般来说，我不会检查一个类是否应该重构。在我目前的项目中，我刚刚完成了将近4000行的课程。但是，方法不超过50个，而且大部分行和方法都是私有的，不作用于类外的任何数据。重构类的经验法则是什么？当一个类违反了SRP时，就该重构了。如果你的类违反了以下“规则”之一，你应该考虑重构。您正在寻找SOLID，可以在此处找到更详细的截屏视频。不要让LOC成为您的主要指标。50行对我来说真的很小。对于一个50行的文件，您最终会在解决方案中得到不合适数量的类文件。您在文件之间进行的所有导航都会降低您的工作效率，您的IDE将总是充斥着太多的选项卡。我个人首先尝试按名称空间将类组织成逻辑组。在逐个类的基础上，我尝试使代码更小且更易于阅读。有时，类文件会变大。当class文件2000+行的时候，我就开始觉得恶心了。除此之外，我将根据具体情况进行处理。我不会说重构大类有任何“经验法则”。有时候，一个类确实封装了很多业务逻辑，应该越大越好。但是，您可能会考虑问自己一些问题：（假设您正在编写面向对象的代码）我的代码真的是面向对象的吗？也就是说，它是否遵循单一职责原则（感谢Nebakanezer）？这个类是辅助类吗？如果是这样，我如何将其方法重构为更合适的对象类？我有一个可靠的模式吗？也就是说，我是在使用抽象和继承，而不是在每个类级别重新发明轮子吗？重载方法是否适当地调用基方法？我真的需要所有这些代码吗？是否可以使用xpath、lambda表达式或某种形式的数据库驱动表达式来外部化某些逻辑？代码是否可扩展？是否易于维护？它是从一开始就设计得很好，还是我们总是制作小补丁来尝试修复问题？我希望这个能有一点帮助;重构大类可能很困难，但我认为如果您开始查看我的问题，您可能很快就会发现您的代码还有改进的空间……我知道我通常会这样做。特别要看#1——人们到处创建大量的辅助类是很常见的，这是非常反OO的（在我看来）。那是一个不同的主题，但您可能想看看在您完成的课程中真正调用的是什么-以及其他地方可以/应该是什么。根据经验，如果类是可维护且灵活的，则可能不需要更改。？在C#中，我对类的经验法则是超过500行太长。我真的很喜欢10行以下的内容，我想20行以下是可以接受的。我认为这取决于具体情况。每当你有机会重构时：等等。编辑：显然，重构的决定应该考虑时间、潜在回报、其他责任等。重构并没有减少LOC的数量，虽然这是一个副作用，但改进质量。特别是，您想尽可能地遵循DRY（不要重复自己）原则。我倾向于查看每个成员的圈复杂度，而不是整个类的代码行。我的经验法则是方法，而不是类——如果我无法在屏幕上看到整个方法，我需要重构。当然，传统的香味也适用。此类是否可以作为“提取您认为不存在的对象”重构练习的候选对象？例如，也许您可??以提取一个方法对象，允许您将50行方法中的几个重构为提取类的成员？或者，将一些包含业务逻辑的私有方法封装在一个与之协作的新对象中，可能会提供一种重用该对象或提取的对象的新方法。一行就足以考虑重构。50行的40个方法每个都开始在我耳边尖叫“我太复杂了，这里隐藏着另一个对象”。以上是C#学习教程：在C#中，课前应该考虑多少行重构？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
