Когда целесообразно использовать частичные классы C #?

Ответы:

423

Самое частое использование частичных классов - облегчить жизнь генераторам / дизайнерам кода. Частичные классы позволяют генератору просто испускать код, который им нужен, и им не нужно иметь дело с пользовательскими изменениями в файле. Пользователи также могут свободно аннотировать класс новыми членами, имея второй частичный класс. Это обеспечивает очень чистую основу для разделения проблем.

Лучший способ взглянуть на это - увидеть, как дизайнеры работали до частичных классов. Дизайнер WinForms выплевывал весь код внутри региона с жестко сформулированными комментариями о том, как не изменять код. Пришлось вставить всевозможные эвристики, чтобы найти сгенерированный код для последующей обработки. Теперь он может просто открыть файл designer.cs и иметь высокую степень уверенности, что он содержит только код, относящийся к конструктору.

JaredPar
источник
70
Соблазн дать вам -1 за то, что вы снимали мне кошмары о том, как плохо было перед частичными занятиями :)
Джон Б.
9
@ Джон :), я думаю, у всех нас были те кошмары.
JaredPar
18
Однажды я написал генератор кода, который выдает более 36 тыс. Строк (или, возможно, гораздо больше, я точно не помню), и мои редакторы были заблокированы при открытии источника. Частичные классы позволили мне увидеть полученный код, не имея 4 ГБ ОЗУ.
Лука
6
Я бы сказал, что это единственное использование для частичных классов в производственном коде. Хотя я принимаю это может быть полезно для рефакторинга.
Гордон Макаллистер
5
@ Гордон - ответ HumerGu - другой, против которого, на мой взгляд, трудно поспорить. Частичные классы могут быть очень удобны для реализации интерфейсов в C # и для того, чтобы члены интерфейса были четко отделены от членов класса: stackoverflow.com/questions/3601901/why-use-partial-classes/…
STW
262

Другое использование состоит в том, чтобы разделить реализацию различных интерфейсов, например:

partial class MyClass : IF1, IF2, IF3
{
    // main implementation of MyClass
}


partial class MyClass
{
    // implementation of IF1
}

partial class MyClass
{
    // implementation of IF2
}
relascope
источник
6
Хорошая точка зрения! Это то, что я делал раньше и о котором забыл, но, безусловно, это хороший способ сделать члены интерфейса четко видимыми (особенно в C #, поскольку VB.NET использует Implementsключевое слово для обозначения метода, принадлежащего интерфейсу)
STW
2
очень хороший момент, каждый интерфейс может быть реализован разработчиком, также это хороший способ легко найти реализацию интерфейса.
Kokabi
3
как узнать, какой из них для IF1 или IF2 .. по порядку объявления классов?
kuldeep
17
Хорошее использование, но плохой пример. Почему бы вам определить все интерфейсы в одном частичном классе и реализовать те же интерфейсы в других частичных классах? ..
inkredibl
4
Ха, я просто посмотрел этот вопрос, чтобы увидеть, было ли разделение реализаций интерфейса стандартным использованием для частичных классов. Рад видеть, что другие считают это хорошей идеей. Я согласен с @inkredibl относительно того, чтобы поместить определение интерфейса вместе с частичным классом, который его реализует.
Ким
172

Помимо других ответов ...

Я нашел их полезными в качестве трамплина в рефакторинге богов. Если у класса есть несколько обязанностей (особенно если это очень большой файл кода), то я считаю целесообразным добавить 1x частичный класс для каждой ответственности в качестве первого прохода для организации, а затем рефакторинга кода.

Это очень помогает, потому что может помочь сделать код намного более читабельным, фактически не влияя на поведение при выполнении. Это также может помочь определить, когда ответственность легко реорганизовать или тесно связана с другими аспектами.

Однако - чтобы быть ясным - это все еще плохой код, в конце разработки вы все еще хотите одну ответственность за класс ( НЕ за частичный класс). Это просто трамплин :)

