Rubyのデカップリング：委任と依存性注入

少し前に戻って、私がこの道を歩むきっかけとなった問題、PDFレポートから始めましょう。

私のクライアントは、さまざまな印刷可能なPDFレポートを生成する機能を要求しました。1つのレポートにはアカウントのすべての費用がリストされ、別のレポートには収益がリストされ、別のレポートには将来の利益が予測されます。

由緒あるprawnを使用しています これらのPDFを作成するためのgem。各レポートはPrawn::Documentからサブクラス化された独自のRubyオブジェクトです。 。

このようなもの：

class CostReport < Prawn::Document
  def initialize(...)
    ...
  end

  def render
    text "Cost Report"
    move_down 20
    ...
  end

ここまでは順調ですね。しかし、ここに問題があります。クライアントは、他のすべてのレポートの一部を含む「概要」レポートを望んでいます。 。

ソリューション1：依存性注入

前述のように、この種の問題に対する一般的な解決策の1つは、依存性注入を使用するようにコードをリファクタリングすることです。つまり、これらすべてのレポートでselfのメソッドを呼び出すのではなく 、代わりに、PDFドキュメントを引数として渡します。

これにより、次のようなものが得られます：

class CostReport < Prawn::Document
...
  def title(pdf = self)
    pdf.text "Cost Report"
    pdf.move_down 20
    ...
  end
end

これは機能しますが、ここにはいくらかのオーバーヘッドがあります。一つには、すべての描画方法でpdfを使用する必要があります。 引数、およびprawnへのすべての呼び出し 今、このpdfを通過する必要があります 引数。

依存性注入にはいくつかの利点があります。それは、システム内の分離されたコンポーネントに向かって私たちを押し進め、ユニットテストを容易にするためにモックまたはスタブを渡すことを可能にします。

ただし、このシナリオでは、これらのメリットのメリットを享受していません。私たちはすでに強く prawnに結合 APIなので、別のPDFライブラリに変更するには、ほぼ確実にコード全体を書き直す必要があります。

ここでもテストは大きな問題ではありません。私たちの場合、自動テストで生成されたPDFレポートをテストするのは面倒で、価値がないからです。

したがって、依存性注入は、必要な動作を提供するだけでなく、最小限のメリットで追加のオーバーヘッドをもたらします。別のオプションを見てみましょう。

ソリューション2：委任

Rubyの標準ライブラリはSimpleDelegatorを提供します デコレータパターンを実装する簡単な方法として。オブジェクトをコンストラクターに渡すと、デリゲーターへのメソッド呼び出しはすべてオブジェクトに転送されます。

SimpleDelegatorの使用 、prawnをラップアラウンドする基本レポートクラスを作成できます 。

class PrawnWrapper < SimpleDelegator
  def initialize(document: nil)
    document ||= Prawn::Document.new(...)
    super(document)
  end
end

次に、このクラスから継承するようにレポートを更新できます。レポートは、初期化子で作成されたデフォルトのドキュメントを使用して、以前と同じように機能します。 概要でこれを使用すると、魔法が起こります レポート：

class OverviewReport < PrawnWrapper
  ...
  def render
    sales = SaleReport.new(..., document: self)
    sales.sales_table
    costs = CostReport.new(..., document: self)
    costs.costs_pie_chart
    ...
  end
end

ここでSaleReport#sales_table およびCostReport#costs_pie_chart 変更はありませんが、prawnへの呼び出し （例：text(...) 、move_down 20 など）は現在、OverviewReportに転送されています SimpleDelegator経由 作成しました。

動作に関しては、基本的にSalesReportのように作成しました OverviewReportのサブクラスになりました 。私たちの場合、これはprawnへのすべての呼び出しを意味します のAPIは、SalesReport -> OverviewReport -> Prawn::Documentに移動します。 。

SimpleDelegatorの仕組み

SimpleDelegatorの方法 内部で機能するのは、基本的にRubyのmethod_missingを使用することです。 メソッド呼び出しを別のオブジェクトに転送する機能。

したがって、SimpleDelegator （またはそのサブクラス）はメソッド呼び出しを受け取ります。それがそのメソッドを実装しているなら、素晴らしいです。他のオブジェクトと同じように実行されます。 ただし 、そのメソッドが定義されていない場合は、method_missingにヒットします。 。 method_missing 次に、callを試みます コンストラクターに渡されたオブジェクトのそのメソッド。

簡単な例：

require 'simple_delegator'
class Thing
  def one
    'one'
  end
  def two
    'two'
  end
end

class ThingDecorator < SimpleDelegator
  def two
    'three!'
  end
end

ThingDecorator.new(Thing.new).one #=> "one"
ThingDecorator.new(Thing.new).two #=> "three!"

SimpleDelegatorをサブクラス化する 独自のThingDecorator ここのクラスでは、いくつかのメソッドを上書きして、他のメソッドをデフォルトのThingにフォールスルーさせることができます オブジェクト。

上記の簡単な例では、実際にはSimpleDelegatorは実行されません。 しかし、正義。このコードを見て、「Thingをサブクラス化しないでください」とよく言われるかもしれません。 同じ結果が得られますか？」

はい、そうです。ただし、主な違いは次のとおりです。SimpleDelegator 委任先のオブジェクトをコンストラクターの引数として受け取ります。これは、実行時にさまざまなオブジェクトを渡すことができることを意味します 。

これにより、呼び出しをprawnにリダイレクトできます。 上記のソリューション2のオブジェクト。単一のレポートを呼び出す場合、prawn 呼び出しは、コンストラクターで作成された新しいドキュメントに移動します。ただし、概要レポートではこれを変更して、prawnを呼び出すことができます。 そのに転送されます ドキュメント。