Best Practices: когда не использовать частичные классы - PullRequest
35 голосов
/ 09 декабря 2008

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

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

Что ты думаешь? Есть ли проблемы с использованием таких частичных классов или все сводится к предпочтениям?

Например, у меня обычно есть что-то вроде этого:

  • MainClass.cs
  • MainClass.Helper1.cs
  • MainClass.Helper2.cs

...

// Inside of MainClass.cs I have code like this:

public abstract partial class MainClass
{
    // ...
}

// Then in the MainClass.Helper1.cs I have:

partial class MainClass
{
   private class Helper1
   {
       // ...
   }
}

Ответы [ 10 ]

26 голосов
/ 09 декабря 2008

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

7 голосов
/ 09 декабря 2008

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

Если вы используете такие частичные классы, ознакомьтесь с (бесплатной) надстройкой vsCommands (для Visual Studio 2008), которая упрощает группирование файлов в обозревателе решений (например, файлы дизайнеров) ) без редактирования файла проекта.

4 голосов
/ 09 декабря 2008

Краткий ответ: Если все классы являются вашим кодом, вам на самом деле не нужны вспомогательные классы, что лишает вас нужды в партиалах.

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

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

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

2 голосов
/ 28 декабря 2012

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

2 голосов
/ 09 декабря 2008

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

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

1 голос
/ 18 сентября 2014

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

Но! Хотя и не часто, я иногда обнаруживал, что интенсивное модульное тестирование класса (обычно внешних классов) приводит к гигантским классам модульного тестирования. Разделение класса модульного теста на частичные классы облегчает понимание и понимание.

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

1 голос
/ 09 декабря 2008

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

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

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

1 голос
/ 09 декабря 2008

Я не очень большой поклонник частичных классов и не использую их сам.

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

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

0 голосов
/ 09 декабря 2008

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

0 голосов
/ 09 декабря 2008

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

...