В общем зашла речь о задаче в каком-то там ВУЗе: написать программу, ...
И все бы ничего, но в условии была следующая структура (восстановлено по памяти):
Комментарий привлек внимание
В общем хорошо посмеялись, что наверняка составитель мужик (кстати, так и оказалось), но потом задумались.
Наверняка использовать перечисление было бы нагляднее, хотя с другой стороны перечисление из двух элементов — это не совсем удобно.
Заглядывая в MSDN иногда встречаются перечисления из двух элементов, например (Automatic, Manual).
Вопрос такой, как же правильней и от чего это зависит ?
Может кто помнит, где это в стандарте прописано.
Alexey_N пишет: > Вопрос такой, как же правильней и от чего это зависит ?
Начнем с того, что правильно Sex, а не Male.
А остальное зависит от предметной области. Как-то делал БД для
буржуйских медиков, у них было штук восемь разных "полов" в справочнике.
Причем "неизвестен" и "не определен" это разные сущности. Я
подозреваю, с чем это связано, но вдаваться в подробности не хотелось.
ЗЫ. По идее правильно перечисления, даже если два значения.
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, Alexey_N, Вы писали: A_N> bool Male; //пол: true — мужской, false — женский A_N>Вопрос такой, как же правильней и от чего это зависит ? A_N>Может кто помнит, где это в стандарте прописано.
Зависит от задачи.
Если вы работаете с БД, то как вы будете интерпретировать ваш enum (не спорю, можно конечно, но это как из пушки по вробьям)?
Иначе, можно так:
[Flags]
enum SEX
{
Man = 0x01,
Women = 0x02,
Unknown = 0x04
}
Здравствуйте, Prometheus, Вы писали:
P>Здравствуйте, Alexey_N, Вы писали: A_N>> bool Male; //пол: true — мужской, false — женский A_N>>Вопрос такой, как же правильней и от чего это зависит ? A_N>>Может кто помнит, где это в стандарте прописано.
P>Зависит от задачи. P>Если вы работаете с БД, то как вы будете интерпретировать ваш enum (не спорю, можно конечно, но это как из пушки по вробьям)?
P>Иначе, можно так: P>[Flags] P>enum SEX P>{ P> Man = 0x01, P> Women = 0x02, P> Unknown = 0x04 P>}
может получиться что одновременно неизвестного пола гермофрадит?
P>или так: P>enum SEX : byte P>{ P> Man = 1, P> Women = 2 P>};
P>или так: P>enum SEX P>{ P> Man, P> Woman, P> Unknown P>}
Здравствуйте, Ромашка, Вы писали:
Р>Alexey_N пишет: >> Вопрос такой, как же правильней и от чего это зависит ?
Р>Начнем с того, что правильно Sex, а не Male.
Р>А остальное зависит от предметной области. Как-то делал БД для Р>буржуйских медиков, у них было штук восемь разных "полов" в справочнике. Р> Причем "неизвестен" и "не определен" это разные сущности. Я Р>подозреваю, с чем это связано, но вдаваться в подробности не хотелось.
неизвестен -- не видели
неопределен -- видели, но непонятно что там: мужское, женское или еще какое
Р>ЗЫ. По идее правильно перечисления, даже если два значения.
Здравствуйте, Alexey_N, Вы писали:
A_N>Вопрос такой, как же правильней и от чего это зависит ?
Правильно, конечно, enum. Потому что при этом сильно лучше читаемость кода. Это во-первых. А во-вторых если завтра понадобится какой нибудь отдельный пол для транссексуалов — что будешь со своим булом делать?
A_N>Может кто помнит, где это в стандарте прописано.
В каком стандарте?
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>В каком стандарте?
У Microsoft есть например статьи по правилам именования переменных, классов и т.д. Они во многих местах используются как стандарт. Возможно есть статьи и на тему правил создания enum.
Enum в данной ситуации совершенно точно правильнее.
Во-первых, не будет возникать вопросов, что означает true и false.
Во-вторых, в какой-то момент может потребоваться другое значение, например, где-то в Малазии, кажется, уже попадается "средний" пол
В то же время бывают и удачные места для применения bool. Но никак не здесь, ИМХО.
Здравствуйте, <Аноним>, Вы писали:
А>У Microsoft есть например статьи по правилам именования переменных, классов и т.д. Они во многих местах используются как стандарт. Возможно есть статьи и на тему правил создания enum.
Стандартов никаких на эту тему нет.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, Alexey_N, Вы писали:
A_N>В общем зашла речь о задаче в каком-то там ВУЗе: написать программу, ... A_N>И все бы ничего, но в условии была следующая структура (восстановлено по памяти):
Мне это напомнило шуточную задачу про столы и ножки.
Здравствуйте, Prometheus, Вы писали:
P>Если вы работаете с БД
Если работать с БД, то надо задуматься о том, что енум может меняться (ну не как пол конечно). В этом случае, возможно, понадобится что то вроде:
public class Sex
{
public static Sex Male = new Guid("...");
public static Sex Female = new Guid("...");
private readonly Guid _value;
private Sex(Guid value)
{
_value = value;
}
// Override Equals and GetHashCode, implement IEquatable<T>, == and != operators
}
Ну и в БД поле, естественно, uniqueidentifier или byte[16].
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, Alexey_N, Вы писали:
A_N>Наверняка использовать перечисление было бы нагляднее,
По-моему, да.
A_N>хотя с другой стороны перечисление из двух элементов — это не совсем удобно.
Почему?
A_N>Вопрос такой, как же правильней и от чего это зависит ?
Я бы сделал enum (С++):
enum Sex // пол
{
Sex_Male,
Sex_Female,
};
Строго говоря, bool – это тоже enum (true/false или yes/no), только встроенный.
Chapter 11. Fundamental Data
… 11.6 Enumerated Types
… Use enumerated types as an alternative to boolean variables. Often, a boolean variable isn’t rich enough to express the meanings it needs to. For example, suppose you have a routine return True if it has successfully performed its task and False otherwise. Later you might find that you really have two kinds of False. The first kind means that the task failed, and the effects are limited to the routine itself; the second kind means that the task failed and caused a fatal error that will need to be propagated to the rest of the program. In this case, an enumerated type with the values Success, Warning, and FatalError would be more useful than a boolean with the values True and False. This scheme can easily be expanded to handle additional distinctions in the kinds of success or failure.
(В русском переводе это раздел 12.6 «Перечислимые типы».)
2. Аналогичный вопрос возникает при создании пользовательского интерфейса. Можно выбрать CheckBox (аналог bool-а) или пару RadioButton-ов (аналог enum-а с двумя значениями). Влад Головач в книге «Дизайн пользовательского интерфейса» пишет:
Инвентарь
… Элементы управления
… Чекбоксы и радиокнопки
…
Всякий раз, когда пользователю нужно предоставить выбор между несколькими параметрами, можно использовать либо чекбоксы, либо радиокнопки (или списки, но о них позже). Если параметров больше двух, выбор прост: если параметры можно комбинировать, нужно использовать чекбоксы (например, текст может быть одновременно и жирным и курсивным); если же параметры комбинировать нельзя, нужно использовать радиокнопки (например, текст может быть выровнен или по левому, или по правому краю).
Если же параметров всего два и при этом параметры невозможно комбинировать (т.е. либо ДА, либо НЕТ), решение более сложно. Дело в том, что группу из двух радиокнопок часто можно заменить одним чекбоксом. Предположим, что нужно дать пользователю выбор: показывать в документе линейки или не показывать. В этом случае логично поместить в диалоговое окно рамку группировки (см. «Структура окна» на стр. 94) со словами Показывать линейки, а в эту рамку поместить две радиокнопки: Да и Нет. Понятно, что это решение очень тяжеловесно. Можно сделать проще: убрать рамку группировки и радиокнопки, а на их место поместить всего один чекбокс со словами Показывать линейки. В этом случае всё будет хорошо. К сожалению, этот метод работает не всегда. Поскольку в самом чекбоксе написано только то, что произойдёт после его включения, но не описано, что произойдёт, если его не включить, такая конструкция не работает в ситуациях, когда пользователям по той или иной причине функциональность непоставленного чекбокса может быть непонятна. Например, если нужно спросить пользователя, в какой кодировке посылать ему письма, не получится заменить две радиокнопки Windows 1251 и KOI-8 единым чекбоксом KOI-8. Пользователь не обязан понимать, в какой кодировке система будет посылать ему письма по умолчанию. К счастью, такие ситуации редки.
P. S. Вспомнилась забавная рекомендация по заполнению анкеты:
Здравствуйте, Ромашка, Вы писали:
Р>Начнем с того, что правильно Sex, а не Male.
Начнём с того, что не Sex, Gender. Но если используется bool, то по правилам хорошего наименования должно быть IsMale.
Р>А остальное зависит от предметной области. Как-то делал БД для Р>буржуйских медиков, у них было штук восемь разных "полов" в справочнике. Р> Причем "неизвестен" и "не определен" это разные сущности. Я Р>подозреваю, с чем это связано, но вдаваться в подробности не хотелось.
Это связано с тем, что на ещё не родившегося ребёнка, пол которого ещё не определён уже заводится медицинская карточка.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ромашка, Вы писали:
Р>Alexey_N пишет: >> Вопрос такой, как же правильней и от чего это зависит ?
Р>Начнем с того, что правильно Sex, а не Male.
Во-во. bool Sex; значения — true, false. Как в том бородатом анекдоте.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, IT, Вы писали:
IT>Буржуй это прочитает примерно так
IT>[Flags] IT>enum ПОЛОВАЯ_ЖИЗНЬ IT>{ IT> Человек = 0x01, IT> Женщины = 0x02, IT> Неизвестно = 0x04 IT>}
Да, но если написать правильно — Male/Female, то прочтет не "ПОЛОВАЯ_ЖИЗНЬ", а именно "ПОЛ".
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, IT, Вы писали: Р>>Начнем с того, что правильно Sex, а не Male. IT>Начнём с того, что не Sex, Gender.
Насколько я знаю, sex – это пол (биологическое понятие), gender – род (грамматическое понятие). Lingvo 6.5:
gender 1.сущ.
1) грам. род
feminine gender — женский род
grammatical gender — грамматический род
masculine gender — мужской род
neuter gender — средний род
2) шутл. пол
Syn:
sex 2.гл.; поэт.
порождать
Syn:
beget, give birth, engender, produce 2.
sex сущ.
1) биол. пол
the fair, weaker sex — прекрасный пол, женщины
the female sex — женский пол
the male sex — мужской пол
the sterner, stronger sex — сильный пол, мужчины
member of the opposite sex — представитель противоположного пола
the sex шутл. — женщины
2) секс, половая жизнь
to have sex with smb. — заниматься сексом с кем-л.
— explicit sex
— illicit sex
— kinky sex
— perverse sex
— premarital sex
— sex instinct
— sex intergrade
Здравствуйте, McSeem2, Вы писали:
IT>>Начнём с того, что не Sex, Gender.
MS>Эвона как. Значит я могу засудить DMV, ибо на моих водительских правах написано именно "Sex: M"
Ну так тож водительские права.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали: IT>Если конкретно по медикам, то довелось мне работать на одном проекте для медиков, конкретно для докторов. Никаких сексов там не было в помине.
Пожалуй, соглашусь с Вами. Была такая игра «Rex Nebular and the Cosmic Gender Bender». В одном из описаний название было переведено так: «Рекс Небьюлар и космический изменитель пола». Статья в Wikipedia:
Rex Nebular and the Cosmic Gender Bender
… Storyline
…
So they invented a machine that would allow them to alter their sex for short periods of time. This machine became known as the Cosmic Gender Bender, or the Gender Bender for short.
… Characters
* Rex Nebular: Believes he is God's gift to women. Pilot and Captain of his space vessel, the Slippery Pig.
…
* Rox: Rex's female alter-ego. Rex becomes Rox after stepping into the Gender Bender device and has his gender "bent".
То есть используются оба слова – и «sex», и «gender». Но в игре много стёба, и, похоже, слово «gender» в смысле «пол» используется с шутливым оттенком (как и написано в Lingvo).
А вообще, я тут бегло поискал в Интернете, и, похоже, оба слова используются на равных, как синонимы. Я попытался примерно оценить, как обстоит дело с анкетами.
На слова «gender male female age» Google выдаёт примерно 2'770'000 ссылок.
На слова «sex male female age» Google выдаёт примерно 6'480'000 ссылок.
Для прояснения ситуации требуется Alex Reyst .
P. S. Возможно, это как «бордюр» в Москве и «поребрик» в Санкт-Петербурге , региональные языковые особенности.
Здравствуйте, McSeem2, Вы писали:
MS>Да, но если написать правильно — Male/Female, то прочтет не "ПОЛОВАЯ_ЖИЗНЬ", а именно "ПОЛ".
По-моему, вам намекали на gender: man/woman или men/women.
Здравствуйте, IT, Вы писали:
IT>Начнём с того, что не Sex, Gender. Но если используется bool, то по правилам хорошего наименования должно быть IsMale.
Последнее вроде бы касается getter-ов (свойств), то есть поле все же male с соответствующим ему getter-ом IsMale.
Здравствуйте, Пётр Седов, Вы писали:
ПС>Для прояснения ситуации требуется Alex Reyst .
В профессиональной медицинской/биологической лексике:
Sex — биологический пол.
Gender — наблюдаемый пол. Исторически — анатомически наблюдаемый, но в настоящее время слово gender все больше отвечает за такие половые различия, как поведенческие, а "ответственность" за анатомические различия постепенно переносится на тот же sex.
Тем не менее пока общепринятому, бытовому смыслу слова sex (== пол) в профессиональной медицинской лексике соответствует термин gender.
Все, что здесь сказано, может и будет использоваться против меня.
Здравствуйте, Ромашка, Вы писали:
Р>Alexey_N пишет: >> Вопрос такой, как же правильней и от чего это зависит ?
Р>Начнем с того, что правильно Sex, а не Male.
Р>А остальное зависит от предметной области. Как-то делал БД для Р>буржуйских медиков, у них было штук восемь разных "полов" в справочнике. Р> Причем "неизвестен" и "не определен" это разные сущности. Я Р>подозреваю, с чем это связано, но вдаваться в подробности не хотелось.
В базе данных ФБР, к примеру, используются следующие значения для пола:
Мужской
Женский
Мужской, бывший женский
Женский, бывший мужской
Мужской, меняющийся на женский
Женский, меняющийся на мужской
Неизвестен
Не определен
Р>ЗЫ. По идее правильно перечисления, даже если два значения.
Да, если даже в текущий момент используются два значения, в будущем могут
добавиться новые. Если уже использовано перечисление, добавление новых
значений будет проще реализовать.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Alexey_N, Вы писали:
A_N>>Вопрос такой, как же правильней и от чего это зависит ?
AVK>Правильно, конечно, enum. Потому что при этом сильно лучше читаемость кода. Это во-первых. А во-вторых если завтра понадобится какой нибудь отдельный пол для транссексуалов — что будешь со своим булом делать?
A_N>>Может кто помнит, где это в стандарте прописано.
AVK>В каком стандарте?
Например, в этом: ISO/IEC 5218:2004ISO/IEC 5218:2004: Codes for the representation of human sexes
Здравствуйте, Igor Trofimov, Вы писали:
iT>Enum в данной ситуации совершенно точно правильнее. iT>Во-первых, не будет возникать вопросов, что означает true и false.
Совершенно верно! Столкнулся с таким на практике в одной из наших баз. Благо, носитель сакрального знания был под рукой.
Здравствуйте, Alex Reyst, Вы писали:
AR>Тем не менее пока общепринятому, бытовому смыслу слова sex (== пол) в профессиональной медицинской лексике соответствует термин gender.
Раньше, лет 30 назад, в анкетах использовали почти всегда sex. Но теперь чаще все таки используют gender, потому что sex считается, типа, не совсем корректным к пи... сексуальным меньшинствам.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, Flying Dutchman, Вы писали:
FD>В базе данных ФБР, к примеру, используются следующие значения для пола:
FD> Мужской FD> Женский FD> Мужской, бывший женский FD> Женский, бывший мужской FD> Мужской, меняющийся на женский FD> Женский, меняющийся на мужской FD> Неизвестен FD> Не определен
Здравствуйте, Alexey_N, Вы писали:
A_N>Вопрос такой, как же правильней и от чего это зависит ?
Как я понял по обсуждению в этой теме, большинство склоняются в сторону enum. Основной аргумент заключается в том, что в будущем может понадобится добавить новый пол, а в случае с boolean изменений в коде придется делать больше, чем в случае с enum.
На мой взгляд, если мы ожидаем неограниченное увеличение количества полов, то вариант с enum'ом будет настолько же неадекватным, насколько и вариант в boolean. Наивно полагать, что когда мы захотим добавить новый пол, нам нужно будет всего лишь добавить новую строчку в объявление enum'а. На самом деле, нам придется еще просмотреть все места где делается switch по этому enum'у для того, чтобы добавить новый case, или убедиться, что default ветка корректно обрабатывает новый случай.
В случае, если расширение полов не ведет к добалению новой логики (т.е. нет ветвлений по полам и все значения полов обрабатываются одинаково), то и вводить enum особого смысла не имеет. Как вариант, в качестве значений пола у нас могут быть даже просто строки "Male", "Female", "Other", "Unknown". Либо (для надежности и типобезопасности) экземпляры специального класса (не enum'а).
Здравствуйте, dshe, Вы писали:
D>Как я понял по обсуждению в этой теме, большинство склоняются в сторону enum.
Я, по крайней мере, за enum со значениями Male и Female.
D>Основной аргумент заключается в том, что в будущем может понадобится добавить новый пол, а в случае с boolean изменений в коде придется делать больше, чем в случае с enum.
По-моему, это не основной аргумент. Мой основной аргумент в том, что в данном случае (пол) enum более естественно выражает мысли программиста. bool для пола смотрится странно:
Анкета
Вы мужчина? (нужное подчеркнуть) да нет
Возраст: __
…
В немужском туалете засорилась канализация.
enum позволяет избежать отрицаний, а чем меньше отрицаний, тем понятнее код. Сравните
if (!UserIsMale && ...)
{
MessageBox("Поздравляем с восьмым марта!");
}
и
if ((UserSex == Sex_Female) && ...)
{
MessageBox("Поздравляем с восьмым марта!");
}
D>Как вариант, в качестве значений пола у нас могут быть даже просто строки "Male", "Female", "Other", "Unknown". Либо (для надежности и типобезопасности) экземпляры специального класса (не enum'а).
Насколько я знаю, в Java так сделано, там элементы enum-а – это объекты.
Здравствуйте, dshe, Вы писали:
D>Как я понял по обсуждению в этой теме, большинство склоняются в сторону enum. Основной аргумент заключается в том, что в будущем может понадобится добавить новый пол, а в случае с boolean изменений в коде придется делать больше, чем в случае с enum. D>На мой взгляд, если мы ожидаем неограниченное увеличение количества полов, то вариант с enum'ом будет настолько же неадекватным, насколько и вариант в boolean. Наивно полагать, что когда мы захотим добавить новый пол, нам нужно будет всего лишь добавить новую строчку в объявление enum'а. На самом деле, нам придется еще просмотреть все места где делается switch по этому enum'у для того, чтобы добавить новый case, или убедиться, что default ветка корректно обрабатывает новый случай.
Только все эти места можно найти на раз, если обработку в клиентском коде делать примерно так:
for (Gender gender : Gender.values())
switch (gender) {
case MALE:
//...break;
case FEMALE:
//...break;
default:
assert false : "Неизвестный пол: " + gender;
break;
}
В итоге, если включить все проверки внутренней корректности кода, то на этапе отладки достаточно просто найти все места, где забыли вставить логику обработки нового gender.
Это только один из вариантов. Можно и по-другому. К примеру, в Java, где перечисления могут иметь реализацию, можно поступить так... это, кстати, опровергает ваш тезис (см. выделенное в цитате).
public enum Gender {
MALE() {
@Override
public Object method(Object... attributes) {
//...
}
},
FEMALE() {
@Override
public Object method(Object... attributes) {
//...
}
};
public abstract Object method(Object... attributes);
}
В итоге, при добавлении нового члена перечисления компилятор сразу попросит добавить для него реализацию специфической для него логики — метода method, а клиентский (внешний по отношению к перечислению код) практически и не заметит изменений, если будет работать с перечислениями с помощью метода method. Этот вариант более красивый, так как логика не размазывается по клиентскому коду, а собрана в перечислении.
D>В случае, если расширение полов не ведет к добалению новой логики (т.е. нет ветвлений по полам и все значения полов обрабатываются одинаково), то и вводить enum особого смысла не имеет. Как вариант, в качестве значений пола у нас могут быть даже просто строки "Male", "Female", "Other", "Unknown". Либо (для надежности и типобезопасности) экземпляры специального класса (не enum'а).
Как понял, весь разговор именно и идет о том, что логика такая необходима.