STW
источник
23
Очень приятно: «... в конце разработки вы все еще хотите одну ответственность за класс ( НЕ за частичный класс) ...»
kokabi
Для меня это не очень хороший стиль кодирования, но он может сделать плохие коды лучше.
themefield
Я полностью согласен с этим. Это хороший шаг к исправлению плохого кода. Класс бога - это погода класса бога, он распространяется по нескольким файлам или нет.
Джимбо
84
  1. Несколько разработчиков с использованием частичных классов Несколько разработчиков могут легко работать с одним и тем же классом.
  2. Генератор кода Частичные классы в основном используются генератором кода для разделения различных задач.
  3. Частичные методы Используя частичные классы, вы также можете определить частичные методы, где разработчик может просто определить метод, а другой разработчик может реализовать его.
  4. Только частичное объявление метода Даже код компилируется только с объявлением метода, и, если реализация метода отсутствует, компилятор может безопасно удалить этот кусок кода, и не возникнет ошибка времени компиляции.

    Чтобы проверить пункт 4. Просто создайте проект winform и добавьте эту строку после конструктора Form1 и попробуйте скомпилировать код

    partial void Ontest(string s);

Вот некоторые моменты, которые следует учитывать при реализации частичных классов:

  1. Используйте частичное ключевое слово в каждой части частичного класса.
  2. Имя каждой части частичного класса должно быть одинаковым, но имя исходного файла для каждой части частичного класса может быть другим.
  3. Все части частичного класса должны находиться в одном пространстве имен.
  4. Каждая часть частичного класса должна находиться в одной сборке или DLL, другими словами, вы не можете создать частичный класс в исходных файлах из другого проекта библиотеки классов.
  5. Каждая часть частичного класса должна иметь одинаковую доступность. (то есть: частный, публичный или защищенный)
  6. Если вы наследуете класс или интерфейс в частичном классе, то он наследуется всеми частями этого частичного класса.
  7. Если часть частичного класса запечатана, тогда весь класс будет запечатан.
  8. Если часть частичного класса является абстрактной, тогда весь класс будет считаться абстрактным классом.
hellowahab
источник
1
Есть ли проблемы с редактированием частичного класса, созданного из Entity Framework? Я хочу изменить имена некоторых классов, созданных из таблицы.
MarceloBarbosa
У меня такие же проблемы. Я хочу знать о преимуществах «если таковые имеются», которые имеет частичный класс при построении моделей, которые Entity Framework будет по существу использовать для построения моей базы данных с точки зрения / подхода / реализации Code First ... что у вас есть.
Chef_Code
@JimBalter Пожалуйста, пройдите по этой ссылке msdn.microsoft.com/en-us/library/6b0scde8(v=vs.110).aspx . Это говорит о том, что если нет реализации, компилятор удалит фрагмент кода, и не будет получена ошибка времени компиляции.
hellowahab
Если вы наследуете класс или интерфейс в частичном классе, то он наследуется всеми частями этого частичного класса.
Красный горох
56

Одним из важных применений является отделение сгенерированного кода от рукописного кода, принадлежащего одному и тому же классу.

Например, поскольку LINQ to SQL использует частичные классы, вы можете написать собственную реализацию определенных частей функциональности (например, отношений «многие ко многим»), и эти части пользовательского кода не будут перезаписаны при повторной генерации кода.

То же самое касается кода WinForms. Весь сгенерированный дизайнером код помещается в один файл, который вы обычно не трогаете. Ваш рукописный код помещается в другой файл. Таким образом, когда вы что-то меняете в Designer, ваши изменения не срываются.

Джастин Нисснер
источник
21

Это правда, что Partial Class используется для автоматической генерации кода, одним из которых может быть поддержание большого файла класса, который может иметь тысячи строк кода. Вы никогда не знаете, что ваш класс может закончиться 10 тысячами строк, и вы не хотите создавать новый класс с другим именем.

