Nic*_*aux 7 c# oop coding-style class-design visual-studio
我正在处理的项目刚刚在主C#文件中命中了4200行,这导致IntelliSense需要几秒钟(有时最多6个左右)才能响应,在此期间Visual Studio会锁定.我想知道其他人如何分割他们的文件以及是否达成了共识.
我试图寻找一些指南,并找到了谷歌的C++指南,但我看不出有关语义的任何信息,如函数大小和文件大小; 也许它就在那里 - 我有一段时间没有看过它.
那你怎么拆分你的文件？您是按照所服务的功能对方法进行分组吗？按类型(事件处理程序,私人/公共)？你在什么尺寸限制下分割功能？
为了澄清,有问题的应用程序处理数据 - 所以它的界面是一个大网格,一切都围绕网格.它有一些用于管理的对话框表单,但它都是关于数据的.它之所以如此之大,是因为存在大量错误检查,事件处理以及网格设置为主细节,每行有三个网格(但主扩展上的这些加载).我希望这有助于澄清我的目标.
Tim*_*Tim 19
我认为您的问题总结为您使用的术语:"主C#文件".
除非你的意思是main(如方法main()),否则没有这个概念的地方.
如果你有一个catch-all实用程序类或其他常用方法,你应该将它们分解为类似的功能部分.
通常我的文件只是一对一的类映射.
有时,非常相关的类在同一个文件中.
如果您的文件太大,则表明您的课程太大而且太笼统.
我尝试将我的方法保持在半个屏幕或更少.(当我从头开始编写代码时,它通常是12行或更少,但最近我一直在使用其他开发人员的现有代码,并且不得不重构100行函数......)
有时它是一个屏幕,但它变得非常大.
编辑:
为了解决关于函数的大小限制问题 - 对我而言,它不是关于大小(尽管这是一个很好的问题指示器),而是关于只做一件事并保持每一个简单.
Jon*_*eet 14
将你的类型拆分成自然分裂的类型 - 但要注意那些做得太多的类型.在大约500行(Java或C#)我很担心.在大约1000行,我开始认真考虑是否应该拆分类型...但有时它不能/不应该.
至于方法:当我无法一次在屏幕上看到整个方法时,我不喜欢它.显然这取决于显示器的大小等,但这是一个合理的经验法则.我更喜欢它们更短.同样,也有例外 - 某些逻辑很难解开,特别是如果有很多本地变量并不自然地想要封装在一起.
有时单个类型有很多方法是有意义的- 例如System.Linq.Enumerable,如果您可以将类型分解为逻辑组(在Enumerable聚合/集合操作/过滤分组的情况下),则部分类可以在这种情况下提供帮助等似乎很自然).这种情况在我的经历中很少见.
Martin Fowler的书Refactoring I think为您提供了一个很好的起点.它指示如何识别"代码味道"以及如何重构代码以修复这些"气味".自然结果(虽然它不是主要目标)是你最终得到更小的可维护类.
编辑
根据您的编辑,我一直坚持认为后端代码的良好编码实践在表示层中是相同的.UI重构要考虑的一些非常有用的模式是命令,策略,规范和状态.
简而言之,您的视图应该只包含代码来处理事件和分配值.所有逻辑都应该分成另一个类.一旦你这样做,你会发现在你可以重构的地方变得更加明显.网格使得这一点变得更加困难,因为它们使得在表示逻辑和视图之间分离您的表示状态变得太容易,但是通过一些工作,您可以放置间接以最小化由此引起的痛苦.