Подтвердить что ты не робот

Стратегия против политики и политика в отношении стратегии

Когда я впервые обнаружил шаблон стратегии, я был поражен, казалось бы, бесконечными возможностями, которые он мне предлагал и моими программами. Я мог бы лучше инкапсулировать поведение моих моделей и даже менять это поведение на лету. Но стратегия также может быть использована для предоставления признаков и полезной нагрузки для содержащего объекта - данных, которые были объявлены в суперклассе. Жизнь была прекрасна.

class MyMonsterAI   { float const see_radius_; virtual void attack () = 0; /* .. */ };
class ElveAI        { ElveAI() : see_radius_(150.0f) {} /* ... */ };
class CycloneAI     { CycloneAI() : see_radius_(50.0f) {} /* ... */ };
class Monster       { MyMonsterAI* ai_; };

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

class MyMonsterTrait { typedef typename ElveAI AI; };

template< class MonsterTrait >
class Monster : public MonsterTrait::AI
{
    void idle (void) { attack(); }
};

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

Мне интересно: где вы используете стратегии и политики? Где лучше всего подходят?

4b9b3361

Ответ 1

Политики в большинстве случаев устанавливаются во время компиляции, а стратегии устанавливаются во время выполнения. Кроме того, политики, как правило, являются концепцией С++ и применяются только к меньшинству других языков (например, D), тогда как шаблон стратегии доступен для многих (большинство?) Объектно-ориентированных языков и языков, которые рассматривают функции как граждан первого класса, такие как python.

Сказанное:

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

  • Стратегия определяется во время выполнения и фактически может быть изменена "на лету". Например, у вас может быть программное обеспечение, которое реализует другой пользовательский интерфейс и логику для Salesforce, чем для группы поддержки, но все они должны иметь дело с одной и той же информацией о клиенте и лицензировании, чтобы вместо двух отдельно поддерживаемых приложений у вас было просто одно приложение, при необходимости измените интерфейс.

-Adam