👋🏾 👩🏼‍💻 🏞️ データコンテキストインタラクション（DCI）-オブジェクト指向のパラダイムの進化 📻 ⬆️ 🤵🏼

多くの場合、「DCI」という略語が西洋のブログやTwitterでちらつきます。ハブにはこのトピックに関する情報がほとんどなく、 Ruby NoName Podcast S04E09でこれだけが言及されているという事実に驚きました。好奇心が持ち上がり、私はこの神秘的な言葉についてもっと学ぶことにしました。検索の過程で、同胞のビクター・サヴキンによって英語で書かれた良い記事に出会いました。豊富な理論のないこの記事は、実用的な例で、DCIとは何かを示しています。さらに、物語はビクターに代わって行きます。

オブジェクト指向の利点

従来のオブジェクト指向プログラミングの価値が証明されている問題のレビューから始めましょう。

オブジェクト指向プログラミングは、オブジェクトの状態管理に優れていることが証明されています。クラス、フィールド、およびプロパティは、状態を定義して操作できる強力なツールです。状態を表示するこれらの手段がプログラミング言語に組み込まれているため、コンパイル中と実行中の両方で状態について結論を出すことができます。コンパイル中にクラスオブジェクトの定義を確認し、実行時にそのフィールドについてオブジェクトをポーリングできます。

すべてのオブジェクト指向言語によって非常によく解決される別の問題は、オブジェクトの状態に関連する操作の表示です。このような操作は、いかなる種類のコラボレーションにも関与しません。彼らは所有者にローカルです。クラスメソッドを定義することにより、ローカル操作を表現します。クラスでメソッドを定義してインスタンス化すると、このメソッドを持つことがわかります。これはかなり明白です。

ローカル操作のみを持つオブジェクトの良い例として、Ruby Stringクラスを使用できます。各文字列には、バイトまたは文字の配列があります。すべての操作はこの配列で機能します。このオブジェクトは独立しています-他のオブジェクトと対話する必要はありません。誰もがStringの使い方を理解できるとは思わない。このような問題を解決するために、OO言語が構築されました。

オブジェクト指向の欠点

オブジェクト指向は、オブジェクトの相互作用を表示することで失われます。意味を示すために、同じグループのオブジェクトが相互作用する2つのシステム操作（2つの使用シナリオ）を見てみましょう。

最初の使用例

この図は、互いに通信する4つのオブジェクトのシステム操作を示しています。

第二のユースケース

そして、ここでは別の使用シナリオ、同じオブジェクトのグループを使用する別のシステム操作が示されています。しかし、ご覧のとおり、オブジェクトとメッセージ間の相互作用のモデルはすでに異なっています。

コードはシステム操作を表示しません

ユースケース1とユースケース2で表される2つのシステム操作を見ました。コードでどのように表示しますか？理想的なケースでは、1つのファイルを開いて、作業中のユースケースのオブジェクトの相互作用のモデルを理解できるようにしたいと思います。 ユースケース1に取り組んでいる場合、 ユースケース2について何も知りたくありません。これは、コードでのユースケースの成功した表示であると考えるものです。

残念ながら、従来のオブジェクト指向プログラミングでは、これを行う機会はありません。オブジェクトの状態を表示し、ローカル動作を割り当てるツールを提供します。しかし、ユースケースを実行するために、実行時のオブジェクト同士の相互作用を記述する良い方法はありません。したがって、システム操作はコードに表示されません。

ソースコード！=ランタイム

最終的に、コードを記述し、何らかの方法でシステム操作をプログラミングします。これをどうやってやるの？それらを多くの小さなメソッドに分割し、それらをさまざまなオブジェクトに割り当てます。

ここでは、すべてのユースケースに必要なすべてのメソッドがこれらのオブジェクトにクランプされていることがわかります。最初のシナリオを実行するメソッドは緑色で強調表示され、2番目のシナリオは赤色で強調表示されます。さらに、これらのオブジェクトにはいくつかのローカルメソッドがあります。それらは青と赤の方法で使用されます。

図に示されている問題は、ソースコードがランタイムで何が起こっているかを表示しないことです。ソースコードは、4つの個別のオブジェクトについて、それぞれに多数のメソッドが含まれていることを示しています。 Rantheimは、相互に通信する4つのオブジェクトがあり、これらのメソッドのごく一部のみがこのユースケースに関連していることを示しています。この矛盾により、プログラムの理解が複雑になります。ソースコードは1つのストーリーを示し、ランタイムはまったく異なるストーリーを示します。

