Частичные классы C#, плохо разрабатывают? [закрытый]

Еще одно хорошее применение частичных классов - реализация абстрактного фабричного шаблона . Сделайте корневой объект фабрики частичным, а затем поместите фактические фабричные методы в тот же файл, что и класс, инстанцируемый фабрикой.

РЕДАКТИРОВАТЬ: Частичные классы также хорошо работают для классов, которые взаимодействуют с файлом конфигурации. Поместите код, содержащий параметры конфигурации, рядом с кодом, который фактически использует параметр конфигурации.

Не могли бы вы объяснить мне, когда будет законная причина когда-либо использовать частичный класс?

Недавние версии Visual Studio используют частичные классы, чтобы отделить автоматически сгенерированный код конструктора от вашего собственного кода.

Пример ASP.NET:

• Page.aspx
• Page.aspx.cs <- Ваш код
• Page.aspx.Designer.cs <- Частичный класс, содержащий автоматически сгенерированный код.

Пример WinForms:

• Form1.resx
• Form1.cs <- Ваш код
• Form1.Designer.cs <- Частичный класс, содержащий автоматически сгенерированный код

Я дважды использовал частичный класс в VB.Net, и оба раза в тех редких случаях, когда мне требовалось позднее связывание. Просто создайте частичный класс и выключите Option Strict Off вверху.

Еще одно законное использование частичных классов - помочь уменьшить «монолитную сеть». служебный "беспорядок в WCF. Вы хотите разбить его на логические группы функциональных возможностей, но не хотите создавать множество отдельных экземпляров службы / конечных точек (предположительно, потому что они совместно используют состояние, ресурсы и т. Д.).

Решение? Пусть служба реализует несколько интерфейсов и реализует каждый интерфейс в своем собственном частичном классе. Затем сопоставьте разные конечные точки в конфигурации с одной и той же физической реализацией.Это делает проект более удобным в обслуживании, но у вас по-прежнему есть только одна физическая конечная точка.

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

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

1. Для разделения автоматически сгенерированных частей кода (например, кода конструктора WinForms или вывода T4).
2. Разрешить вложенным типам их собственный файл, в то же время обеспечивая инкапсуляцию, требуемую вашим проектом.

Обновление
Я вижу, что некоторые не уверены в моем втором пункте, поэтому позвольте мне привести пример; ListViewItemCollection в структуре. Он вполне справедливо вложен в ListView , потому что он предназначен только для использования ListView , но чтобы упростить обслуживание, я бы дал ему собственный файл, используя частичные классы. Я не считаю это плохим дизайном или неправильным использованием ключевого слова partial .

Для более подробного обсуждения ознакомьтесь с вопросом, который дублирует этот: Частичные классы в C #

Я использовал частичные классы для «физического» отделения статических методов доступа к данным от свойств и методов бизнес-класса в активной архитектуре записи. Например, у нас параллельно были частичные классы Company и CompanyData. Преимущество состояло в том, что один файл был POCO, а другой содержал только методы доступа к данным. Это было ступенькой к прекращению доступа к данным в классах репозитория в устаревшем приложении. Я думаю, что это было законное использование, оно определенно сделало процесс рефакторинга более разумным.

Я полностью согласен с ответом Джона . Но я бы пошел еще дальше.

• Не делайте свои классы частичными.

Единственное использование частичных классов, которое я считаю «хорошим дизайном», - это автоматически сгенерированный код. Любое другое использование почти наверняка приведет к ненужному разделению вашего класса. (На самом деле, я вижу, что второй пункт Джеффа о вложенных классах, возможно, является допустимым)

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

Частичный класс существует в платформе .Net исключительно для того, чтобы дизайнеры Visual Studio (например, дизайнер Asp.Net и дизайнер Windows Forms) могли генерировать код / ​​беспорядок с вашими классами, сохраняя этот сгенерированный код в отдельный файл.

(См. Частичные классы .NET против наследования )

Если вы сделаете что-то подобное (сгенерируете код, который должен сосуществовать с кодом, написанным пользователем), то вы также можете найти частичные классы полезными, но Я не верю, что Microsoft когда-либо предполагала, что частичные классы как языковая концепция будут полезны кому-либо, кроме команды Visual Studio.

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

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

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

Я определенно не поощряю вышеупомянутое как выбор дизайна, но это была хорошая быстрая победа для нас, и показывает, что частичные классы не являются злом все время...

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

Существует много дискуссий на эту тему, и многие люди говорят, что 1) использование частичных классов - это плохой дизайн, 2) что они используются для автогенерируемого кода и 3) что они не должны занимать место наследования.

Однако у меня есть ситуация, в которой частичные классы кажутся очень полезными: Я создаю серию приложений, которые в конечном итоге будут объединены в пакет. Все они будут иметь главную форму, которая будет обеспечивать некоторую функциональность, и несколько общих компонентов (например, форму для отображения отчетов). Хотя я мог бы определить базовый класс и наследоваться от него, это означало бы много переделок, когда придет время объединить все приложения в "корпоративную" версию продукта.

Таким образом, частичные классы весьма полезны, поскольку я могу довольно просто включить различные частичные классы в объединенную версию, при этом сохраняя возможность создания отдельных, автономных версий продукта. Если бы я попытался сделать это с помощью наследования, то в итоге каждый компонент вызывал бы свою собственную версию общих компонентов (например, InvoiceReportViewer, PurchasingReportsViewer и т.д.), а не просто вызывал бы ReportsViewer и знал бы, что Visual Studio интегрирует все биты за меня.