C#类可以拥有的属性数量是否有限制?
我在标准ECMA-334上快速浏览,但没有找到任何相关信息。
在进入为什么一个有很多方法的课程设计不好之前,我想更清楚一下这个意图。当然,我不会手动编写一个包含大量方法的类。我问这个的原因是我需要通过代码生成大量的执行单元。我讨论的是使用单个方法的多个类或使用多个方法的一个大类。
所以对于这个问题,如果有限制我会感兴趣,属性和方法数量的限制是什么。
答案 0 :(得分:27)
每种方法每集合1670万(非等级)。
答案 1 :(得分:16)
我不知道C#类可以有多少方法,但我知道当你考虑它时,你肯定做错了。
如果有一个限制(我怀疑)它是如此之高,你不会超过它。除了你的课程设计非常糟糕。
查看反模式"God object"。
<强>更新强>:
尽管我仍然不知道你想要达到什么目标,但我仍然认为你应该用很少的方法创建很多类,原因如下:
性能:如果要将所有属性放入一个类中,则在创建实例时必须分配每个属性内存,即使您只需要5%的属性你的班级
模块化:如果你创建了很多类,你可以让它们都实现一个接口/抽象类,从而定义一个类似的结构,这将有助于使你的应用程序更加模块化
结构:当只有它们位于同一个类中时,看哪些方法使用哪些属性非常简单 - 否则事情可能会变得非常混乱
编译时间:更改一个函数的实现时,不需要重新编译其他函数,因为它们在其他类中
答案 2 :(得分:16)
当前CLR实施中的正确答案是 ushort.MaxValue - 15 。这可以按如下方式进行测试:
AppDomain appDomain = AppDomain.CurrentDomain;
AssemblyName aname = new AssemblyName ("MyDynamicAssembly");
AssemblyBuilder assemBuilder =
appDomain.DefineDynamicAssembly (aname, AssemblyBuilderAccess.Run);
ModuleBuilder modBuilder = assemBuilder.DefineDynamicModule ("DynModule");
TypeBuilder tb = modBuilder.DefineType ("Widget", TypeAttributes.Public);
for (int i = 0; i < ushort.MaxValue - 15; i++)
{
MethodBuilder methBuilder = tb.DefineMethod ("SayHello" + i, MethodAttributes.Public, null, null);
ILGenerator gen = methBuilder.GetILGenerator();
gen.EmitWriteLine ("Hello world");
gen.Emit (OpCodes.Ret);
}
Type t = tb.CreateType();
object o = Activator.CreateInstance (t);
如果您使用Reflection.Emit创建一个类型化的DataContext来支持数据库(如LINQPad那样),则问题是相关的。有了足够的存储过程,您就可以达到此限制!
答案 3 :(得分:4)
Type.GetMethods
方法返回一个必须用整数索引的数组,所以我会说每个类不能超过 int.MaxValue
方法。
答案 4 :(得分:2)
实际上有人经历了尽可能多的方法生成课程的痛苦
答案 5 :(得分:1)
超过你想要的一个课程。
答案 6 :(得分:0)
...是
它被称为常识。尽量不要使一个班级超载,它很可能违反单一责任原则,没有人能够理解它。
毕竟,一堂课“只是为了帮助开发人员,他们不能同时将7个以上的信息融入他的短期记忆中”(是的,我知道这是一个危险的陈述)
答案 7 :(得分:0)
我不这么认为。但是,遵循和考虑的良好的软件开发实践和指南自然应该限制一个类具有有意义和绝对必要性的属性和方法的数量。这些做法包括SOLID,KISS(保持简单),DRY(不要重复自己),构图,重构,继承等。
答案 8 :(得分:0)
我有一个自动代码生成工具,我目前达到~5K(有效)和10K之间的限制,但失败了
System.TypeLoadException: Type '<the type name>' from assembly '<the assembly name>, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' contains more methods than the current implementation allows.
因此,这与“无限制”的说法相矛盾。