Когда выбирать стратегию вместо полиморфизма при рефакторинге оператора switch

Question

Можете ли вы дать мне конкретную причину, когда следует выбирать стратегию вместо полиморфизма и наоборот.

Большое спасибо!

Answer 1

Одним из важных критериев является то, будет ли полиморфизм создавать связь, которой избегает стратегия. Например, если реализация метода save () для дерева классов подразумевает использование низкоуровневых функций ввода-вывода, то при использовании полиморфизма дерево классов будет связано с системой ввода-вывода, тогда как оно не было т раньше. Однако, если вы используете шаблон стратегии, объекты стратегии будут служить «буфером» и не позволять дереву классов зависеть от ввода-вывода.

Answer 2

Вы запускаете приложение с нуля.

Следующим шагом является необработанный код с полиморфизмом.

В базовых случаях это может остаться таким - это не проблема.

Если вы хотите, чтобы ваше приложение было более гибким, подготовленным к изменениям, и вы планируете продолжить его разработку - пришло время искать некоторые шаблоны проектирования, стратегия - одна из тех, о которых вам следует подумать, когда полиморфизм дает некоторые неприятности.

---

Назначение стратегии:

Определите семейство алгоритмов, инкапсулируйте каждый и сделайте их взаимозаменяемыми. Стратегия позволяет алгоритму варьироваться независимо от клиентов, которые его используют.

---

Мотивация использования стратегии:

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

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

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

· Трудно добавлять новые алгоритмы и изменять существующие при разрыве строки является неотъемлемой частью клиента. Мы можем избежать этих проблем, определив классы, которые инкапсулируют разные алгоритмы разрыва строки. Алгоритм, который инкапсулирован таким образом, называется стратегия.

---

Последствия:

1. Семейства связанных алгоритмов. Иерархии классов Стратегии определяют семейство алгоритмов или поведений для повторного использования контекстов. Наследование может помочь исключить общие функциональные возможности алгоритмов.

2. Альтернатива подклассам. Наследование предлагает еще один способ поддержки различные алгоритмы или поведения. Вы можете создать подкласс класса Context непосредственно, чтобы дать ему другое поведение. Но это хард-провол в Context.It смешивает реализацию алгоритма с Context, делая Контекст сложнее понять, поддерживать и расширять. И ты не можешь варьироваться алгоритм динамически. Вы сталкиваетесь со многими родственными классами, чьи только Разница заключается в алгоритме или поведении, которое они используют. Инкапсуляция Алгоритм в отдельных классах Стратегии позволяет варьировать алгоритм независимо от контекста, облегчая переключение, понимание и продлить.

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