この記事は、「SOLIDの原則を心で理解する」に関するシリーズの締めくくりとして、その最後の原則であり、重要な「依存性逆転の原則（DIP: Dependency Inversion Principle）」について解説します。 これはおそらく5つの原則の中で最も重要なものであり、単一責任の原則（Single Responsibility Principle）やリスコフの置換原則（Liskov Substitution Principle）とともに、とても優れたアーキテクチャパターンである基礎を形成しています。 高レベルのモジュールと低レベルのモジュールについての説明は以下の通りです。 高レベルのモジュール これらのモジュールは通常、ビジネスロジックやアプリケーションのオーケストレーション（調整）を含みます。複雑なタスクの調整やビジネスルールの適用を担当することが多いです。 低レベルのモジュー

さて、SOLIDの原則を心で理解することの探求を続けましょう。その第四の原則は「インターフェース分離の原則」（ISP）であり、Wikipedia(英語版)では以下のようにまとめられています。 以前のSOLID原則に関する投稿、特に単一責任の原則（SRP）に関するものを読んだことがあるなら、その目的にすでに気付いているかもしれません。 ここでも同様に、疎結合のシステムを構築することを目指しています。これは、強い凝集性、低い結合性を達成するために、クラスとインターフェースを一貫性があり、モジュール化され、保守が容易な形で設計することを通じて実現します。 原則の理解 今回は乗り物（車・バイク）を参考例として作成しました。 まず、すべての種類の車両に対してメソッドを定義するインターフェースVehicleをモデル化することで始めました。そのメソッドには、startEngine()、stopEngin

SOLIDの原則を心で理解することの探求を続け、TypeScriptの例を交えて説明します。 単一責任の原則 (SRP) と オープン/クローズドの原則 (OCP) を見た後、今日は リスコフの置換原則 (LSP) に注目します。 この原則は1994年に バーバラ・リスコフ と ジャネット・ウィング によって定義され、派生クラスが基底クラスの代わりに透過的に使用できる条件を定義しています。 言い換えれば、サブクラスがスーパークラスの代わりに使用されても、プログラムの期待される動作に影響を与えないことを保証します 🤩 原則の定義 リスコフの置換原則の最も明白な定義は下記の通りです。 まだ明確でない場合、長い説明よりも例を見た方がわかりやすいので、TypeScriptのいくつかの例を一緒に見てみましょう。 シンプルで理論的な例 次の例は独創的ではありません。一般的にリスコフの置換原則 (LS

一つの記事で始めたSOLID原則の探求を続け、今回は2番目の原則であるオープン/クローズドの原則について説明します。 この概念は、1988年にバートランド・メイヤーが彼の著書「オブジェクト指向入門」で表現したように、多くの著者によってオブジェクト指向プログラミングの最も重要な原則の一つと考えられています。 モジュール（クラスや関数など）が「拡張には開かれているが、修正には閉じている」べきだと述べています。 つまり、新しい機能を追加する際には、既存のコードを変更せずに済むように設計することが重要です。これにより、既存の機能に影響を与えずにシステムを拡張することができます。 例えば、あるクラスに新しい機能を追加したい場合、そのクラスを直接変更するのではなく、継承やインターフェースを使って新しいクラスを作成することで、元のクラスを変更せずに機能を拡張することができます。 この原則の概念自体は素晴

React(TypeScript)でSOLIDの原則を心で理解する 一度記事にアウトプットしたものの完全に理解するためにそれぞれの原則を別の記事で再度深掘りしていきます。 原則の5つのすべてを一度に説明しており、十分に理解が乏しく複雑さを詳しく説明できておりませんでした。 今回も TypeScript の例を付属してますが、以下の内容はオブジェクト指向をサポートするプログラミング言語に適用されることと理解しています。 単一責任の原則 SRP (Single Responsibility Principle) 意味 ここでのモジュールとは、機能的な責任をカプセル化するソフトウェアコンポーネントを指します。 最も一般的な例はクラスですが、関数やメソッドなどにも適用できます。 より高いレベルでは、この原則はソフトウェアアーキテクチャ、例えばマイクロサービスアーキテクチャを設計するときにも適用され

先週、TypeScriptの3つの黄金ルール（独自解釈）について説明しました。 その中で第三のルール「型の派生を優先する：汎用型（ジェネリクス）」は特に実装が難しいものです。 型システムが効果的に機能するのは、その定義が正確であるためです。 しかし、より正確になるほど、型の複製が増え、コードが保守不可能になるリスクが高まります。その解決策は、派生（=他の型から型を定義すること）を利用することです。 しかし、簡単ではありません。そこで今日は、型を最適に設定するためのいくつかの重要な概念をステップバイステップで紹介します。これらの概念を徐々に理解することで、コードの任意の部分を型付けするための自立を目指すことができるでしょう💪（頑張る） 取り上げる概念 オブジェクトのキーを取得する オブジェクトのキーをフィルタリングする クラスを操作する 文字列を操作する inferを使用して既存の型から型