Избежать случая переключения для чистых причин кодирования? [Дубликат]

Я не покупаю его. Кажется, что у этих фанатиков ООП есть машины, у которых есть бесконечная оперативная память и потрясающая производительность. Очевидно, что при использовании inifinite RAM вам не нужно беспокоиться о фрагментации ОЗУ и о влиянии производительности, которое возникает при непрерывном создании и уничтожении небольших вспомогательных классов. Перефразируя цитату из книги «Красивый код» - «Каждая проблема в информатике может быть решена с еще одним уровнем абстракции»

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

Я помещал сообщения в массив, а затем сопоставлял элемент с ключом решения, чтобы отобразить сообщение.

На ум приходит Strategy .

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

В этом случае «семейство алгоритмов» - это ваши разные действия.

---

Что касается операторов switch - в «Чистом коде» Роберт Мартин говорит, что он пытается ограничить себя одним оператором switch для каждого типа. Не исключать их вообще.

Причина в том, что операторы switch не придерживаются OCP .

С точки зрения дизайна вы можете использовать Command Pattern для данного сценария. (См. http://en.wikipedia.org/wiki/Command_pattern ).

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

Для получения дополнительной информации о том, как вы удаляете эти инструкции switch и вводите соответствующие подклассы, я рекомендую вам прочитать первую главу «Рефакторинг» Мартином Фаулер. Или вы можете найти похожие слайды здесь http://www1.informatik.uni-wuerzburg.de/database/courses/pi2_ss03_dir/RefactoringExampleSlides.pdf . (Слайд 44)

Операторы «Bad» switch часто включают тип объекта (или что-то, что может быть типом объекта в другом проекте). Другими словами, жестко кодировать то, что может быть лучше обработано полиморфизмом. Другие типы операторов switch могут быть в порядке

Вам понадобится оператор switch, но только один. Когда вы получите сообщение, вызовите объект Factory для возврата объекта соответствующего подкласса Message (Move, Attack и т. Д.), Затем вызовите метод message-> doit () для выполнения работы.

означает, что если вы добавляете больше типов сообщений, необходимо изменить только заводский объект.

Использовать команды. Оберните действие в объект и пусть полиморфизм сделает для вас переключатель. В C ++ (shared_ptr - это просто указатель или ссылка на языке Java. Это позволяет динамическую отправку):

void GameServer::perform_action(shared_ptr<Action> op) {
    op->execute();
}

Клиенты выбирают действие для выполнения, и как только они отправляют это действие на сервер, поэтому серверу не нужно выполнять синтаксический анализ:

void BlueClient::play() {
    shared_ptr<Action> a;
    if( should_move() ) a = new Move(this, NORTHWEST);
    else if( should_attack() ) a = new Attack(this, EAST);
    else a = Wait(this);
    server.perform_action(a);
}

Операторы IMO switch не являются bad , но их следует избегать, если это возможно. Одним из решений было бы использовать Map, где ключи являются командами, а значения Command - объектами с помощью метода execute(). Или List, если ваши команды являются числовыми и не имеют пробелов.

Однако, как правило, вы должны использовать switch заявления при реализации шаблонов проектирования; одним примером может быть использование шаблона цепочки ответственности для обработки команд, заданных любой командой «id» или «value». (Был также отмечен шаблон Strategy .) Однако в вашем случае вы также можете изучить шаблон Command .

В основном, в OOP, вы попытаетесь использовать другие решения, чем полагаться на блоки switch, которые используют парадигму процедурного программирования. Однако, когда и как использовать это - это ваше решение. Я лично часто использую блоки switch при использовании шаблона Factory и т. Д.

Определение организации кода:

• a пакет представляет собой группу классов с когерентным API (ex: Collection API во многих фреймах)
• класс представляет собой набор когерентных функциональных возможностей (например: класс Math ...
• метод является функциональностью a , он должен делать только одно и только одно. (например: добавление элемента в список может потребовать, чтобы увеличить указанный список, и в этом случае add метод будет полагаться на другие методы для этого и не будет выполнять эту операцию сам, потому что это не контракт).

Поэтому, если ваш оператор switch выполняет различные операции, вы « нарушает » это определение, тогда как использование шаблона проектирования не соответствует каждой операции в собственном классе (это собственный набор функциональных возможностей).