Частичные классы в C#

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

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

Как отмечалось ранее, я также думаю, что это - запах кода.

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

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

Я нахожу, что частичные классы чрезвычайно полезны. Обычно они используются, чтобы смочь расширить автоматически сгенерированные классы. Я использовал их в одном проекте с тяжелыми модульными тестами. Мои классы UT имели сложные зависимости, и это не было очень практично для разделения кода через несколько классов. Конечно, лучше использовать inheritance\composition, но в некоторых случаях частичные классы могут быть полезным митингом.

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

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

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

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

// Main Part
public partial class Class1
{
    private partial void LogSomethingDebugOnly();

    public void SomeMethod()
    {
        LogSomethingDebugOnly();
        // do the real work
    }
}

// Debug Part - probably in a different file
public partial class Class1
{

    #if DEBUG

    private partial void LogSomethingDebugOnly()
    {
        // Do the logging or diagnostic work
    }

    #endif
}

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

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

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

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

Берут WinForms или Введенные Наборы данных, например (или любой разработчик в этом отношении). Каждый раз Вы вносите изменение в разработчика, оно сериализирует соответствующий код в файл. Скажем, необходимо обеспечить несколько дополнительных методов, о которых генератор ничего не знает. Если бы Вы добавили его к сгенерированному файлу, то Ваши изменения были бы потеряны в следующий раз, когда это было сгенерировано.

проект А, что я в настоящее время работаю над генерацией кода использования для всего DAL, BLL и предприятий. Однако генератор только get's нас 75% информации. Остающаяся часть должна быть кодированной рукой (пользовательская бизнес-логика, например). Я могу предположить, что каждый класс BLL имеет метод SelectAll, таким образом, это легко генерировать. Однако у Моего клиента BLL также должен быть метод SelectAllByLocation. Я не могу поместить это в свой генератор, потому что это не универсально ко всем классам BLL. Поэтому я генерирую все свои классы как частичные классы, и затем в отдельном файле я определяю свои пользовательские методы. Теперь в будущем, когда моя структура изменяется, или я должен повторно создать свой BLL по некоторым причинам, мой пользовательский код не будет вытерт.

РЕДАКТИРОВАНИЕ: Инструменты DSL для Visual Studio используют частичные классы.

Таким образом, это - функция, которую используют много автоматических сгенерированных кодов. Вместо того, чтобы использовать #region автоматический сгенерированный код переходит к одному файлу, и пользовательский код (также названный пользовательским кодом) переходит к другому и даже в различных каталогах так, чтобы разработчик не запутывался с таким количеством бессмысленных файлов.

хорошо иметь этот выбор, который можно объединить - но не вынужденные использовать - с наследованием

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

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

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

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

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

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

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

Я просто нашел использование для частичных классов. У меня есть класс [DataContract], который я использую, чтобы передать данные клиенту. Я хотел, чтобы клиент смог отобразить класс в особенном методе (текстовый вывод). таким образом, я создал частичный класс и переопределил метод ToString.

Исправление, как Matt указал, обе стороны частичной потребности быть в том же блоке. мое плохое.

Обычно я считаю это запахом кода.

, Если Ваш класс - то, который усложнил затем, это может, вероятно, быть разбито в меньшие допускающие повторное использование компоненты.

Или это означает, что нет никакой иерархии наследования, где должен быть тот.

Для сценариев генерации кода это хорошо, но я думаю, что генерация кода является другим запахом кода.

Я работал над парой проекта несколько лет назад, где у нас был введенный класс DataSet, который имел тонну кода в ней: Методы в DataTables, методы в TableAdapters, объявлениях экземпляров TableAdapter, Вы называете его. Это была крупная центральная точка проекта, что все должны были часто продолжать работать, и было много конкуренции управления исходным кодом по частичному файлу кода класса.

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

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

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