1. OOP の原則の紹介
今日、あなたは新しくて興味深い世界を発見するでしょう。オブジェクト指向プログラミング( OOP )の世界。クラスとオブジェクトについては以前に学習しました。今日は、それらについてさらに詳しく学びます。
OOP は、プログラムの複雑化への対応として登場しました。プログラム内の変数とメソッドの数が数万に達し始めたとき、何かをしなければならないことが明らかになりました。1 つの解決策は、データと関連するメソッドを個別のオブジェクトに結合することでした。
現在、プログラマーは、オブジェクトが外部とどのように相互作用するか、およびオブジェクトが内部でどのように動作するかを個別に記述する必要がありました。これにより、プログラムの理解と作成がはるかに簡単になりました。しかし、疑問は残りました。どのメソッドがオブジェクトの内部にあるべきで、どのメソッドが他のオブジェクトで利用できるべきでしょうか?
多くのアプローチが試みられました。そして発見されたベストプラクティスに基づいて、OOPの 4 つの原則が生まれました。それらは、抽象化、カプセル化、継承、ポリモーフィズムです。以前は 3 つしかありませんでしたが、後に専門家は抽象化も追加することを決定しました。
2. 抽象化
インターネット上の人々は、OOPにおける抽象化の定義について今でも議論しています。問題は、全員が間違っているということではありません。それは誰もが正しいということです。プログラムが小さいほど、Java 言語に関連付けられる抽象化が高くなります。プログラムが大きくなるほど、現実世界のオブジェクトのモデリング/単純化に抽象化が結びつきます。
しかし、優秀な頭脳は次の点に同意しているようです。
抽象化とは、プログラム内でオブジェクトを十分に正確に表すオブジェクトの特性のみを使用することです。主なアイデアは、タスクを十分な精度で同時に解決できる最小限のフィールドとメソッドのセットでオブジェクトを表現することです。
Java では、抽象化は抽象クラスとインターフェイスを通じて実現されます。
実生活における抽象化
実生活における抽象化の良い例は、会社や組織での職務記述書です。役職の肩書は同じですが、その役職に割り当てられる具体的な責任はまったく別の問題です。
あなたが将来の会社の組織構造を設計していると想像してください。秘書の責任を分割して、いくつかの異なる役職に分散させることができます。CEO の役職を、CFO、CTO、CMO、HR ディレクターなどのいくつかの役職に分割できます。または、たとえば、オフィスマネージャーと採用担当者のポジションを 1 つに結合することもできます。
役職を考えて、その役職に対する責任を分担します。抽象化とは、オブジェクト全体から脱却し、必要な本質的なプロパティとコンポーネントを選択することです。
プログラミングの観点から見ると、抽象化とは、プログラムをオブジェクトに正しく分割することです。通常、大規模なプログラムを相互作用するオブジェクトとして表現する方法は数十あります。抽象化を使用すると、重要な特性を選択し、重要でない特性を無視できます。
3. カプセル化
カプセル化の目的は、オブジェクトをより単純にすることで対話を改善することです。
そして、何かを単純化するための最良の方法は、複雑なものを詮索好きな目から隠すことです。たとえば、ボーイング ジャンボ ジェット機のコックピットに乗り込まれたとしても、その操作方法をすぐには理解できないでしょう。
しかし、飛行機の乗客にとっては、すべてが簡単です。チケットを購入して飛行機に乗り、離陸して着陸します。「チケットを買う」と「飛行機に乗る」だけで、ある大陸から別の大陸へ簡単に飛ぶことができます。飛行、離陸、着陸、およびさまざまな緊急事態に備えて航空機を準備する複雑さはすべて隠されています。衛星ナビゲーション、自動操縦、航空管制センターは言うまでもありません。そしてこれは私たちの生活を簡素化します。
プログラミングの観点から見ると、カプセル化は「実装を隠す」ことです。私はこの定義が好きです。私たちのクラスには何百ものメソッドを含めることができ、さまざまな状況で非常に複雑な動作を実装できます。しかし、そのすべてのメソッドを (private 修飾子でマークすることで) 覗き見から隠し、(public 修飾子でマークすることで) 他のクラスと対話するメソッドを 2 つまたは 3 つだけ残すことができます。そうすれば、プログラムの他のすべてのクラスは 3 つのパブリック メソッドのみを認識して呼び出しますが、他のクラスは呼び出しません。そして、コックピットが幸せな乗客から隠されるのと同じように、すべての複雑さはクラスの内部に隠されます。
4. 継承
継承には 2 つの側面があります。プログラミングにおける継承と現実世界における継承。プログラミングにおいて、継承は2 つのクラス間の特別な関係です。しかし、現実の継承ははるかに興味深いものです。
現実に何かを作成する必要がある場合、次の 2 つの選択肢があります。
- 膨大な時間と労力をかけて、必要なものを一から作り上げる。
- すでに存在するものをベースにして、必要なものを作成します。
最適な戦略は次のとおりです。既存の優れたソリューションを採用し、少し変更し、ニーズに合わせて調整してから使用します。
人類の歴史をその始まりまで遡ってみると、地球上に生命が誕生してから数十億年が経過していることがわかります。しかし、人類の出発点が霊長類の祖先であると考えると（つまり、人類は霊長類の祖先に「基づいている」）、まだ数百万年しか経過していません。ゼロから構築するとさらに時間がかかります。もっと長く。
プログラミングでは、別のクラスに基づいてクラスを作成することで、同様のことを行うことができます。新しいクラスは、既存のクラスから派生 (継承) します。これは、必要なデータとメソッドの 80 ～ 90% が既存のクラスにある場合に非常に有益です。適切なクラスを新しいクラスの親として宣言するだけで、親クラスのすべてのデータとメソッドが新しいクラスに自動的に表示されます。便利ですよね？
5. ポリモーフィズム
ポリモーフィズムはプログラミングの概念です。これは、さまざまな実装が単一のインターフェイスの背後に隠されている状況を説明します。現実の生活に目を向けると、車両の操作が最適であることがわかりました。
トラックを運転できる人であれば、救急車やスポーツカーのハンドルを握ることもできます。すべての車が同じ制御インターフェイス (ステアリング ホイール、ペダル、ギアシフト) を備えているため、車の種類に関係なく、人は車を操作できます。車の内部構造は異なりますが、すべて同じ制御インターフェイスを備えています。
プログラミングの世界に戻ると、ポリモーフィズムにより、異なるクラスのオブジェクト (通常は共通の祖先を持つ) に同じ方法でアクセスできるようになり、その値を誇張することはほとんどできないプロパティです。プログラムが大きくなるにつれて、その値は増加します。
OOPとは原則を意味します。内部法。それらはそれぞれ何らかの形で私たちを制限しますが、プログラムが大規模になると、その代わりに大きな利点をもたらします。OOPの 4 つの原則は、テーブルの 4 本の脚に似ています。1 つを取り去ると、システム全体が不安定になります。
GO TO FULL VERSION