Рекомендации по внутренней группировке членов класса

2

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

Используете ли вы регионы? Я использую их вместе с группами, созданными генератором-заглушкой для реализации интерфейса Visual Studio, например:

#region IEnumerable

...

#endregion

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

Как вы справляетесь с этим?

Теги:

5 ответов

2
Лучший ответ

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

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

Поделиться
5

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

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

Поделиться
  • 0
    Иногда я буду использовать вложенные регионы для группировки определенного набора методов, если они реализуют интерфейс.
  • 0
    Спасибо, но я думаю, что разбивать типы не очень хорошая идея. Я включаю только те вещи, которые полностью соответствуют классу. Вы по-прежнему можете использовать 20-30 методов, в зависимости от класса, например, для типов XNA.
1

Используйте регионы, разбитые по функциональности. Таким образом, по мере роста вашего класса, вы можете видеть, как отдельные регионы начинают расти, а затем сами регионы становятся указателями того, какие обязанности выполняет этот класс, а также рекомендации по рефакторингу (т.е. "Эй, мой" элемент процесса "как 5 функций! Может быть, мне нужен класс для обработки элементов!" ).

Поделиться
1

В общем:

  • Конструкторы (если есть перегрузки)
  • Статические методы
  • Методы
  • Свойства
  • События
  • Возможно группировка реализации интерфейса (а именно IEnumerable<T>), но абсолютно для явных реализаций интерфейса
  • Вложенные типы

Если ASP.NET:

  • Элементы управления (поля, имя которых сопоставляется с элементом управления)

Если у меня есть метод, который имеет несколько перегрузок, я добавляю для них область. Или, если есть несколько методов, которые являются похожими, но не обязательно перегружаемыми (например, Find, FindAll, FindIndex и т.д. В List<T>, тогда они будут в одной области "Найти" ).

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

Это мой общий подход к организации, от которого также следуют мои регионы. Опять же: в общем. Каждый класс отличается (иначе зачем его писать?), Поэтому YMWV: в нем нет "can".

Поделиться
0

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

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

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню