オブジェクト指向プログラミング

Object Oriented Programming

"データをオブジェクトに定義し、オブジェクトの相互作用を使ってプログラムを作る方法"

オブジェクト (Object)

データの抽象化; 状態(State)と行為(Behave)を持つ物

現実世界からのインスピレーション

→ オブジェクトの相互作用でプログラムロジックを構成

手続き型プログラミング vs オブジェクト指向プログラミング

手続き型プログラミング (Procedural Programming)

"順番が決めた作業(routine；procedure)の連続でプログラムを作る方法"

• メリット

  コンピューターの処理ルーチンと類似で、実行速度が速い

• デメリット

  メンテナンスが難しい(特に,プロジェクトのスケールが大きくなったらスパゲッティコードに成る)

  コードの実行順序が結果に影響を与える

  デバッグの難

PPとOOPの違い

プログラムの実現にあって、何処に重点を置くのか

PP

→ データ変化を中心に関数を実現

OOP

→ 機能を中心にメソッドを実現

OOP登場切っ掛け

時間が過ぎってハードウェアの発展速度がソフトウェアの発展速度を追い付くのができなくなる

オブジェクト指向プログラミングは機能を一所に集めて、モジュール化および再利用 → ハードウェアの重複計算を防ぐことで性能を高める

OOP特徴

1. カプセル化(Encapsulation)

"関わるデータとコードを一所に集めること"

変数と関数がコード全体に広かったら,コードを再利用(メンテナンスおよび拡張)するのことが難しい

→ カプセル化でデータと機能の再利用性増加

情報隠蔽

"データをカプセルの中で隠して、メソッドを通じて外部世界と相互作用"

(Pythonの場合、カプセル化でOOPができるが　情報隠蔽はできない)

(Javaの場合、privateみたいなキーワードを使ってクラス中にある情報を隠せることができる)

→ つまり、カプセル化が絶対的に情報隠蔽を保証するのでは無いけど、情報隠蔽のメリットを持つことができる

2. 相続(Inheritance)

"すでに定義したクラス(カプセル化)の特性を相続すること"

既存の属性および機能を変えたり追加して新しいクラスに作る

→ 相続はカプセル化を維持し、既存クラスを再利用することに役に立つ

3. 多態性(Polymorphism)

"同じ資料型に様々なオブジェクトを代入して多様な結果を出せる性質"

→ ある役割(インタフェース、スーパークラス)について多様な具現(クラスおよびオブジェクト)が存在すること

e.g.,

Hamburger burgerA = new BigMac();
Hamburger burgerB = new Whopper();

Overriding & Overloading

多態性実現を助ける技術

• Overriding

  既存の定義したメソッドを再定義すること

• Overloading

  同じ名を持ってるけど入力パラメーターのタイプと数を違く設定して関数を呼び出すこと

抽象化(Abstraction)

"必要な特性(フィールドやメソッド)を一般化、単純化させる作業"

俗に、設計上使うメソッドを予めインタフェースで作ったり、抽象クラスを宣言するために使う

抽象化はなぜ必要なのか？

ロール(Role)と具現(Implementation)の分離するため

オブジェクト間のどんな依存関係を構成する時、

依存されるオブジェクト(Server)から変更があっても、依存するオブジェクト(Client)側のコードには変更が無いようにするため

つまり、クライアントはサーバーの具現(クラスおよびオブジェクト)に依存することではなく、ロール(インタフェース)に依存するように関係を設定すればインタフェースの具現が変わってもクライアント側で別の変更が要らないとか最小化ができる

OOPメリット

• コードの再利用

• PPより理解安い仕組みとシンプルなコーディング

• メンタナンス、拡張の安い

• データモデリングをする時オブジェクトとデータのマッピングが安い

  → 要求事項をもっと明確に理解できる

OOPデメリット

• PPより遅い処理速度

• 設計に時間がかかりすぎる

• オブジェクトが変数を通じて状態を持つ

  → 予測できない状態になれば、バグがあるかも(関数型プログラミングの再発見)
  

オブジェクト指向的設計原則(SOLID)

1. SRP (Single Responsible Principle / 単一責任の原則)

   クラスは一つの責任を持つ

   変更がある時、波及効果(side effect)が少ないとSRPをよく従ったこと

2. OCP (Open-Closed Principle / 解放閉鎖の原則)

   拡張に開き、修正には閉じること

   → 多態性とインタフェースを使用

3. LSP (Liskov Subsitution Principle / リスコフの置換原則)

   上位タイプオブジェクトを下位タイプオブジェクトに置換する時、上位タイプを要求するプログラムの正確性を違反してはいけない

   → 多態性を支えるための原則で、インタフェースの具現(クラス)はこの原則を従う必要がある

4. ISP (Interface Segregation Principle / インタフェース分離の原則)

   インタフェースはユーザーを中心に分離すること

5. DIP (Dependency Inversion Principle / 依存性逆転の原則)

   高水準モジュールは低水準モジュールに依存してはならないこと
   （両者は、抽象化に依存するべきである）

   → クライアントは抽象化した概念に依存するように関係を設計するべきである