また、システム操作（使用シナリオ）を明示的に定義する方法がないため、すべてのメソッド呼び出しを追跡して、プログラムで何が起こっているのかを把握する必要があります。このユースケースを理解するために開くことができるファイルがありません。さらに悪いことに、すべてのクラスには多数の使用シナリオのメソッドが含まれているため、必要なメソッドをフィルターで除外するのに多くの時間を費やす必要があります。

DCIが助けになります！

DCI（データ、コンテキスト、相互作用）は、これらの問題を解決するためにTrygve Reenskaug（MVCテンプレートの作成者）によって作成されたパラダイムです。

最初のユースケース（DCI）

DCIスタイルで表現された最初のユースケースを見てみましょう。

ここでは、このユースケースから、データとローカルメソッドのみを含むシステムの不変部分を分離しています。従来のオブジェクト指向のテクニックはすべて、この不変部分をモデル化するために使用できます。特に、集約やリポジトリなどのドメイン駆動型の設計手法を使用することをお勧めしますが、状況依存の動作や相互作用はなく、ローカルな方法しかありません。

相互作用をどのようにモデル化するのですか？

相互作用-コンテキストを記述するための新しい抽象化が利用可能になりました。コンテキストは、特定のユースケースのすべてのロールを含むクラスです。各役割は、相互作用における同僚を表し、特定のオブジェクトによって演じられます。ご覧のとおり、状況依存の動作は役割に集中しています。コンテキストは、オブジェクトにロールを割り当ててから対話を開始するだけです。

セカンドユースケース（DCI）

オブジェクト（オブジェクトAD）は同じままです。 2番目のユースケースでは、メソッドを追加する必要はありません。提示されているすべての方法は、基本的で、自給自足で、ローカルです。個々の動作を使用するためのすべてのシナリオは、コンテキストとロールで強調されました。

また、赤と緑のメソッドが同時に表示されないことも注目に値します。各コンテキストには、その実行に必要なメソッドのみが含まれています。

これはあまりにも抽象的に聞こえるかもしれませんので、Rubyのサンプルコードを見てみましょう。

コード例

DCI専用のHello Worldの例を次に示します。 DCIに関心がある人は誰でも、ある口座から別の口座への送金から始まります。

この例はあまりにも単純すぎて、非常に単純なので、サービス、通常のエンティティ、または関数を使ってうまく表現できることを理解しています。したがって、コードをどのように構成する必要があるかを示す例として、この例を見てください。

あるアカウントから別のアカウントへの送金について話しているため、何らかの方法でアカウント情報を保存する必要があります。 Accountクラスがこれを担当します。残高とトランザクションのリストに関する情報を保存します。

class Account def decrease_balance(amount); end def increase_balance(amount); end def balance; end def update_log(message, amount); end def self.find(id); end end

ご覧のとおり、ここのすべてのメソッドはローカルであり、コンテキストに依存しません。アカウントは送金について何も知りません。彼はバランスを補充し、彼からお金を読むことだけに責任があります。送金のロジックは次のコンテキストにあります。

 class TransferringMoney include Context def self.transfer source_account_id, destination_account_id, amount source = Account.find(source_account_id) destination = Account.find(destination_account_id) TransferringMoney.new(source, destination).transfer amount end attr_reader :source_account, :destination_account def initialize source_account, destination_account @source_account = source_account.extend SourceAccount @destination_account = destination_account.extend DestinationAccount end def transfer amount in_context do source_account.transfer_out amount end end ... end

データベースに2つのアカウントを要求し、コンテキストのインスタンスを作成して、転送メソッドを呼び出します。おそらく、2つのアカウントをコンストラクターに渡し、転送額を転送メソッドに渡すことに気づいたでしょう。これにより、どのオブジェクトがこのインタラクションのアクターであり、どのデータのみであるかを示したいと思います。アカウントはアクターであり、振る舞いがあり、転送量はすでにデータです。

次に、コンストラクターでアカウントオブジェクトにロールを割り当てます。これらのデータオブジェクトをソースアカウントと受信者アカウントになるようにトレーニングします。

最後に、ソースアカウントでtransef_outメソッドを呼び出して対話を開始します。この例では、コンテキストはインタラクションのみを開始しますが、一部の複雑なケースでは、アクターを調整することもできます。

それでは、ロールの実装を見てみましょう。

 class TransferringMoney include Context ... def transfer amount ... end module SourceAccount include ContextAccssor def transfer_out amount raise "Insufficient funds" if balance < amount decrease_balance amount context.destination_account.transfer_in amount update_log "Transferred out", amount end end module DestinationAccount include ContextAccssor def transfer_in amount increase_balance amount update_log "Transferred in", amount end end end

まず、ソースアカウントに十分なお金があることを確認し、残高から振替金額を差し引きます。その後、お金を受け取るように伝えるために、コンテキスト変数を介して受信者アカウントを呼び出します。

いくつかの興味深いことに注意してください。

