Когда я создаю библиотеку классов, я обычно создаю файл Enums.cs для хранения всех перечислений, используемых в сборке. Вот пример:
namespace MyNamespace
{
public enum Colors
{
Red,
Green,
Blue
}
public enum Shapes
{
Circle,
Square,
Triangle
}
}
Это упрощает поиск всех моих перечислений, хорошо организованных и простых в доступе в коде.
Мне интересно, есть ли причина, почему это не будет такой хорошей идеей?
Как правило, лучше упорядочивать определения по модульности, а не по виду.
Я лично считаю, что это не очень хорошая идея. Я предпочитаю хранить перечисления в собственном файле (один файл в определенном перечислении), как и класс. Это делает его более очевидным (для меня), куда идти, если я ищу тип, по имени. Я рассматриваю перечисления так же, как класс или структуру, или любой другой тип пространства имен, который для меня означает один тип для каждого файла.
Основной недостаток вашего подхода возникает, если в вашем проекте определено много перечислений, что "один файл" может стать довольно большим.
Однако в компилированном IL нет технической разницы. Это действительно более личная, организационная стратегия.
Ну, вы можете применить те же аргументы ко всем вашим типам делегатов, всем своим классам, всем вашим структурам.
Объединяя вещи в соответствии с их значимостью для компилятора, вы теряете возможность группировать их способами, которые имеют для вас значение. Компилятор уже знает, как относиться к ним в соответствии с их значением на языке.
Лично, когда я хочу найти объявления, относящиеся к "Parser", в отличие от "Диалоговое окно конфигурации", я перехожу к тому месту, где сохраняется код для этой функции. Мне не нужно смотреть в пяти разных местах в зависимости от особенностей языка, которые я использую.
Я думаю, что это зависит от того, в каких областях кода они применяются. Если я смотрю на функцию в определенном классе, я ожидаю, что связанные перечисления будут рядом.
Обычно у нас есть весь проект, сборка, в которой хранятся все наши константы, перечисления и вспомогательные методы.
Итак ДА, я бы рекомендовал разместить их в центральном, легко доступном месте.
Это позволит вам легко получить доступ к сборке из других сборок, пытаясь избежать циклических ссылок.
Я перехожу к большей части организации пространства имен. Visual Studio упрощает навигацию к объявлению объекта. Мне больше смысла иметь перечисление, связанное с доступом к базе данных/данных в моем пространстве имен MyData, а не какое-то общее пространство имен enum, я мог бы не беспокоиться о имени файла.
Я разработчик java, но я думаю, что могу ответить и здесь...
Для меня это не очень хорошая идея. Как и Дэниел Эрвиккер, вы можете сделать то же самое для классов... вы можете обрабатывать все ваше приложение в одном файле со многими внутренними классами (я предполагаю, что на С#, как на Java, вы можете иметь внутренние классы...), но вы не знаете, t все равно...
И перечисление может когда-нибудь быть более сложной структурой, оно может иметь атрибуты...
A (очень) простой пример в Java:
public enum JobPriority {
HIGH(5),
MEDIUM_HIGH(4),
MEDIUM(3),
MEDIUM_LOW(2),
LOW(1)
;
private int level;
JobPriority(int level) {
this.level = level;
}
public int getLevel() {
return level;
}
}
Я работаю на очень большом французском веб-сайте, и у нас есть структуры перечисления намного сложнее, чем это... Если бы у нас были все наши перечисления в одном файле, этот файл создавал бы сотни строк...
Итак, если ваше приложение мало, а структура перечисления не является сложной, вы можете поместить все их в один файл.
Но вы предпочли бы размещать сложные перечисления в отдельных файлах в пространстве имен enum (пакет в java) и создавать пространство имен enum, когда это необходимо для каждой функциональной части вашего приложения. Для простых перечислений, почему бы не добавить затем в общий файл enum для данного пространства имен (вы можете иметь несколько общих файлов перечислений). Не знаю, если это хорошая практика.
Вам действительно важно иметь много файлов enum? Если вам нужно найти перечисление, ваша среда IDE, возможно, предложит вам быстрый поиск класса для поиска легко перечислений нет? Вы также можете суффиксом всех ваших перечислений с помощью xxxEnum.cs, чтобы отличить их (а также быстро найти их по имени класса * Enum).
В java webapp я работаю над (~ 2 миллиона строк кода, сотни перечислений), мы можем легко найти перечисления в нашей Eclipse IDE с ярлыками, такими как ctrl + shift + R + * Enum. Это намного быстрее, чем с общими файлами enum:)
Существуют определенные имена файлов кода, которые сразу же поднимут для меня красный флаг. Наряду с utils.cpp, helpers.vb (или подобным), если я вижу enums.cs, я сразу задаю вопрос, перестает ли часть программного обеспечения связываться с перечислениями.
Перечисления должны использоваться экономно и объявляться рядом с типами, связанными с листом (с наименьшим типом), с которыми они связаны.
Слишком часто я видел большие системы, которые переполняются из-за общих перечислений. До слишком долгого времени у кого-то будет яркая идея перечислить все первичные ключи базы данных.