public partial class Product
{
    // 50 business logic embedded in methods and properties..
}

public partial class Product
{
    // another 50 business logic embedded in methods and properties..
}
//finally compile with product.class file.

Другое возможное использование может заключаться в том, что более одного разработчика могут работать в одном классе, поскольку они хранятся в разных местах. Люди могут смеяться, но вы никогда не знаете, что иногда это может быть горсткой.

Product1.cs

public partial class Product
{
    //you are writing the business logic for fast moving product
}

Product2.cs

public partial class Product
{
    // Another developer writing some business logic...
}

Надеюсь, это имеет смысл!

Каусар Ахмед
источник
13

Частичные классы охватывают несколько файлов.

Как вы можете использовать частичный модификатор в объявлении класса C #?

Частичные классы позволяют физически разделить класс на несколько файлов. Это часто делается генераторами кода.

пример

С обычными классами C # вы не можете объявить класс в двух отдельных файлах в одном проекте. Но с partialмодификатором вы можете.

Это полезно, если один файл обычно редактируется, а другой генерируется машиной или редко редактируется.

Вот пример, чтобы уточнить:

class Program
{
    static void Main()
    {
        A.A1();
        A.A2();
    }
}

Содержимое файла A1.cs: C #

using System;

partial class A
{
    public static void A1()
    {
        Console.WriteLine("A1");
    }
}

Содержимое файла A2.cs: C #

using System;

partial class A
{
    public static void A2()
    {
        Console.WriteLine("A2");
    }
}

Вывод:

A1
A2

Частичное требуется здесь.

Если вы удалите partialмодификатор, вы получите ошибку, содержащую этот текст:

[Пространство имен ' <global namespace>' уже содержит определение для ' A'].

Подсказка:

Чтобы это исправить, вы можете использовать partialключевое слово или изменить одно из имен классов.

Как компилятор C # работает с частичными классами?

Если вы разберете вышеуказанную программу (используя IL Disassembler), вы увидите, что файлы A1.cs и A2.cs исключены. Вы обнаружите, что класс А присутствует.

Класс A будет содержать методы A1 и A2 в одном и том же блоке кода. Два класса были объединены в один.

Скомпилированный результат A1.cs и A2.cs: C #

internal class A
{
    // Methods
    public static void A1()
    {
        Console.WriteLine("A1");
    }

    public static void A2()
    {
        Console.WriteLine("A2");
    }
}

Резюме

  • Частичные классы могут упростить определенные ситуации программирования на C #.
  • Они часто используются в Visual Studio при создании программ Windows Forms / WPF.
  • Сгенерированный машиной код C # является отдельным.
  • Или вы можете найти полное описание здесь .
Вивек Саурав
источник
2
Хороший пример и хорошо задокументированы.
Chef_Code
1
Это самое простое объяснение для подражания.
Юша
12

Сохраняйте все как можно более чистыми при работе с огромными классами или при работе в команде, вы можете редактировать без переопределения (или всегда вносить изменения)


источник
11

Основное использование для частичных классов - сгенерированный код. Если вы посмотрите на сеть WPF (Windows Presentation Foundation), вы определите свой пользовательский интерфейс с помощью разметки (XML). Эта разметка компилируется в частичные классы. Вы заполняете код частичными собственными классами.

Клетус
источник
8

Если у вас достаточно большой класс, который не поддается эффективному рефакторингу, разделение его на несколько файлов помогает сохранить порядок.

Например, если у вас есть база данных для сайта, содержащего дискуссионный форум и систему продуктов, и вы не хотите создавать два разных класса провайдеров (НЕ то же самое, что прокси-класс, просто для ясности), вы можете создать один частичный класс в разных файлах, например

MyProvider.cs - основная логика

MyProvider.Forum.cs - методы, относящиеся конкретно к форуму

MyProvider.Product.cs - методы для продуктов

Это просто еще один способ держать вещи в порядке.