不変の動作とコンテキスト依存の分離。アカウントクラスは、そのデータの操作方法のみを知っています。すべてのチェック、コンテキスト内のすべてのビジネスロジック。
ロールは、コンテキスト変数を介して他の同僚にアクセスします。繰り返しますが、これはアクターをデータから分離するために行われます。すべてを引数として渡した場合、どのようにして俳優が誰で、誰がそうでないかを知ることができますか？このため、コンテキスト変数を通じてアクターを参照し、すべてのデータオブジェクトを引数として渡す必要があります。

コンテキストと両方の役割：

 class TransferringMoney include Context def self.transfer source_account_id, destination_account_id, amount source = Account.find(source_account_id) destination = Account.find(destination_account_id) TransferringMoney.new(source, destination).transfer amount end attr_reader :source_account, :destination_account def initialize source_account, destination_account @source_account = source_account.extend SourceAccount @destination_account = destination_account.extend DestinationAccount end def transfer amount in_context do source_account.transfer_out amount end end module SourceAccount include ContextAccssor def transfer_out amount raise "Insufficient funds" if balance < amount decrease_balance amount context.destination_account.transfer_in amount update_log "Transferred out", amount end end module DestinationAccount include ContextAccssor def transfer_in amount increase_balance amount update_log "Transferred in", amount end end end

何がありますか

局所性

DCIは、アルゴリズムが多くの異なるファイルに分散している場合、従来のオブジェクト指向プログラミングの問題を解決します。ユースケースの実装方法を知りたい場合は、1つのファイルを開くだけで済みます。

フォーカス

コンテキストには、それが表す実行スクリプトの一部であるメソッドのみが含まれます。そのため、作業中の問題に関係のない数十または数百のメソッドをスキャンする必要はありません。

「システムとは」および「システムとは」

すべてのデータオブジェクトとそのローカルメソッドは、「システムとは何か」を表しています。通常、システムのこの部分は変更されていません。状況依存のペースの速い動作は、「システムの機能」です。変化のない部品を急速に変化する部品から分離することは、安定したソフトウェアを構築するための必要条件の1つです。 DCIはこの分離を提供します。

DCIのデータは、オブジェクトの内容に関するすべてを示し、その近隣については何も示しません（「システムとは何か」）
DCIのコンテキストは、相互作用するオブジェクトのネットワークに関するすべてを示し、そのコンテンツについては何も示しません（「システムの動作」）

ソースコード== Rantaim

また、ソースコードはランタイムと一致します。 Rantimeは、2つのアカウントと振替額があることを示しています。これは、コンテキストを開くと表示されます。

明示的な役割

DCIの主な利点は、明示的な役割です。多くのデザイナーは、オブジェクト自体には責任がないことに同意します。これは多くの役割です。たとえば、オブジェクトの例として私を取り上げます。私は次の特性を持っています：私はロシアで生まれました、私の名前はビクターです、私の体重は約65kgです。これらのプロパティは、実際にいくつかの高度なコミットメントを表現できますか？できません。しかし、私が家に帰って夫の役割を果たし始めると、私はすべての結婚関係の問題に責任を持つようになります。したがって、オブジェクトが役割を果たします。ロールが従来のオブジェクト指向プログラミングの最前線にないという事実は間違っています。

ソース

実際には記事自体：

データコンテキストインタラクション：オブジェクト指向パラダイムの進化

このアイデアに興味がある場合は、次のリソースをご覧になることをお勧めします。

あなたが本を読むことを好むなら、私はあなたにこれらの3つの本を推薦することができます：

ジムゲイによるクリーンルビー。この本は、ルビーの実用的なDCIプレゼンテーションの必要性を満たします。彼女はまだ開発中ですが、すでに有望に見えます。
リーンアーキテクチャ：アジャイルソフトウェア開発のためのJames O. CoplienとGertrudBjørnvigによる。これは、整然としたアーキテクチャとアジャイル開発の市場での最初の本であるだけでなく、これら2つの強力なアプローチの違いを説明し、それらをどのように組み合わせることができるかを示しています。また、これはDCIと呼ばれるTrygve Reenskaugの新しいソフトウェアアーキテクチャを特集した最初の本です。データ、コンテキスト、相互作用。
オブジェクトデザイン：役割、責任、およびコラボレーション（Rebecca Wirfs-BrockおよびAlan McKeanによる）。この本は2002年にリリースされたため、DCIに関する情報は含まれていません。ただし、オブジェクトの設計、役割の使用、同僚のモデリングに関する優れた資料が含まれています。これらのトピックは、DCIの中心的な考え方に非常に近いものです。

データコンテキストインタラクション（DCI）-オブジェクト指向のパラダイムの進化