🕐 約8分間の読み物
📝 この記事に関するメモ
この記事は、私のOOPとSOLIDの原則に関する個人的な学習メモに基づいて作成されました。メモをより読みやすく、役立つものにするため——私自身にも他の人にも——私はAIの助けを借りて、ブログ記事として発展させ、整理しました。アイデア、学習の旅、理解は私のものです；AIは執筆と提示の部分で助けをしました。
読みやすく、変更しやすいコードは偶然ではない。楽しいと感じるコードベースの背後には、すべてがどのように構成され、結びつくかを導くいくつかの考え方がある.
この記事では、その完全な旅について話す——OOPとは何か、オブジェクトがどのように相互に関連しているか、悪い設計とはどのようなものか、そして最終的には、すべてを統合するSOLIDの5つの原則.
始めよう。
第1部：OOPとは何か？
Object Oriented Programming (OOP) は、現実世界を反映するコードを書く方法です。長い指示のリストの代わりに、関連するデータと行動を オブジェクト にまとめます。
🤖 ロボットの玩具を想像してみてください。ロボットには プロパティがあります (色、高さ、バッテリー) と 行動 (歩く、話す、手を振る)。オブジェクト指向プログラミングにおいて、そのロボットはオブジェクトであり — 彼を構築するための設計図は class と呼ばれる。
二つの重要な用語:
- Class — 設計図（テンプレート）
- Object — その設計図から作られた実際のもの
オブジェクト指向の4つの柱
| 柱 | その機能 |
|---|---|
| 継承 | 子クラスは親クラスのプロパティと振る舞いを継承する |
| カプセル化 | 内部データは隠蔽され—外部からのアクセスは指定されたルートを通じてのみ可能 |
| 抽象化 | 内部の Kerumitan は隠され、必要なものだけが表示されます |
| 多態性 | 同じアクションがオブジェクトによって異なる挙動を示す |
第2部：オブジェクトどうしの関係性について
オブジェクトはそれぞれ独立して存在しません。彼らはつながり、協力し、互いに依存しており—そして 種類 は重要です.
アソシエーション
二つのオブジェクトが相互に認識し、相互作用できます。カーディナルリティには三つの種類があります.
- 一対一 — 一人の人が一つのパスポート
- 一対多 — 一人の教師、多くの生徒
- 多対多 — 多くの生徒、多くの科目
アソシエーションにおいて、一つのオブジェクトが他のオブジェクトを「持つ」場合、その関係は以下のようになります：
- 集約 (疎結合) — 子供のオブジェクトは親から独立して存在できます。バッグに本が入っているが、バッグが捨てられたとしても本はそのまま存在します。
- 組成 (密結合) — 子供のオブジェクトは親の存在に依存しており、親が存在しないと存在できません。家に部屋がある；家が破壊されれば、部屋も一緒に消滅します。
依存関係
一時的な使用ベースの関係。一つのクラスが別のクラスを使用するが、永続的に保持しない。アソシエーションより弱い.
一般化 & 実現
- 一般化 — 複数のクラスから共通の特性を一つのスーパークラスに引き上げる（継承）
- 実現 — インターフェースを実装するクラスで、定義された契約を果たすことを約束しています
第3部：悪いデザインはどのようなものですか？
ルールを学ぶ前に、避けるべき点を理解することが重要です。ロバート・C・マーティンは、3つの悪いデザインの兆候を特定しました
🪨 柔軟性の欠如 — システムは変更が難しい。一つを触れると、多くの他のものも更新が必要になる。開発者は変更を行うのを恐れる。
🍪 弱さ (Kerapuhan) — 変更を行うと、予期せぬ場所でシステムが壊れる。支払いモジュールのバグを修正している途中で、突然メール通知が機能しなくなる。
🏗️ 固着 (Ketidakmampuan Dipindahkan) — 有用なコンポーネントは再利用できません。それらは環境と過度に摩耗しているため、取り除くのに最初から書き直すよりも時間がかかります。
これら三つには同じ根本的な原因があります： コンポーネント間の依存関係管理が悪い。
第4章：SOLID
SOLIDは上記の問題を直接解決する五つの原則です。それぞれは特定の設計の失敗をターゲットとしています。
S — 単一責任の原則
「モジュールは一つの、そしてそれ以上の役割に対して責任を持つべきである。」
各クラスは正確に一つの理由で変更されるべきです — 1つの役割（1つのステークホルダーグループ）を担当します。
👨🍳 レストランの従業員が同時にシェフ、カスケール、セキュリティパーソン、そして食事の配達役を務めることは、起こりうる災害です。1つの役割の変更が他のすべての役割を妨げます。
クラスを分けなさい。1つのクラスあたり1つの責任.
O — 開放/閉鎖原則
「ソフトウェアのアーティファクトは追加するために公開され、変更するために閉じるべきです。」
新しい動作を追加するには、拡張する方法で — 既に動作している古いコードを編集するのではなく.
🔌 ストップコネクターは、新しいデバイスを接続するためにケーブルを外す必要がないことを可能にします。それがOCPの実践です。
ニーズが変わったら、古いコードの横に新しいコードを追加する——動作しているものを書き直さない.
L — リスコフの置換原則
「SがTのサブタイプである場合、T型のオブジェクトはS型のオブジェクトで置き換えることができ、プログラムの正しさを変えない。」
サブクラスは完全に置換可能であるべき は親クラスです。親が約束したすべてのことは、子が果たす必要があります.
🤖 親ロボットが料理できるなら、子ロボットも料理できるべきです — エラーを投げたり、何もせずに黙って待つことはできません.
もしサブクラスに空のメソッドがあるなら、実装のスタブを提供するか、「サポートされていません」と投げる — これはリスコフの置換則に違反します.
I — インターフェース分離の原則
「クライアントは、使わないインターフェースに依存させられない。」
大きすぎるインターフェースを作らず、クラスが不要なメソッドを実装するように強制しないように。インターフェースを小さく、より焦点を当てた部分に分割する。
🍴レストランの客に、ステーキのナイフ、スープのフォーク、スプーン、フォンデュのスプーンを与えないで、スープを注文した時だけ。
より小さいインターフェース = より狭い依存 = 位置特定の変更が継続します.
D — 依存性の逆転の原則
「高レベルモジュールは低レベルモジュールに依存しない。両者は抽象化に依存しなければならない。」
ビジネスロジックは特定の実装と直接関連しない。インターフェースとコミュニケーションしなければならない — 低レベルの詳細な実装で、そのインターフェースを実装しています.
🤖 スパタラをロボットの手に溶接しないでください。標準コネクターを手に与え、工具を交換可能にしてください.
これが、インフラストラクチャ（データベース、API、ファイルシステム）を変更してもビジネスロジックを触ることなくできる理由です.
簡潔なまとめ：SOLIDの概要
| 原則 | 解決すべき問題 | 鍵となる質問 |
|---|---|---|
| SRP | クラスが多くのことを行っている | 「このクラスは複数のステークホルダーグループをサービスするか？」 |
| OCP | 古いコードを修正して機能を追加 | 「これは拡張として追加できそうか、変更としてではなく？」 |
| LSP | 損なわれた継承階層 | 「子孫が親を置き換えることで何も損なわれないか？」 |
| ISP | 肥大化したインターフェースと未使用のメソッド | 「このクラスは不要な実装を強制されているか？」 |
| DIP | ビジネスロジックがインフラに結びついている | 「高レベルのコードが、本来でない具体的なクラスに依存しているか？」 |
どこから始める？
初めてこれを実装するなら：
- SRPから始める — 「多くの仕事をしている」クラスを見つけ、分割する
- LSP違反のために継承を確認 — 空のメソッドはその警告の印
- インフラストラクチャの境界にインターフェースを追加 — それが実践におけるDIPです
これらの原則はチェックリストではありません。コードを書くたびにあなたが問いかけなければならない質問です
最初に公開された場所はsanudin.dev