「こんにちは、アミーゴ! OOP のもう 1 つの利点についてお話したいと思います。ご存知のとおり、プログラムは建物というよりも動物に似ています。プログラムは構築されるのではなく、成長していくものです。開発とは継続的な変更を意味します。構築では、次のことができます。適切な計画を立てて、それを最後まで実行します。しかし、ソフトウェア開発ではそうではありません。」
意図したとおりに何かを実行できず、プログラムを何度も作り直さなければならないことがよくあります。さらに多くの場合、顧客の要件は変化します。
「しかし、顧客が非常に詳細な仕様を提供した場合はどうなるでしょうか?」
「時間の経過とともに何が起こるか見てみましょう。製品が成功すると、顧客は新しいバージョンをリリースし、さらに別のバージョンをリリースしたいと思うでしょう。そしてもちろん、いくつかの「小さな変更」を加える必要があります。」_ _
「それでは、このすべてから何が結論づけられるでしょうか？」
「製品の内部構造は、最小限の手戻りで大きな (および小さな) 変更を加えられるような方法で維持されなければなりません。」
「どうやってそれをするのですか？」
「プログラムが相互に作用するオブジェクトでどのように構成されているかについてはすでに説明しました。ボード上のプログラムのオブジェクトをすべて太いドットを使用して表しましょう。各オブジェクト (ドット) からすべてのオブジェクトに矢印を描きます。 (ドット) と相互作用します。」
次に、オブジェクト (ドット) をグループに結合してみましょう。ドットは、他のドットよりも相互に接続されている場合、同じグループに属します。ドットの矢印のほとんどがそのグループ内のドットを指している場合、オブジェクトは正しくグループ化されています。同じグループ内のドットは密に結合していると言われますが、異なるグループ内のドットは疎に結合しています。
これは「疎結合の原理」と呼ばれます。プログラムは複数の部分 (多くの場合は層) に分割され、そのロジックは内部構造と強く結びついており、他の層/部分とは弱く結びついています。通常、レイヤー間の相互作用は高度に細分化されています。ある層は、そのクラスの小さなサブセットのみを使用して別の層を呼び出すことができます。
「同じ『分業』の原則を、より大規模に？」
「その通りです。これにより、部門を再編成し、効率を高め、さらに多くの人を雇用することができます。部門間のプロトコルを変更しなければ、すべての変更はローカルなものになります。誰も再教育を受ける必要はありません。私たちはそうしません。」システム全体を作り直す必要はありません。部門間の相互作用のメカニズムが適切に選択されていれば、各部門はこのようにして内部事情を最適化できます。」
「もし彼らがうまく選ばれたら。そしてうまく選ばれなかったらどうする？」
「そうすると、変更を加えるための「余裕」がすぐになくなってしまい、システム全体を作り直さなければならなくなります。そういうことは時々起こります。未来を予測することはできませんが、プログラムを書き直す回数を最小限に抑えることはできます。」
「わかりました。そのようにプログラムを分割する利点はわかりますが、OOP はどのように考慮されるのでしょうか?」
「部門をどのように構成し、どのように相互作用するかを選択するとき、私たちは『抽象化の原則』を適用します。プログラミングでは、抽象化は、プログラムを分割する最適な方法と各部分がどのように相互作用するかを決定するために使用されます。この原則は、また、プログラムを個々のクラスに分割するまで、構成部分に繰り返し適用する必要があります。」
「そして、これらのパーツの内部構造を隠し、他のパーツとの相互作用を厳密に制限すること、それがカプセル化ですよね?」
「その通りです。カプセル化と抽象化は OOP の基礎です。優れたプログラムはこれら 2 つの原則を遵守する必要があります。後で他の原則を見て、その利点を理解することにします。」
「よかったです。待ちきれません！」
GO TO FULL VERSION