Реализация интерфейсов в разделяемых классах

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

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

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

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

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

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

Единственным преимуществом является наличие различных реализаций интерфейса в отдельных физических файлах.

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

Pro: может легко определить, какая часть класса реализует какой интерфейс (хорошо, когда вы используете инструмент, который не позволяет легко перемещаться по коду внутри IDE).

Минусы: легче потерять контекст, так как теперь вам нужно перемещаться по нескольким файлам.

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

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

Это имеет такой же смысл, как наличие конструкторов в одном файле частичного класса, свойств в другом файле частичного класса и т. д. и т. д.

т. е. не делайте этого, если у вас нет веской причины.

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

В зависимости от того, сколько интерфейсов вы действительно имеете в виду под «множеством интерфейсов», вы можете использовать регионы для разделения реализаций. Это было бы нормально до 10-15 интерфейсов с общим количеством, скажем, 150 функций для реализации. После этого все станет грязным, и вы потеряете обзор. И именно здесь вы сможете воспользоваться другими механизмами, такими как наследование, инкапсуляция или агрегация, а также использование служб и вспомогательных классов.

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