Сколько методов может иметь класс C#

16,7 миллиона на сборку для каждого метода (не класса).

Правильный ответ в текущей реализации 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). С достаточным количеством хранимых процедур вы можете достичь этого предела!

Я не знаю, сколько методов может иметь класс C#, но я знаю, что когда вы думаете об этом, вы наверняка делаете что-то не так.

Если и есть предел (в чем я сомневаюсь), то он настолько высок, что вы его не превысите. За исключением того, что у вас очень плохой дизайн класса.

См. антишаблон "Объект Бога".

ОБНОВЛЕНИЕ:

Несмотря на то, что я до сих пор точно не знаю, чего вы хотите достичь, я все же считаю, что вам определенно следует создавать много классов всего с несколькими методами по следующим причинам:

• Производительность: если вы помещаете все свойства в один класс, для каждого свойства должна быть выделена память при создании экземпляра, даже если вам нужно только 5% свойств в вашем классе.

• Модульность: если вы создаете много классов, вы можете сделать так, чтобы все они реализовывали интерфейсный/абстрактный класс и тем самым определяли аналогичную структуру, что поможет сделать ваше приложение более модульным.

• Структура: довольно просто увидеть, какие методы используют какие свойства, если только они находятся в одном и том же классе, иначе все может стать очень запутанным.

• Время компиляции: при изменении реализации одной функции другие не нужно перекомпилировать, как в других классах

Метод Type.GetMethods возвращает массив, который должен быть проиндексирован целым числом, поэтому я бы сказал, что у вас не может быть более int.MaxValue методов на класс.

Посмотрите на это: https://softwareengineering.stackexchange.com/questions/193295/implications-of-a-large-partial-class/193304?noredirect=1#193304

Кто-то на самом деле прошел через боль создания класса с максимально возможным количеством методов.

Больше, чем вы когда-либо захотите поместить в один класс.

Да...

Это называется здравый смысл. Старайтесь не перегружать класс, это, скорее всего, нарушит принцип единой ответственности, и его никто не сможет понять.

В конце концов, класс существует «только для того, чтобы помочь разработчику, который не может уместить в своей кратковременной памяти более 7 сведений одновременно» (да, я знаю, что это опасное утверждение).

Я так не думаю. Однако хорошие практики и рекомендации по разработке программного обеспечения, если им следовать и учитывать, должны естественным образом ограничивать количество свойств и методов, которые имеет класс, до того, что имеет смысл и является абсолютно необходимым. К таким практикам относятся SOLID, KISS (будьте проще), DRY (не повторяйтесь), композиция, рефакторинг, наследование и т. д.

У меня есть инструмент автоматической генерации кода, и в настоящее время я достиг предела между ~ 5 КБ (что сработало) и 10 КБ, что не удалось

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.

Таким образом, это противоречит утверждениям о том, что он «неограничен».