それが戦略戦略デザインパターン

をやっているときだ。 プロジェクトしかし、車輪の再発明は避けたいものだ。ある問題に対する解決策が効果的であることが証明されている場合、それを再利用すれば、膨大な時間といくつかの頭痛の種を節約することができる。システム・アーキテクチャのジレンマの場合、私たちは設計プロセスを容易にするためにいくつかのパターンを開発しました。

デザインパターンとは何か？

デザイン・パターンとは、さまざまな文脈におけるデザイン上の問題を解決するのに役立つ概念的なモデルである。デザイン・パターンは、デザイン・パターンの構造化に適用できる、再利用可能なテンプレートのようなものです。 コード.つまり、デザインパターンは十分に文書化され、実証されており、一般的に知られているということだ。言い換えれば、適切なデザイン・パターンを使えば、他のデザイン・パターン・インサイダー（あなたの同僚のこと）があなたのアイデアをスムーズに理解できるようになるということだ。

学びたいですか？ストラテジー・デザイン・パターンの登場だ。

戦略デザインパターン：

• はアルゴリズムのファミリーを定義する、

• は、それぞれのアルゴリズムを別個のものとして実装している、

• によって、それぞれのアルゴリズムが、与えられた文脈の中で互換性を持って使われるようになる。

実例は？認証

私たちのアプリの1つでは、リクエストを認証するためのいくつかの戦略を実装している。クッキー、JWTトークン、APIキーによる認証を許可している。私にはアルゴリズムのファミリーのように聞こえる。

実装例を見てみよう。

認証アルゴリズム・ファミリーは、3つの別々のクラスに分かれている。それぞれのクラスは、具体的な動作を定義している：

モジュール AuthenticationStrategies
  クラス CookiesAuthentication
    def self.authenticate_request(リクエスト)
      puts "クッキー認証アルゴリズムを実装します"
    終了
  終わり

クラス JWTAuthentication
    def self.authenticate_request(リクエスト)
      puts "jwt認証アルゴリズムを実装します"
    終了
  終了

クラス ApiKeyAuthentication
    def self.authenticate_request(リクエスト)
      puts "私はapiキー認証アルゴリズムを実装しています"
    end
  end
end

次に、コンテキスト／クライアント・クラスがある：

クラス Authentication
  def self.authenticate(authentication_strategy, request)
    authentication_strategy.authenticate_request(リクエスト)
  終了
終了

request = "リクエストのふりをする"

Authentication.authenticate(AuthenticationStrategies::CookiesAuthentication, request)
Authentication.authenticate(AuthenticationStrategies::JWTAuthentication, request)
Authentication.authenticate(AuthenticationStrategies::ApiKeyAuthentication, request)

上のスクリプトはこう出力する：

クッキー認証アルゴリズムを実装する jwt認証アルゴリズムを実装する APIキー認証アルゴリズムを実装する

まとめ

• デザインパターンは、アーキテクチャ上の問題を解決するための便利なツールである、

• デザインパターンの知識は、他の開発者とのシステムアーキテクチャに関するコミュニケーションを向上させます、

• ストラテジー・デザイン・パターンは、特定のコンテキストで交換可能に使えるアルゴリズムがたくさんある場合に適している。