Кроме того, как уже говорили другие, это единственный способ добавить методы в сгенерированный класс, не рискуя уничтожить ваши добавления при следующей регенерации класса. Это очень удобно для кода, сгенерированного шаблоном (T4), ORM и т. Д.

3Dave
источник
2
Я бы отстаивал частичное в качестве ступеньки к рефакторингу (суть моего ответа), но не предлагал бы их как реальное решение для написания чистого кода. Если частичный класс четко отделен от других забот класса, то почему бы не приложить дополнительные небольшие усилия, чтобы превратить его в отдельный класс?
STW
@STW: может случиться так, что много экземпляров объекта создаются и используются для различных задач. Разделение различных задач на разные классы потребовало бы отслеживания, какие экземпляры были использованы для каких задач - потенциально гораздо более сложное занятие, чем просто перемещение блоков кода между исходными модулями.
суперкат
4
@supercat - я полностью понимаю, но очистка такого рода спагетти должна быть предпринята. У меня есть много шрамов от очистки именно такого типа кода, и я никогда не рекомендую оставить его позади. Эти типы беспорядков гарантированно будут постоянно создавать проблемы, и долгосрочные выгоды огромны по сравнению с просто игнорированием проблемы. Такой код не «пахнет», а пахнет как мусорная свалка.
STW
1
@supercat - я попытался уточнить это следующим образом: «Если частичное чисто отделено от других проблем ... тогда это небольшое усилие». Пройдя через боль распутывания, вы, как правило, значительно сэкономите на долгосрочном обслуживании, если не Rogaine
STW
2
Кстати, сейчас я пытаюсь изменить Roslyn, и он написан с использованием частичных классов. Много-много основных классов в Roslyn определены как частичные классы в нескольких файлах. И Roslyn был написан людьми, которых я, по крайней мере, считаю очень умными программистами C #.
RenniePet
8

Как альтернатива директивам прекомпилятора.

Если вы используете директивы прекомпилятора (а именно #IF DEBUG ), то в итоге вы получите какой-то мрачно выглядящий код, смешанный с вашим реальным кодом Release.

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

STW
источник
Monogame использует эту стратегию.
Замбони
6

Ссылки на сервисы являются еще одним примером, где частичные классы полезны для отделения сгенерированного кода от кода, созданного пользователем.

Вы можете «расширить» классы обслуживания, не перезаписывая их при обновлении ссылки на службу.

Франческо де Виттори
источник
6

Другое использование, которое я видел,

Расширение большого абстрактного класса относительно логики доступа к данным,

у меня есть различные файлы с именами Post.cs, Comment.cs, Pages.cs ...

in Post.cs 

public partial class XMLDAO :BigAbstractClass
{
// CRUD methods of post..
}


in Comment.cs 

public partial class XMLDAO :BigAbstractClass
{
// CRUD methods of comment..
}

in Pages.cs 

public partial class XMLDAO :BigAbstractClass
{
// CRUD methods of Pages..
}
Сринивас Редди Татиарти
источник
6

Большинство людей отмечают, что их partialследует использовать только для класса, в котором есть файл сгенерированного кода, или для интерфейсов. Я не согласен, и вот почему.

Для одного примера, давайте посмотрим на класс C # System.Math ... это класс . Я бы не пытался втиснуть все 70+ методов в один и тот же файл кода. Это было бы кошмаром для поддержания.

Размещение каждого математического метода в отдельных файлах частичного класса и всех файлов кода в папке Math в проекте будет значительно более чистой организацией.

То же самое может / будет справедливо для многих других классов, которые имеют большое количество разнообразных функциональных возможностей. Например, класс для управления API PrivateProfile может быть полезен, если его разделить на чистый набор частичных файлов классов в одной папке проекта.

Лично я также разделил то, что большинство людей называют «вспомогательными» или «служебными» классами, на отдельные частичные файлы для каждого метода или функциональной группы методов. Например, в одном проекте класс вспомогательных строк имеет почти 50 методов. Это был бы длинный громоздкий файл кода, даже с использованием регионов. Значительно проще поддерживать использование отдельных файлов классов для каждого метода.

Я просто буду осторожен, используя частичные классы, и при этом сохраню согласованность всей структуры файла кода на протяжении всего проекта. Например, помещая любые общедоступные перечисления класса и закрытые члены класса в файл Common.cs или файл с аналогичным именем в папке, вместо того, чтобы распространять их по файлам, если они не относятся только к частичному файлу, в котором они содержатся.

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

deegee
источник
4

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

Частичный открытый класс zzFileConverterRegistrar
    Регистр событий (ByVal mainConverter as zzFileConverter)
    ПодрегистрAll (ByVal mainConverter as zzFileConverter)
        Регистрация RaiseEvent (mainConverter)
    End Sub
Конечный класс

Каждый модуль, который хочет зарегистрировать один или несколько типов файловых конвертеров, может включать что-то вроде:

Частичный открытый класс zzFileConverterRegistrar
    Private Sub RegisterGif (ByVal mainConverter as zzFileConverter) Обрабатывает Me.Register
        mainConverter.RegisterConverter ("GIF", GifConverter.NewFactory))
    End Sub
