Zenn
🐵

OOP（オブジェクト指向プログラミング）用語チートシート

2024/03/06に公開
Java
TypeScript
NestJS
#
オブジェクト指向
#
OOP
tech

OOPの用語チートシート

※備忘録

OOPの基本概念

  1. クラス (Class)

    • プロパティ（属性）とメソッド（機能）を持つオブジェクトの設計図。
    • 例: class Car { ... }

  2. オブジェクト (Object)

    • クラスに基づいて生成された実体（インスタンス）。
    • 例: let myCar = new Car();

  3. プロパティ (Property)

    • オブジェクトに属する変数。オブジェクトの状態を表す。
    • 例: car.color = 'red';

  4. メソッド (Method)

    • オブジェクトに属する関数。オブジェクトの振る舞いを定義。
    • 例: car.start();

  5. カプセル化 (Encapsulation)

    • オブジェクトの詳細（状態と振る舞い）を隠蔽し、外部からの直接的なアクセスを制限するプロセス。
    • 例: private, public, protected キーワード

  6. 継承 (Inheritance)

    • 一つのクラス（スーパークラス）の特性を別のクラス（サブクラス）が受け継ぐこと。
    • 例: class ElectricCar extends Car { ... }

  7. 多態性 (Polymorphism)

    • 同じインターフェースまたはメソッドが異なるデータ型やクラスに対して異なる実装を持つこと。
    • 例: メソッドオーバーライド、メソッドオーバーロード

  8. 抽象化 (Abstraction)

    • 複雑な現象から本質的な概念を抽出し、単純化するプロセス。
    • 例: 抽象クラス、インターフェース

  9. インターフェース (Interface)

    • メソッドのシグネチャの集合を定義するが、それらの具体的な実装は含まない。
    • 例: interface Drivable { drive(): void; }

  10. コンストラクタ (Constructor)

    • クラスからオブジェクトを生成する際に呼ばれる特別なメソッド。
    • 例: constructor() { ... }

OOPの原則

SOLIDの原則

  • 単一責任の原則（Single Responsibility Principle）
  • オープン/クローズドの原則（Open/Closed Principle）
  • リスコフの置換原則（Liskov Substitution Principle）
  • インターフェース分離の原則（Interface Segregation Principle）
  • 依存性逆転の原則（Dependency Inversion Principle）

1. 単一責任の原則（Single Responsibility Principle, SRP）

  • 定義: 一つのクラスは一つの責任だけを持つべきです。
  • 目的: 変更の理由を一つに限定することで、システムをより理解しやすく、保守しやすくします。
  • 例: あるUserクラスが、ユーザー情報の管理と、ユーザーデータのデータベースへの保存を行っているとします。SRPに従うと、このクラスは二つの責任を持っているため、問題があります。解決策として、ユーザー情報の管理をUserクラスに、データの保存をUserRepositoryクラスに分離します。

2. オープン/クローズドの原則（Open/Closed Principle, OCP）

  • 定義: ソフトウェアのエンティティ（クラス、モジュール、関数など）は、拡張に対して開かれているべきですが、変更に対して閉じられているべきです。
  • 目的: 既存のコードを変更することなく、システムの振る舞いを変更または拡張できるようにします。
  • 例: グラフ描画システムで、異なるタイプのグラフ（棒グラフ、折れ線グラフ等）を描画する機能があるとします。新しいグラフタイプを追加するたびに既存のコードを変更するのではなく、グラフ描画のための共通インターフェース（例えばGraph）を定義し、新しいグラフタイプはこのインターフェースを実装する新しいクラス（例えばPieChart）として追加します。

3. リスコフの置換原則（Liskov Substitution Principle, LSP）

  • 定義: サブクラスはいつでもそのスーパークラスの代わりに使用できるべきです。
  • 目的: 継承を使用する際に、派生クラスが基底クラスの振る舞いを正しく継承・実装していることを保証します。
  • 例: 動物園の動物管理システムがあり、すべての動物はAnimalクラスから派生しています。BirdクラスはAnimalのサブクラスです。このシステムでは、Animal型のオブジェクトを扱う場合、それがBirdのインスタンスであっても問題なく動作しなければなりません。例えば、Animalが持つmakeSoundメソッドをBirdがオーバーライドしている場合でも、BirdのインスタンスでmakeSoundを呼び出すと、鳥の鳴き声が得られるべきです。

4. インターフェース分離の原則（Interface Segregation Principle, ISP）

  • 定義: 一つのクラスは、自身が使用しないメソッドに依存するべきではありません。
  • 目的: 大きくて一般的なインターフェースよりも、小さくて特定のインターフェースを多く持つ方が望ましいという考え方です。
  • 例: あるMultiFunctionPrinterクラスが、印刷、スキャン、ファックスの機能を持っているとします。ISPに従うと、このクラスは複数の異なる機能を持ちすぎています。解決策として、Printable、Scannable、Faxableといった個別のインターフェースを作成し、必要に応じてこれらのインターフェースを実装する複数のクラスを作成します。

5. 依存性逆転の原則（Dependency Inversion Principle, DIP）

  • 定義: 高レベルのモジュールは、低レベルのモジュールに直接依存すべきではなく、両方が抽象化に依存すべきです。また、抽象化は詳細に依存すべきではなく、詳細が抽象化に依存すべきです。
  • 目的: システムの各部分の間での依存関係を減らし、拡張性と保守性を向上させます。
  • 例: ショッピングカートアプリケーションで、ShoppingCartクラスがMySQLDatabaseクラスに直接依存しているとします。DIPに従うと、この直接的な依存関係は問題です。解決策として、DatabaseInterface（抽象化）を定義し、ShoppingCartはこのインターフェースに依存するようにします。MySQLDatabaseはDatabaseInterfaceを実装します。これにより、将来的に異なるデータベースに切り替える場合でも、ShoppingCartクラスを変更する必要はありません。

これらのSOLID原則を適用することで、より拡張可能で、保守しやすく、そして堅牢なソフトウェアシステムを設計・開発することができる。

Discussion