ソフトウェアオブジェクト間で制御を転送する方法
ソフトウェアオブジェクトは、OOPの通常のクラスです。 ソフトウェアオブジェクトの相互作用とは、あるクラスから別のクラスに制御を移すことを意味します。
これを行うには2つの方法があります。 さらに、それらをオブジェクトとイベントと呼びます。 名前はオブジェクトイベントパラダイムから取られます。これは、ある種のイベントをトリガーおよび処理するオブジェクトの存在を意味します。 しかし、私の場合、意味は異なります。 また、混乱しないように、制御がマネージャーに転送される最初のクラスを呼び出し、 executorによってそれぞれ制御を取得する2番目のクラスを呼び出します。
私はC＃言語と.NET Frameworkの操作に慣れているので、例と説明でそれらを使用します。 C＃では、イベントメカニズムはデリゲート（事前定義されたインターフェースを持つメソッドへのポインター）を介して実装されることをすぐに言っておく価値があります。 同じ目的で、CommandまたはObserverパターンが適しています。 実装には違いがありますが、意味は同じです。 両方とも1つのタスクを実行します。未知のサブスクライバーのイベントについて通知します。
オブジェクトの一方だけが他方について知っている状況を考えます。 バリアントはまだ可能です-両方ともお互いについて知っている（クラスの強いつながり）、または誰も誰も知らない（普遍性、Facadeパターンの適用など）。
オブジェクトメソッドとは、1つのクラス（エグゼキューター）がインターフェイスを通じて何らかのメソッドを提供することを意味します。 executorインスタンスへのリンクを持つ2番目（マネージャー）は、このメソッドを呼び出すことができます。 この場合、制御は最初のオブジェクトから2番目のオブジェクトに移されます。 C＃の例を次に示します（C ++を知っている人は、Javaも理解すると思います）。
ご覧のとおり、Workerクラスは、誰がそれを動作させ、誰に属しているかについては何も知りません。 一方、ボスは、どのような種類の労働者に従属しているのか、何人の労働者がどのような仕事をするのかをよく知っています。 要約すると、マネージャークラス（ボス）はエグゼキュータークラス（ワーカー）のインターフェイスを知っていますが、その逆はありません。 マネージャーはパフォーマーの数を知っている必要があります。
イベントベースのコントロール転送方法の動作は少し異なります。 1つのクラスは、そのインターフェイスを介して、何らかのイベントをトリガーできることを通知します。 これを知っている別のクラスは、これらのイベントをサブスクライブし、発生した場合は処理できます。
現在、Bossクラスは、誰がコマンドを実行するかについて何も知らず、単にイベント「projectStarted」を宣言します。 仕事をしたい人（労働者クラス）は、彼らが誰のために働いているかを正確に知っています。 ワーカーの特定のインスタンスは、ボスの特定のインスタンスのコマンドでのみジョブを実行します。 オブジェクトのアプローチとは対照的に、 エグゼキューターはマネージャーのインターフェースを知っており、マネージャーはエグゼキューターとその番号について何も知りません。
Model-View-Controllerを実装するときに、適切なアプローチを適用する問題が発生しました。 制御はコントローラーからビューに移され、誰が誰について知る必要があるかを決定する必要がありました：ビューについてのコントローラーまたはコントローラーについてのビュー？
まず、これが他の人によってどのように実装されているかを見てみましょう。 たとえば、Buttonなど、WinFormsライブラリからUIコントロールを取得してみましょう（他のUIフレームワークの支持者はご容赦ください）。
ボタンについて考えるときに最初に思い浮かぶのは、Click（）イベントです。 ほとんどの場合、クリックを処理するために使用します。 イベントアプローチでは、イベントはマネージャーによってトリガーされます。 したがって、コントロールを転送する必要がある場合、WinFormsのボタンはコントロールです。 次に、そのメソッド、たとえばTitleプロパティを見てみましょう。 これは、アプリケーションの実行中にボタンに表示される碑文に責任があります。 このボタンは、そのインターフェイスを介して自分自身で作業するためのメソッドを提供するため、アーティストの役割を果たします。 ボタン、パフォーマー、マネージャーはどうですか？ どうして？ さらに、ボタンはそれに応じて呼び出されます-UIコントロール。 一方では、それはUIです、すなわち 一方、パフォーマンスビューはContol、つまり コントローラーマネージャー。
ボタンクラスを設計するとき、1つの問題があります。ボタンがコントロールを送信できる場所と取得できる場所がわからないということです。 ただし、動作を実装する必要があります。 明らかな結論を定式化しますが、それでもシステム設計の性質をよりよく理解できます。 未知に制御を渡し、イベントメカニズムを使用し、未知から制御を受け取り、オブジェクトメカニズムを使用します。
より良い知覚のための画像：
しかし、この証拠は「不明」にのみ適用されます。 しかし、両方の部分を設計し、サスペンスがない場合はどうでしょうか？ 未知のものを考え出さなければなりません。 しかし、どのアプローチを選択するのでしょうか？ 私は誰でも結論に達しました。 それはすべて、私たちにとって主要な設計を開始する場所に依存します。
ビューとコントローラーについての話に戻ります。 たとえば、統計情報をグラフ形式で画面に表示するシステムを作成します。 主要なのは、美しいグラフを描くことです。つまり、 主役。 さらに、統計自体は私たちにとって重要ではないと想像し（実際、これは完全に間違っている可能性があります）、制御が未知のものから転送されると想像します。 したがって、オブジェクトアプローチを使用します。Viewのグラフを描画する方法を説明し、ViewへのリンクをControllerに渡し、適切な場所でControllerからメソッドを呼び出します。
別の状況-統計（マネージャー）は私たちにとって重要であり、それがどのように提示されるかはすでに二次的です。 さて、私たちにとって、未知は統計の表示方法です。 イベントアプローチを適用します。 イベントについて説明し、適切な場所で開始します。 現在、私たちにとっては、誰がどのように処理するかは問題ではありません。 チャート描画モジュール自体は、必要なイベントをサブスクライブします。
前者の場合、統計だけでなく運用データなど、さまざまなタイプの情報のグラフを呼び出す方が便利です。 つまり 1つのビューに異なるコントローラーを使用するのは簡単です。 反対に、2番目の方法では、美しいグラフの形と、値のクラウドの形、およびその他の方法の両方で統計情報を（同時に）描画できます。 つまり、1つのコントローラーに対して複数のビューを簡単に定義できます。
どういうわけか、アプリケーションのさまざまな部分の相互作用を実装しました。 その瞬間、私はこのトピックについてそれほど深く考えず、その時私に思われた最も簡単なことをし、そして再び最も簡単なことをしました。 その結果、設計が混在することが判明しました。 ControllerとViewはお互いを知っていました-どこかでコントローラーがプレゼンテーションメソッドを呼び出し、どこかでViewがイベントをサブスクライブしました。 これは私が警告したいことです。 なぜなら、それは互いに関するオブジェクトの相互知識につながり、結果として：
この段階で開発されたシステムは非常に単純なので、最初の問題はまだ発生していません。 2つ目はまだ感じていません。 しかし、これは彼らが将来にいなくなることを意味するものではありません。 しかし、チームへの新しい人の出現で、3番目のものは困難さえもたらしました。 このため、知識を構造化し、すべてを統一された用語で説明する必要がありました。
これらのパターンおよびその他のパターンについては、「オブジェクト指向設計の受容」という本に記載されています。 デザインパターン」E.ガンマ、R。ヘルム、R。ジョンソン、J。ヴリスサイドによる。 UMLについては、書籍「UML。 ユーザーガイド」Grady Butch、James Rambo、Aivar Jacobson。
これを行うには2つの方法があります。 さらに、それらをオブジェクトとイベントと呼びます。 名前はオブジェクトイベントパラダイムから取られます。これは、ある種のイベントをトリガーおよび処理するオブジェクトの存在を意味します。 しかし、私の場合、意味は異なります。 また、混乱しないように、制御がマネージャーに転送される最初のクラスを呼び出し、 executorによってそれぞれ制御を取得する2番目のクラスを呼び出します。
私はC＃言語と.NET Frameworkの操作に慣れているので、例と説明でそれらを使用します。 C＃では、イベントメカニズムはデリゲート（事前定義されたインターフェースを持つメソッドへのポインター）を介して実装されることをすぐに言っておく価値があります。 同じ目的で、CommandまたはObserverパターンが適しています。 実装には違いがありますが、意味は同じです。 両方とも1つのタスクを実行します。未知のサブスクライバーのイベントについて通知します。
オブジェクトの一方だけが他方について知っている状況を考えます。 バリアントはまだ可能です-両方ともお互いについて知っている（クラスの強いつながり）、または誰も誰も知らない（普遍性、Facadeパターンの適用など）。
説明
オブジェクトメソッドとは、1つのクラス（エグゼキューター）がインターフェイスを通じて何らかのメソッドを提供することを意味します。 executorインスタンスへのリンクを持つ2番目（マネージャー）は、このメソッドを呼び出すことができます。 この場合、制御は最初のオブジェクトから2番目のオブジェクトに移されます。 C＃の例を次に示します（C ++を知っている人は、Javaも理解すると思います）。
//
class Worker {
public void doWork() {
//....
}
}
//
class Boss {
Worker worker1 = new Worker();
Worker worker2 = new Worker();
public void startProject() {
worker1.doWork();
worker2.doWork();
}
}
ご覧のとおり、Workerクラスは、誰がそれを動作させ、誰に属しているかについては何も知りません。 一方、ボスは、どのような種類の労働者に従属しているのか、何人の労働者がどのような仕事をするのかをよく知っています。 要約すると、マネージャークラス（ボス）はエグゼキュータークラス（ワーカー）のインターフェイスを知っていますが、その逆はありません。 マネージャーはパフォーマーの数を知っている必要があります。
イベントベースのコントロール転送方法の動作は少し異なります。 1つのクラスは、そのインターフェイスを介して、何らかのイベントをトリガーできることを通知します。 これを知っている別のクラスは、これらのイベントをサブスクライブし、発生した場合は処理できます。
//
class Worker {
public Worker(Boss boss) {
boss.projectStarted += new EventHandler(doWork);
}
private void doWork(object sender, EventArgs e) {
//....
}
}
//
class Boss {
public event EventHandler projectStarted;
public void startProject() {
if (projectStarted != null)
projectStarted.Invoke(this, new EventArgs());
}
}
現在、Bossクラスは、誰がコマンドを実行するかについて何も知らず、単にイベント「projectStarted」を宣言します。 仕事をしたい人（労働者クラス）は、彼らが誰のために働いているかを正確に知っています。 ワーカーの特定のインスタンスは、ボスの特定のインスタンスのコマンドでのみジョブを実行します。 オブジェクトのアプローチとは対照的に、 エグゼキューターはマネージャーのインターフェースを知っており、マネージャーはエグゼキューターとその番号について何も知りません。
申込み
Model-View-Controllerを実装するときに、適切なアプローチを適用する問題が発生しました。 制御はコントローラーからビューに移され、誰が誰について知る必要があるかを決定する必要がありました：ビューについてのコントローラーまたはコントローラーについてのビュー？
まず、これが他の人によってどのように実装されているかを見てみましょう。 たとえば、Buttonなど、WinFormsライブラリからUIコントロールを取得してみましょう（他のUIフレームワークの支持者はご容赦ください）。
ボタンについて考えるときに最初に思い浮かぶのは、Click（）イベントです。 ほとんどの場合、クリックを処理するために使用します。 イベントアプローチでは、イベントはマネージャーによってトリガーされます。 したがって、コントロールを転送する必要がある場合、WinFormsのボタンはコントロールです。 次に、そのメソッド、たとえばTitleプロパティを見てみましょう。 これは、アプリケーションの実行中にボタンに表示される碑文に責任があります。 このボタンは、そのインターフェイスを介して自分自身で作業するためのメソッドを提供するため、アーティストの役割を果たします。 ボタン、パフォーマー、マネージャーはどうですか？ どうして？ さらに、ボタンはそれに応じて呼び出されます-UIコントロール。 一方では、それはUIです、すなわち 一方、パフォーマンスビューはContol、つまり コントローラーマネージャー。
ボタンクラスを設計するとき、1つの問題があります。ボタンがコントロールを送信できる場所と取得できる場所がわからないということです。 ただし、動作を実装する必要があります。 明らかな結論を定式化しますが、それでもシステム設計の性質をよりよく理解できます。 未知に制御を渡し、イベントメカニズムを使用し、未知から制御を受け取り、オブジェクトメカニズムを使用します。
より良い知覚のための画像：
しかし、この証拠は「不明」にのみ適用されます。 しかし、両方の部分を設計し、サスペンスがない場合はどうでしょうか？ 未知のものを考え出さなければなりません。 しかし、どのアプローチを選択するのでしょうか？ 私は誰でも結論に達しました。 それはすべて、私たちにとって主要な設計を開始する場所に依存します。
ビューとコントローラーについての話に戻ります。 たとえば、統計情報をグラフ形式で画面に表示するシステムを作成します。 主要なのは、美しいグラフを描くことです。つまり、 主役。 さらに、統計自体は私たちにとって重要ではないと想像し（実際、これは完全に間違っている可能性があります）、制御が未知のものから転送されると想像します。 したがって、オブジェクトアプローチを使用します。Viewのグラフを描画する方法を説明し、ViewへのリンクをControllerに渡し、適切な場所でControllerからメソッドを呼び出します。
別の状況-統計（マネージャー）は私たちにとって重要であり、それがどのように提示されるかはすでに二次的です。 さて、私たちにとって、未知は統計の表示方法です。 イベントアプローチを適用します。 イベントについて説明し、適切な場所で開始します。 現在、私たちにとっては、誰がどのように処理するかは問題ではありません。 チャート描画モジュール自体は、必要なイベントをサブスクライブします。
前者の場合、統計だけでなく運用データなど、さまざまなタイプの情報のグラフを呼び出す方が便利です。 つまり 1つのビューに異なるコントローラーを使用するのは簡単です。 反対に、2番目の方法では、美しいグラフの形と、値のクラウドの形、およびその他の方法の両方で統計情報を（同時に）描画できます。 つまり、1つのコントローラーに対して複数のビューを簡単に定義できます。
なんで？
どういうわけか、アプリケーションのさまざまな部分の相互作用を実装しました。 その瞬間、私はこのトピックについてそれほど深く考えず、その時私に思われた最も簡単なことをし、そして再び最も簡単なことをしました。 その結果、設計が混在することが判明しました。 ControllerとViewはお互いを知っていました-どこかでコントローラーがプレゼンテーションメソッドを呼び出し、どこかでViewがイベントをサブスクライブしました。 これは私が警告したいことです。 なぜなら、それは互いに関するオブジェクトの相互知識につながり、結果として：
- システムデバイスの独自の理解の難しさ。
- クラスの変更の難しさ。
- システム設計を部外者に説明するのが難しい。
この段階で開発されたシステムは非常に単純なので、最初の問題はまだ発生していません。 2つ目はまだ感じていません。 しかし、これは彼らが将来にいなくなることを意味するものではありません。 しかし、チームへの新しい人の出現で、3番目のものは困難さえもたらしました。 このため、知識を構造化し、すべてを統一された用語で説明する必要がありました。
これらのパターンおよびその他のパターンについては、「オブジェクト指向設計の受容」という本に記載されています。 デザインパターン」E.ガンマ、R。ヘルム、R。ジョンソン、J。ヴリスサイドによる。 UMLについては、書籍「UML。 ユーザーガイド」Grady Butch、James Rambo、Aivar Jacobson。
All Articles