Конечный класс

Обратите внимание, что основной класс конвертера файлов не «выставлен» - он просто представляет небольшой класс-заглушку, к которому могут подключаться модули расширения. Существует небольшой риск возникновения конфликтов имен, но если подпрограмма «register» каждого модуля расширения именуется в соответствии с типом файла, с которым он имеет дело, они, вероятно, не должны создавать проблем. Можно указать GUID в имени подпрограммы регистрации, если вы беспокоитесь о таких вещах.

Редактировать / Добавление Чтобы было ясно, цель этого состоит в том, чтобы предоставить средство, с помощью которого различные отдельные классы могут сообщить основной программе или классу о них. Единственное, что будет делать основной конвертер файлов с zzFileConverterRegistrar, - это создать один его экземпляр и вызвать метод registerAll, который вызовет событие Register. Любой модуль, который хочет перехватить это событие, может выполнить произвольный код в ответ на него (вот и вся идея), но модуль ничего не может сделать, неправильно расширив класс zzFileConverterRegistrar, кроме определения метода, имя которого совпадает с именем другого объекта. , Конечно, было бы возможно, чтобы одно неправильно написанное расширение сломало другое неправильно написанное расширение, но решение для этого для тех, кто не хочет, чтобы его расширение было сломано, просто написать его правильно.

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

  RegisterConverter ("GIF", GifConvertor.NewFactory)
  RegisterConverter ("BMP", BmpConvertor.NewFactory)
  RegisterConverter ("JPEG", JpegConvertor.NewFactory)

но добавление другого модуля преобразователя потребует перехода в эту часть кода преобразователя и добавления нового преобразователя в список. Используя частичные методы, в этом больше нет необходимости - все конвертеры будут включены автоматически.

Supercat
источник
это работает, но простая система плагинов для динамической загрузки этих модулей будет намного приятнее и поможет устранить риск повреждения модулей друг другом (это может привести к загрузке модулей во время выполнения, а не к перекомпиляции)
STW
Риск того, что модули повредят друг друга, может быть сведен к минимуму, если они ничего не делают с классом zz_, кроме перехвата события Register и вызова процедуры для регистрации самих себя. Какие риски вы видите, что не существует с плагином? Плагины хороши, если ожидается, что конечный пользователь «подключит» новые модули. Однако иногда хочется поместить все функциональные возможности в один exe. Возможность подключения исходных файлов без необходимости вручную добавлять ссылку на вновь добавленные файлы может быть полезной.
суперкат
1
риск довольно хорошо отражен в вашей строке "... если они ничего не делают [...], кроме ...", безопасность и стабильность полностью зависят от разработчика в соответствии с соглашением и обеспечивают 0% гарантию. Если ваш сценарий использования состоит в том, чтобы их скомпилировать (совершенно допустимо, это просто компромисс с совестью), то почему бы просто не определить модули в отдельных классах и реализовать некоторый IModuleинтерфейс?
STW
Это звучит как случай, когда «умный» испортился. Это не «модули», это один класс с множеством поведений и обязанностей, объединенных во время компиляции. Есть много лучших способов сделать это - вы можете использовать Reflection для сканирования скомпилированной сборки на предмет классов, которые реализуют IModule, вы можете использовать плагин-фреймворк, такой как MEF (только один из многих) и т. Д. И т. Д.
STW
3

