「こんにちは、アミーゴ！ OOP の目的を理解してもらいたいのです。そこで、ある話をします。」

かつて、宇宙に商品を輸送する小さな会社がありました…

「ギャラクティックラッシュみたいな​​？」

「はい、ギャラクティック・ラッシュのように。そこでは5人が働いていました。1人目は財務を担当し、2人目は倉庫で働き、3人目は発送を担当し、4人目は広告を担当し、5人目はすべてを監督していました。」

彼らは一生懸命働き、成長しました。その会社は評判が良く、たくさんのお金を稼ぎました。注文数が年々増加したため、CEO はより多くの従業員を雇用する必要がありました。倉庫担当の数名、出荷担当の数名、レジ担当者、そして売上を伸ばすためのマーケティング担当者が 1 名です。

ここから問題が始まりました。人員も増え、お互いに干渉し始めた。

Java webinar

マーケティング担当者は新たな広告キャンペーンに全額を費やし、緊急に発送するはずだった商品を購入するための現金が手元に残っていませんでした。

倉庫には、月に 1 回出荷される、新品のハイパードライブが入った 10 個の箱がありました。ある宅配業者が 1 台のハイパードライブを持って出発したため、別の顧客による 10 台のハイパードライブの注文はさらに 1 か月遅れました。最初の配達員は、他の注文が 2 番目の配達員によって処理されていることを単に知らなかったのです。

新しい CEO 補佐は、商品を購入するために船に宅配便を送り、他のすべては次に利用可能な船を待ちました。急ぎの配達がたくさんありましたが、このアシスタントは購入を管理するだけで、自分の仕事をうまくやろうとしていました。 一人が自分の職務をよりよく遂行するほど、他の人に干渉するようになります。

CEO は状況を分析する中で、船、現金、物品などの重要なリソースが最適に使用されているのではなく、「先着順」で使用されていることを認識しました。誰でも仕事を遂行するためにリソースを奪い、他の従業員や会社の生産性を脅かす可能性があります。

何かをしなければなりませんでした。CEO は一枚岩の会社をいくつかの部門に分割することにしました。彼は出荷部門、マーケティング部門、購買部門、財務部門、倉庫部門を創設しました。今では誰も船に乗ることができなくなりました。出荷部門の責任者はすべての出荷情報を受け取り、配送が会社にとって最も利益になる宅配業者に出荷しました。さらに、倉庫では宅配業者が商品を単に受け取ることはできませんでした。彼らはプロセスをコントロールしていました。財務部門は、近いうちに買収が行われるとわかっていれば、マーケティングに資金を割り当てることはできませんでした。各部門には部門長という公人が 1 人いました。各部門の内部構造はそれぞれの懸念事項でした。配達員が商品を受け取りたい場合は、倉庫ではなく倉庫管理者に行きます。新しい注文が入ったとき、それは配達員 (個人) ではなく、配送部門の責任者 (一般人)に送られました。

言い換えれば、CEO はリソースとアクションを部門にグループ化し、他の部門が内部の部門構造に干渉することを禁止しました。 特定の人のみに連絡を取ることができました。

OOP の観点から言えば、これはプログラムをオブジェクトに分割することに他なりません。関数と変数で構成されるモノリシック プログラムは、オブジェクトで構成されるプログラムに変換されます。そして、これらのオブジェクトには変数と関数が含まれています。

「ちょっと待ってください。つまり、すべての従業員がリソースに無制限にアクセスでき、他の従業員にコマンドを発行できることが問題だということですか?」

"はい、正確に。"

「興味深いですね。小さな制限を導入しましたが、より多くの注文を受けました。そして、彼らはすべてをより適切に管理することができました。」

「はい。最も純粋な形で分割して征服してください。」

「あなたの言った通り、分割統治することです。それは覚えておくべきことです。」