Is there a limitation on number of properties, methods a C# class can have?
C#类可以拥有的属性数量是否有限制?
I do a quick skim at Standard ECMA-334 and did not find any information on it.
我快速浏览标准ECMA-334并没有找到任何相关信息。
Before jumping into why a class with many methods are bad design, I want to be more clear on the intention. Of course I will not be writing a class with large number of methods manually. The reason I am asking this is I need to generate a large number of execution units by code. I am debate between have multiple classes with single method or one large class with multiple methods.
在进入为什么一个有很多方法的课程设计不好之前,我想更明确一下这个意图。当然,我不会手动编写一个包含大量方法的类。我问这个的原因是我需要通过代码生成大量的执行单元。我讨论的是具有单个方法的多个类或具有多个方法的一个大类。
So for this question, I am only interest if is there a limit and what is the limit for number of properties, methods.
所以对于这个问题,我只是有兴趣,如果有一个限制,属性数量,方法的限制是什么。
9 个解决方案
#1
27
16.7 million per assembly per method (not class).
每种方法每组装1670万(不是等级)。
#2
16
I don't know how many methods a C# class can have, but I do know that when you're thinking about it you are most certainly doing something wrong.
我不知道C#类可以有多少方法,但我知道当你考虑它时,你肯定做错了什么。
If there is a limit(which I doubt) it's so high that you won't exceed it. Except you have a really bad class design.
如果有一个限制(我怀疑)它是如此之高,你不会超过它。除了你有一个非常糟糕的课程设计。
See the anti-pattern "God object".
看到反模式“上帝的对象”。
UPDATE:
Even though I still don't exactly know what you want to achieve, I still believe that you should definitely create a lot of classes with only a few methods for the following reasons:
虽然我仍然不知道你想要实现什么,但我仍然认为你应该用很少的方法创建很多类,原因如下:
-
Performance: if you are putting all properties into one class, for every property memory has to be allocated when you create an instance, even if you only need 5% of the properties in your class
性能:如果要将所有属性放入一个类中,则在创建实例时必须为每个属性分配内存,即使您只需要类中5%的属性
-
Modularity: if you create a lot of classes you can make them all implement an interface/abstract class and thereby define a similar structure, which will help making your application more modular
模块化:如果你创建了很多类,你可以让它们都实现一个接口/抽象类,从而定义一个类似的结构,这将有助于使你的应用程序更加模块化
-
Structure: it's pretty straightforward to see which methods use which properties when only they reside in the same class - otherwise things might get really really messy
结构:当只有它们位于同一个类中时,看看哪些方法使用哪些属性非常简单 - 否则事情可能会变得非常混乱
-
Compiling time: when changing the implementation of one function, the others don't have to be re-compiled, as they are in other classes
编译时间:在更改一个函数的实现时,其他函数不必重新编译,因为它们在其他类中
#3
15
The correct answer, in the current CLR implementation, is ushort.MaxValue - 15. This can be tested as follows:
在当前的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);
The question is relevant if you're using Reflection.Emit to create a typed DataContext to back a database (as LINQPad does). With enough stored procedures, you can hit this limit!
如果您使用Reflection.Emit创建一个类型化的DataContext来支持数据库(如LINQPad那样),则问题是相关的。有了足够的存储过程,您就可以达到此限制!
#4
4
The Type.GetMethods
method returns an array that must be indexed by an integer so, I would say you can't have more than int.MaxValue
methods per class.
Type.GetMethods方法返回一个必须用整数索引的数组,所以我想说每个类不能超过int.MaxValue方法。
#5
2
看看这个:https://softwareengineering.stackexchange.com/questions/193295/implications-of-a-large-partial-class/193304?noredirect=1#193304
Someone actually went through the pain of generating a class with as many methods as possible
实际上有人经历了尽可能多的方法生成一个类的痛苦
#6
1
More than you will ever want to put in a single class.
比你想要的更多。
#7
0
Yes...
Its called common sense. Try not to overload a class, it will most likely violate the single responsibility principle, and noone will be able to understand it.
它叫做常识。尽量不要超载一个类,它很可能违反单一责任原则,没有人能够理解它。
After all, a class is there "only to aid the developer, who cant fit more then 7 informations at once into his short term memory" (Yes, i know thats a dangerous statement)
毕竟,一堂课“只是为了帮助开发人员,他们不能同时将7个以上的信息融入他的短期记忆中”(是的,我知道这是一个危险的陈述)
#8
0
I don't think so. However, good software development practices and guidelines when followed and considered should naturally limit the number of properties and methods that a class has to what makes sense and absolute necessity. Such practices include SOLID, KISS (keep it simple), DRY (Don't repeat yourself), composition, refactoring, inheritance, etc.
我不这么认为。但是,遵循和考虑的良好软件开发实践和指南自然应该限制一个类具有意义和绝对必要性的属性和方法的数量。这些做法包括SOLID,KISS(保持简单),DRY(不要重复自己),组合,重构,继承等。
#9
0
I have an automated code generation tool and I currently hit the limit between ~5K (which worked) and 10K, which failed
我有一个自动代码生成工具,我目前达到~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.
So this contradicts claims that it is "unlimited".
所以这与它是“无限的”的说法相矛盾。
#1
27
16.7 million per assembly per method (not class).
每种方法每组装1670万(不是等级)。
#2
16
I don't know how many methods a C# class can have, but I do know that when you're thinking about it you are most certainly doing something wrong.
我不知道C#类可以有多少方法,但我知道当你考虑它时,你肯定做错了什么。
If there is a limit(which I doubt) it's so high that you won't exceed it. Except you have a really bad class design.
如果有一个限制(我怀疑)它是如此之高,你不会超过它。除了你有一个非常糟糕的课程设计。
See the anti-pattern "God object".
看到反模式“上帝的对象”。
UPDATE:
Even though I still don't exactly know what you want to achieve, I still believe that you should definitely create a lot of classes with only a few methods for the following reasons:
虽然我仍然不知道你想要实现什么,但我仍然认为你应该用很少的方法创建很多类,原因如下:
-
Performance: if you are putting all properties into one class, for every property memory has to be allocated when you create an instance, even if you only need 5% of the properties in your class
性能:如果要将所有属性放入一个类中,则在创建实例时必须为每个属性分配内存,即使您只需要类中5%的属性
-
Modularity: if you create a lot of classes you can make them all implement an interface/abstract class and thereby define a similar structure, which will help making your application more modular
模块化:如果你创建了很多类,你可以让它们都实现一个接口/抽象类,从而定义一个类似的结构,这将有助于使你的应用程序更加模块化
-
Structure: it's pretty straightforward to see which methods use which properties when only they reside in the same class - otherwise things might get really really messy
结构:当只有它们位于同一个类中时,看看哪些方法使用哪些属性非常简单 - 否则事情可能会变得非常混乱
-
Compiling time: when changing the implementation of one function, the others don't have to be re-compiled, as they are in other classes
编译时间:在更改一个函数的实现时,其他函数不必重新编译,因为它们在其他类中
#3
15
The correct answer, in the current CLR implementation, is ushort.MaxValue - 15. This can be tested as follows:
在当前的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);
The question is relevant if you're using Reflection.Emit to create a typed DataContext to back a database (as LINQPad does). With enough stored procedures, you can hit this limit!
如果您使用Reflection.Emit创建一个类型化的DataContext来支持数据库(如LINQPad那样),则问题是相关的。有了足够的存储过程,您就可以达到此限制!
#4
4
The Type.GetMethods
method returns an array that must be indexed by an integer so, I would say you can't have more than int.MaxValue
methods per class.
Type.GetMethods方法返回一个必须用整数索引的数组,所以我想说每个类不能超过int.MaxValue方法。
#5
2
看看这个:https://softwareengineering.stackexchange.com/questions/193295/implications-of-a-large-partial-class/193304?noredirect=1#193304
Someone actually went through the pain of generating a class with as many methods as possible
实际上有人经历了尽可能多的方法生成一个类的痛苦
#6
1
More than you will ever want to put in a single class.
比你想要的更多。
#7
0
Yes...
Its called common sense. Try not to overload a class, it will most likely violate the single responsibility principle, and noone will be able to understand it.
它叫做常识。尽量不要超载一个类,它很可能违反单一责任原则,没有人能够理解它。
After all, a class is there "only to aid the developer, who cant fit more then 7 informations at once into his short term memory" (Yes, i know thats a dangerous statement)
毕竟,一堂课“只是为了帮助开发人员,他们不能同时将7个以上的信息融入他的短期记忆中”(是的,我知道这是一个危险的陈述)
#8
0
I don't think so. However, good software development practices and guidelines when followed and considered should naturally limit the number of properties and methods that a class has to what makes sense and absolute necessity. Such practices include SOLID, KISS (keep it simple), DRY (Don't repeat yourself), composition, refactoring, inheritance, etc.
我不这么认为。但是,遵循和考虑的良好软件开发实践和指南自然应该限制一个类具有意义和绝对必要性的属性和方法的数量。这些做法包括SOLID,KISS(保持简单),DRY(不要重复自己),组合,重构,继承等。
#9
0
I have an automated code generation tool and I currently hit the limit between ~5K (which worked) and 10K, which failed
我有一个自动代码生成工具,我目前达到~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.
So this contradicts claims that it is "unlimited".
所以这与它是“无限的”的说法相矛盾。