Частичные классы недавно помогли с контролем исходного кода, когда несколько разработчиков добавляли в один файл, где новые методы были добавлены в одну и ту же часть файла (автоматизировано Resharper).

Эти толчки вызвали конфликты слияний. Я не нашел способа заставить инструмент слияния принять новые методы как полный блок кода.

Частичные классы в этом отношении позволяют разработчикам придерживаться версии своего файла, и мы можем объединить их позже вручную.

пример -

  • MainClass.cs - содержит поля, конструктор и т. Д.
  • MainClass1.cs - разработчик нового кода, как они реализуют
  • MainClass2.cs - еще один класс разработчиков для своего нового кода.
сойка
источник
3

Из MSDN :

1. Во время компиляции атрибуты определений частичного типа объединяются. Например, рассмотрим следующие объявления:

[SerializableAttribute]
partial class Moon { }

[ObsoleteAttribute]
partial class Moon { }

Они эквивалентны следующим декларациям:

[SerializableAttribute]
[ObsoleteAttribute]
class Moon { }

Следующее объединено со всеми определениями частичного типа:

  • XML комментарии

  • интерфейсы

  • атрибуты параметров универсального типа

  • атрибуты класса

  • члены

2. Еще одна вещь, вложенные частичные классы могут быть также частичными:

partial class ClassWithNestedClass
{
    partial class NestedClass { }
}

partial class ClassWithNestedClass
{
    partial class NestedClass { }
}
Eli
источник
1

Вот список некоторых преимуществ частичных классов.

Вы можете разделить код разработки пользовательского интерфейса и код бизнес-логики, чтобы его было легко читать и понимать. Например, вы разрабатываете веб-приложение с использованием Visual Studio и добавляете новую веб-форму, тогда есть два исходных файла: «aspx.cs» и «aspx.designer.cs». Эти два файла имеют один и тот же класс с частичным ключевым словом. Класс «.aspx.cs» имеет код бизнес-логики, а «aspx.designer.cs» - определение элемента управления пользовательского интерфейса.

При работе с автоматически сгенерированным исходным кодом код можно добавить в класс, не создавая заново исходный файл. Например, вы работаете с LINQ to SQL и создаете файл DBML. Теперь, когда вы перетаскиваете таблицу, она создает частичный класс в designer.cs, и все столбцы таблицы имеют свойства в этом классе. Вам нужно больше столбцов в этой таблице для привязки к сетке пользовательского интерфейса, но вы не хотите добавлять новый столбец в таблицу базы данных, поэтому вы можете создать отдельный исходный файл для этого класса, который имеет новое свойство для этого столбца, и он будет быть частичным классом. Так что это влияет на отображение между таблицей базы данных и сущностью DBML, но вы можете легко получить дополнительное поле. Это означает, что вы можете написать код самостоятельно, не вмешиваясь в сгенерированный системой код.

Несколько разработчиков могут одновременно написать код для класса.

Вы можете лучше поддерживать свое приложение, сжимая большие классы. Предположим, у вас есть класс с несколькими интерфейсами, поэтому вы можете создавать несколько исходных файлов в зависимости от реализации интерфейса. Легко понять и поддерживать реализованный интерфейс, в котором исходный файл имеет частичный класс.

