Мы должны всегда одобрять полиморфизм по перечислениям?
+(BOOL)doesSystemVersionMeetRequirement:(NSString *)minRequirement{
// eg NSString *reqSysVer = @"4.0";
NSString *currSysVer = [[UIDevice currentDevice] systemVersion];
if ([currSysVer compare:minRequirement options:NSNumericSearch] != NSOrderedAscending)
{
return YES;
}else{
return NO;
}
}
6 ответов
It не, что перечисления являются злыми, это - операторы переключения. Существует долгое обсуждение этого в Книга FAQ C++, но суть - это: за исключением ограниченных областей---, например, интерпретация данных, входящих от регистра на устройстве---большая расческа переключателя, предполагает использование данных для различения подтипы. Вместо этого необходимо просто использовать подтипы, получение справки компилятора в хранении его исправляет, и также значение, что компилятор автоматически добавит новые случаи, когда Вы (неизбежно) измените набор случаев.
В первую очередь, Java на самом деле имеет большие перечисления, которые могут использоваться полиморфно. Я не программист Java, таким образом, кто-то еще может, конечно, дать хороший пример (я не могу). Кроме того, полагайте, что полиморфизм является часто просто излишеством. Я также только что видел разговор, и это является большим, но это только предоставляет инструкции, никакую серебряную пулю.
Это особенно не верно, что весь switch операторы могут быть заменены. Конечные автоматы являются на самом деле одним случаем, где перечисления имеют много смысла. Я использую конечные автоматы много в парсинге. Несомненно, это может быть сделано с полиморфизмом класса и шаблоном разработки. Но это - очень ( очень ) больше кода, это выполняет то же задание, только медленнее, это не более читаемая капля, и это - решение, это только необходимо в одном единственном месте без любой переработки кода. Используя разделение на подклассы здесь просто имеет преимущество.
С другой стороны, это - исключение. В целом разделение на подклассы часто является лучшим решением на языках, которые поддерживают его хорошо.
РЕДАКТИРОВАНИЕ: Я замечаю, что это могло бы повысить противоречие. Конечно, существует много хороших решений, которые инкапсулируют парсинг от регулярных выражений до платформ парсера-генератора, таких как Antlr. Ничто неправильно с ними и во всех кроме тривиальных случаев это лучшее решение. Однако я работаю много с кодом низкого уровня (не в Java, очевидно), где регулярные выражения не поддерживаются, и парсеры-генераторы также подвергаются издержкам.
class Sunday extends DayOfWeek {}
class Monday extends DayOfWeek {}
class Tuesday extends DayOfWeek {}
class Wednesday extends DayOfWeek {}
class Thursday extends DayOfWeek {}
class Friday extends DayOfWeek {}
class Saturday extends DayOfWeek {}
Перечисления прекрасны.
Я смущаюсь называть что-либо зло . Это - вопрос, "Как тяжелый делают Вы хотите спроектировать это".
Перечисления/переключатели прекрасны - в некоторых областях. Установка иерархии классов является служебной, который не всегда необходим для проблемы. Но чем больше кода в операторе выбора, тем более вероятно это, что, да, возможно, Вы должны двинуть более тяжелый подход.
Мой классический опыт является компилятором, который я записал для класса несколько лет назад. У моего соседа по комнате был тот же класс со мной, и мы приблизились к нему двумя совсем другими способами. Я проявил подход тяжелого OO, полный polymophism. Он проявил тяжелый-C подход, с помощью перечислений и объединений. Его код был ~1/2 мой мудрый LOC размер, его код был быстрее к компилятору и его коду работавший . Его код был гибок, потому что это не было сверхспроектировано. Это было ценным уроком для меня в разработке программного обеспечения.
"Это означает, что перечисления являются "злыми" в дизайне OO и должны быть устранены с полиморфизмом?"
Обычно.
конструкции переключателя/перечисления могут быть любой из многих полиморфных структур: состояние и Стратегия является двумя общими, которые чаще всего подходят.
Я думаю, что Перечисления полезны, когда значения известны & некоторые в числе.
кроме того, Перечисления называют константами в некотором роде.
Перечисления не имеют никакого другого состояния снабженным им (кроме значения его).
Полиморфизм был бы полезен, когда у Вас есть различные состояния условий (и условия требуют большего количества состояния, чем надежда в единственной переменной).