プログラム内で起こることは、数人のチームの活動に非常に似ています。 各チームメンバーには、自分自身のタスクと、ほとんどの場合、自分以外の誰も手を触れてはならない「職場」があります。 同僚はお互いに指示を出し、作業プロセスに関する情報を送信できます。 彼らは互いに助けを求め、それを提供することができます。 他のチームと同様に、彼らには、ユーザーと対話し、チーム内でアクションを調整することがタスクであるボスがいます。
このプログラムの見方によって、それは生き返り、その中で起こるすべてが何らかのイメージを帯び始めます。 すべての作業プロセスとタスクをさまざまな「従業員」に分散させると、すべてがどのように機能するかを理解し始めます。
かつて私が多くの時間を費やしたプレーヤーのソースコードは、長い間ハードドライブにほこりを集めてきました。 このアプリケーションは、気分が浮かんだ1年間書きました。 結局、私の熱意は尽き、プレイヤーは忘れられました。 そして最近、私はアーキテクチャのアイデアを思いつきました。それが判明したように、それはそれと完全に適合します。それについては後で説明します。 アプリケーションの「ワーカー」を強調し、各従業員が明確でシンプルで理解しやすいタスクを持つように役割を分散します。
知人
まず、チームの最も重要なメンバーは歌手です。 彼は彼を滑らせる音符で歌を歌います。 当然、プログラムでは音符は処理されません。これは「音楽トラック」の概念を置き換えるだけです。 歌手は、何かを歌うように指示することができ、やめるように頼み、少し大きくまたは静かに歌うように頼みます。 また、歌手にリストの次の歌の音符を付けて、ある歌から別の歌にすばやく移動できるようにすることもできます。
歌手が叫んでいる間、誰かが次に歌われる曲のリストを保持する必要があります。 ここにソーターがあります。 彼の仕事は、ユーザーが喜ぶ再生モードに従って、さらに再生される曲のリストを維持することです。 歌手が歌を終えると、彼はソーターに次からメモをとるように頼みます。 そして、彼はそれらを与えるか、または肩をすくめて、リストが終わったと言って、繰り返しはありません。 さらに、上司はいつでもユーザーが再生順序を変更したことを通知でき、ソーターは新しいリストを作成する必要があります。
ソーターは再生順序のみを保存し、一般的に利用可能な曲を知る必要があります。 曲の完全なリストを保存して操作するには、オーディオ技術者が責任を負います（そのような言葉があるようです）。 ほとんどの場合、リストを編集するときにサービスを参照するのはソーターです。 オーディオライブラリは、ルートフォルダのリスト、各フォルダのコンテンツのリスト、およびオーディオライブラリ内のトラックに関する情報を提供できます。
もう1つタスクがあります。 ユーザーが新しい音楽フォルダをオーディオライブラリに追加する場合、このフォルダを表示し、オーディオライブラリで見つかったすべての音楽に関する情報を入力する必要があります。 これはオーディオライブラリによって実行できますが、この場合、フォルダーの同時スキャンとオーディオライブラリの正しい機能を保証することは困難です。 検索エンジンにこれを行わせます-必要なすべての変更を蓄積し、それらをオーディオクラークに1回で転送して、オーディオライブラリで作業する際の遅延を最小限に抑えます。
そして最後の、最も責任のあるキャラクターはボスです。 彼は、チームの作業を開始し、ユーザーとやり取りする責任があります。 インターフェイスを制御し、ユーザーが何かを望んでいるかどうかを残りのユーザーに知らせます。 一時停止ボタンが押されました-ボスは歌手に停止するように頼みます。 コンポジションがキューに追加されました-上司はこれをソーターに報告します。 私たちの場合、これはほとんど必要ありませんが、部下は自分自身が処理できないもので助けが必要な場合はチーフに連絡することもできます。 この場合、上司はチームの誰が支援できるかを示すことができます。
これらの人々は誰ですか？
私はそのようなアーキテクチャについて聞いたことがありませんが、このようなものがすでに存在する可能性が高いです。 あなたがこれについて聞いたなら、あなたがコメントでそれについて書いてくれれば感謝します。 自転車を発明したかもしれないという事実にもかかわらず、私はやめません-突然マウンテンバイクであることが判明しました。
ビジネスに戻りましょう。 何とかしてパフォーマーに名前を付けなければなりません。 私は労働者、人格、手先について考えましたが、最も適切な言葉は「性格」だと思います。 この用語は、彼らや誰かを呼ぶのに十分な非人称です。 そして、ローファーと看護師と主な悪役。 キャラクターはどうあるべきですか？
第一に、彼にはいくらかの自由が必要です。 実生活の人々が所有しているものと同じです。 あなたは従業員に肉体的な力の助けを借りて何かを強制することはできません（私は人道的な労働のためです）。 したがって、キャラクターのオブジェクトの機能を直接呼び出すことはできません。これは、「人形劇」のようなものであり、自主的な仕事ではありません。 代わりに、彼はメッセージを受信し、可能な限りそれらに応答する必要があります。 メッセージングメソッドを提供する必要があることがわかりました。
次に、プロセスの各参加者にストリームを割り当てる必要があります。 これにより、お互いの独立性が確保されます。
第三に、ストリームがアクセス中にデータを損なうことがないように、適切な手段を提供する必要があります。 これは、システム内のプロセスの相互作用とそこに存在する問題にやや似ています。
投稿について
キャラクターは、彼に到着したメッセージを順番に処理します。 メッセージがない場合は、アイドル状態であるか、メッセージキューを定期的にチェックしてバックグラウンドで動作している可能性があります。
メッセージは何ですか？ 必要なパラメータを設定することにより、すべての場合に使用できる単一のタイプ-ユニバーサルを作成できます。 機能の普遍的な概念があるのとほぼ同じ方法で。 しかし、普遍性はしばしば単純なアクションの実装を複雑にするので、私はそのような決定を避けようとします。 1つの複雑な普遍的な方法よりも、何らかのアクションを実行するためのすべての可能なオプションをカバーする3つの単純な方法を好みます。 これは、もちろん、このアクションの実行方法を学習するのを多少複雑にしますが、時にはアプリケーションの速度を上げ、式の可視性を改善します。 さらに、アクションがタイプに分割されている場合、これはマシンがアクションを簡単に区別できることを意味し、これにより自動化と最適化の可能性が広がります。
したがって、メッセージを3つのグループに分けることができます。
1）タスク/割り当て-誰かがキャラクターに何らかの仕事をさせたい。 例：ユーザーが「再生」を押すと、ボスは歌手に歌を開始するように要求します。
2）リクエスト-キャラクターは、同僚にいくつかの資料を伝えるよう依頼する場合があります。 要求された人（そのような言葉があるはずです）が送信の準備が整うと、申請者は必要な資料を含むメッセージを彼から受け取ります。 例：歌手が新しい作曲を必要とするとき、彼はソーターからそれを要求します。
3）イベントの通知-あるキャラクターの活動が別のキャラクターの行動に依存することが起こる場合があります。 指揮者は、歌手が歌を変更してインターフェースを更新するタイミングを知る必要があります。 このため、指揮官は歌手に歌の変更について知らせるように依頼する必要があります。 そして、歌手はそれについて尋ねた人全員に通知メッセージを送信します。
メッセージとともに、任意の材料またはパラメータを転送できます。 実際、メッセージの送信と関数の呼び出しの唯一の違いは、メッセージがキャラクターに送信され、関数がすぐにトリガーされてオブジェクトに関連する間、遅延する可能性があることです。
それから、プレイヤーのすべてのキャラクターが理解できるすべてのメッセージをペイントしようと考えましたが、リストはかなり大きく、私はそれがかなり役に立たないと決めました。 だから私は終わり始めます。
おわりに
提示されたアーキテクチャにより、マルチスレッドアプリケーションを非常に明確に提示できます。 さらに、プログラムのすべてのコンポーネントをオブジェクトとパフォーマーに分類すると、プログラムの構造がより明確になります。 チーム開発により、責任を共有する方法がより明確になります-各プログラマーがキャラクターを引き受けることができます。
プログラムは、数人の労働者と作業資材を備えた単なる部屋であることが判明しました。 プログラマーの夢が実現しました。 プログラムの仕組みを説明できます。 コンセプトが想像しやすいなら、チャンスがあると確信しています。