Шаши
источник
1

Всякий раз, когда у меня есть класс, который содержит вложенный класс любого существенного размера / сложности, я отмечаю класс как partialи помещаю вложенный класс в отдельный файл. Я называю файл, содержащий вложенный класс, используя правило: [имя класса]. [Имя вложенного класса] .cs.

В следующем блоге MSDN объясняется использование частичных классов с вложенными классами для удобства обслуживания: http://blogs.msdn.com/b/marcelolr/archive/2009/04/13/using-partial-classes-with-nested-classes-for- maintainability.aspx

Ɖiamond ǤeezeƦ
источник
1

Я знаю, что этот вопрос действительно старый, но я просто хотел бы добавить свой взгляд на частичные занятия.

Одна из причин, по которой я лично использую частичные классы, - это когда я создаю привязки для программы, особенно конечных автоматов.

Например, OpenGL - это конечный автомат, есть куча методов, которые можно изменить глобально, однако, по моему опыту, связывая нечто похожее с OpenGL, где есть так много методов, класс может легко превысить 10 000 LOC.

Частичные уроки сломают это для меня и помогут мне быстро найти методы.


источник
0

Частичные классы в основном вводятся для помощи генераторам кода, поэтому мы (пользователи) не теряем всю нашу работу / изменения в сгенерированных классах, таких как класс .designer.cs в ASP.NET, каждый раз, когда мы обновляем, почти все новые инструменты, которые генерируют код LINQ, EntityFrameworks, ASP.NET используют частичные классы для сгенерированного кода, поэтому мы можем безопасно добавлять или изменять логику этих сгенерированных кодов, используя преимущества частичных классов и методов, но будьте очень осторожны, прежде чем добавлять материал в сгенерированный код с использованием частичных классов легче, если мы нарушаем сборку, но хуже, если мы вводим ошибки во время выполнения. Для более подробной информации проверьте это http://www.4guysfromrolla.com/articles/071509-1.aspx

Киран Бхемарти
источник
0

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

Группировка предметов класса

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

public class MyClass{  
  //Member variables
  //Constructors
  //Properties
  //Methods
}

С частичными классами мы можем пойти дальше и разделить разделы на отдельные файлы. Как правило, команда может добавлять суффикс к каждому файлу с соответствующим ему разделом. Таким образом, в приведенном выше примере мы имеем что-то вроде: MyClassMembers.cs, MyClassConstructors.cs, MyClassProperties.cs, MyClassMethods.cs.

Как уже упоминалось в других ответах, стоит ли разделять класс, вероятно, зависит от того, насколько велик класс в этом случае. Если оно маленькое, то, вероятно, проще иметь все в одном мастер-классе. Но если какой-либо из этих разделов становится слишком большим, его содержимое можно переместить в отдельный частичный класс, чтобы сохранить мастер-класс в чистоте. Соглашение в этом случае может заключаться в том, чтобы оставить комментарий, сказав что-то вроде «Смотрите частичный класс» после заголовка раздела, например:

//Methods - See partial class

Управление областью использования операторов / пространства имен

Вероятно, это редкое явление, но может возникнуть конфликт пространства имен между двумя функциями из библиотек, которые вы хотите использовать. В одном классе вы можете максимально использовать предложение using для одного из них. Для другого вам понадобится полное имя или псевдоним. С частичными классами, поскольку каждое пространство имен и список использования операторов различны, можно разделить два набора функций на два отдельных файла.

Колм Бхандал
источник
Существуют механизмы разрешения конфликтов пространства имен, например, переименование пространства имен с помощью using Library1 = The.Namespace.You.Needилиglobal::Root.Of.Namespace
fjch1997
Да, я полагаю, это слабый вариант использования. Но немного приятнее не иметь полной квалификации имен. Больше приятного непреднамеренного побочного эффекта, чем причины использования частичных классов.
Колм Бхандал