Большие Операторы переключения: Плохое ООП?

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

Лучший способ решить эту конкретную проблему: сериализация и протоколы чисто должны использовать IDL и сгенерировать код маршалинга с операторами переключения. Поскольку безотносительно шаблонов (опытная фабрика, шаблон "команда" и т.д.), который Вы пытаетесь использовать иначе, необходимо будет инициализировать отображение между идентификатором/строкой команды и классом/указателем функции, так или иначе и это 'll работает медленнее, чем операторы переключения, так как компилятор может использовать идеальный поиск хеша для операторов переключения.

Можно использовать словарь (или хешировать карту, если Вы кодируете в Java) (это назвало табличную разработку Steve McConnell).

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

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

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

Существует две вещи, которые приходят на ум при разговоре о большом операторе переключения:

1. Это нарушает OCP - Вы могли непрерывно поддерживать большую функцию.
2. у Вас могла быть плохая производительность: O (n).

, С другой стороны, реализация Map может соответствовать OCP и могла работать с потенциально O (1).

Я вижу стратегическую модель. Если у меня есть 100 различных стратегий... пусть будет так. Гигантский оператор переключения ужасен. Являются все Команды допустимыми именами классов? Если так, просто используйте названия команды в качестве имен классов и создайте объект стратегии с Активатором. CreateInstance.

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

команда может быть одной из 100 различных команд

, Если необходимо сделать один из 100 разных вещей, Вы не можете постараться не иметь ответвление с 100 путями. Можно закодировать его в потоке управления (переключатель, if-elseif^100) или в данных (карта с 100 элементами от строки до команды/фабрики/стратегии). Но это будет там.

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

Я вижу наличие два операторы переключения как признак дизайна неOO, где switch-on-enum-type мог бы быть заменен несколькими типами, которые обеспечивают различные реализации абстрактного интерфейса; например, следующее...

switch (eFoo)
{
case Foo.This:
  eatThis();
  break;
case Foo.That:
  eatThat();
  break;
}

switch (eFoo)
{
case Foo.This:
  drinkThis();
  break;
case Foo.That:
  drinkThat();
  break;
}

... должен, возможно, быть переписан к как...

IAbstract
{
  void eat();
  void drink();
}

class This : IAbstract
{
  void eat() { ... }
  void drink() { ... }
}

class That : IAbstract
{
  void eat() { ... }
  void drink() { ... }
}

Однако один оператор переключения не imo такой сильный индикатор, что оператор переключения должен быть заменен чем-то еще.

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

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

, Конечно, полностью диспетчер команды OOP (на основе волшебства, такого как отражение или механизмы как Активация Java) более красив, но иногда Вы просто хотите починить вещи и получить сделанную работу ;)