Большие операторы Switch: Bad OOP?

Question

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

Сейчас я нахожусь в ситуации, в которой есть чудовищный оператор переключения, основанный на потоке данных из сокета TCP, в котором протокол состоит в основном из завершающей команды перевода строки, за которой следуют строки данных, за которыми следует маркер конца. Команда может быть одной из 100 различных команд, поэтому я хотел бы найти способ уменьшить этот оператор переключения монстров до чего-то более управляемого.

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

Есть ли какие-либо шаблоны для такого рода проблем? Любые предложения о возможных реализациях?

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

Однако это также имеет проблему взрыва типа. Теперь мне нужно 100 новых классов, плюс я должен найти способ аккуратно связать их с моделью данных. Является ли «один истинный оператор переключения» действительно правильным выбором?

Буду признателен за ваши мысли, мнения или комментарии.

Answer 1

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

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

Answer 2

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

Answer 3

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

Answer 4

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