Организация класса - PullRequest
       11

Организация класса

5 голосов
/ 12 октября 2008

Каков наилучший способ сортировки учеников?

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

Что ты думаешь?

Ответы [ 10 ]

11 голосов
/ 12 октября 2008

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

3 голосов
/ 12 октября 2008

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

Некоторые также считают целесообразным объединять методы доступа и модификаторы в отдельные разделы.

2 голосов
/ 12 октября 2008

Я изучил этот вопрос как часть магистерской диссертации.

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

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

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

1 голос
/ 12 октября 2008

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

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

1 голос
/ 12 октября 2008

Это только мое мнение, которое, я уверен, будет непопулярным, но проблема с семантической сортировкой является ее субъективной. У каждого человека будет свое мнение о том, какие методы должны быть близко друг к другу.

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

Большинство IDE имеют контуры или гиперссылки для упрощения навигации.

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

0 голосов
/ 20 июля 2009

Полагаю, я один из странных случаев, предпочитающих алфавитные списки.

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

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

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

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

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

0 голосов
/ 26 октября 2008

На более высоком уровне я бы организовал свой класс следующим образом:

  1. Конструктор
  2. Destructor
  3. Личные поля
  4. Свойства
  5. Методы / Функции

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

RWendi

0 голосов
/ 26 октября 2008

Предполагая, что вы используете современную среду IDE, поиск нужного метода редко занимает больше двух щелчков мыши, поэтому я не уверен, что вам поможет конкретный способ организации ваших методов. Я использую stylecop (http://code.msdn.microsoft.com/sourceanalysis), в котором я упорядочиваю по public / private / method / properties - я обнаружил, что это достаточно анально.

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

0 голосов
/ 12 октября 2008

Вы можете перейти от семантического к буквенному, отсортировав «отображение методов» в вашей IDE.

Нельзя перейти (автоматически) с буквенного на семантический.

Отсюда: семантика.

0 голосов
/ 12 октября 2008

Вы пишете телефонную книгу?

С семантическим подходом вы можете легко показать, какие из них являются наиболее важными. Обычно я сначала использую конструктор, деструктор, затем важные методы, затем геттеры и сеттеры и, в конце концов, разное. методы. Наконец, я использую аналогичный подход для внутренних частей (частные методы, атрибуты ...).

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

...