最近「クリーン アーキテクチャ」という本を読んでいますが、この本のソフトウェア設計とアーキテクチャについての説明は非常に奥深いです。そこで、書籍『クリーン・アーキテクチャー』に収録されている優れた建築設計のコンセプトと、その内容に対する私の考えを記録するコラムを開設しました。
1. プログラミングパラダイム
1-1. 構造化プログラミング
構造化プログラミングは、コンピューター プログラムの読みやすさと開発時間を最適化し、ヌードル コードの記述を回避するために、従来の goto ステートメントをサブルーチン、ブロック構造、条件分岐、ループなどの構造に置き換えるプログラミング パラダイムです。
具体的には、構造化プログラミングはいくつかの単純な階層的なプログラム フロー構造で構成されており、「シーケンス」、「条件分岐」、「ループ」の 3 つのカテゴリに分類できます。
シーケンスとは、プログラムの通常の実行モードを指し、1 つの命令が実行された後、次の命令が実行されます。
条件分岐は、プログラムの状態に応じて、複数のプログラムの中から実行する 1 つを選択するもので、一般に if、switch/case などの相対語を使用して識別されます。
ループとは、特定の条件が満たされるまで、またはコレクション内のすべての要素が処理された後に終了するまで、特定のプログラムを実行することを指し、一般に for や while などのキーワードで識別されます。
さらに、プログラミング言語の構文により、プログラムをキーワードのペアで囲んで構造を形成できる場合、この構造を「ブロック構造」と呼びます。たとえば、C では中括弧 {...} で囲まれたプログラムなどです。言語。
構造化プログラミング パラダイムの最も価値のある部分は、「テスト可能なプログラム ユニット」を作成できることです。同様に、これが、アーキテクチャ設計の分野で機能分割が常にベスト プラクティスである理由です。
1-2. オブジェクト指向プログラミング
オブジェクト指向プログラミングとは正確には何ですか? 業界では、この問題についてさまざまな見解や意見があります。ただし、ソフトウェア アーキテクトにとって、その意味は非常に明確であるはずです。
オブジェクト指向プログラミングとは、オブジェクトによってソース コードの依存関係を制御する機能です。この機能により、ソフトウェア アーキテクトは、高レベルの戦略的コンポーネントを低レベルの実装コンポーネントから分離するプラグイン アーキテクチャを構築できます。また、基礎となるコンポーネントも、プラグインにコンパイルできるため、高レベルのコンポーネントから独立した開発と展開が可能になります。
1-3. 関数型プログラミング
関数型プログラミングでは、すべてのプログラムを関数操作として扱い、「状態」や「可変オブジェクト」の使用を回避します。
命令型プログラミングと比較すると、関数型プログラミングでは、実行プロセスではなくプログラムの実行結果に重点が置かれ、複数の単純な実行ユニットを使用して計算結果を段階的に進歩させ、複雑な演算を直接ではなく層ごとに推定することを推奨しています。複雑な実行プロセスの設計。
関数型プログラミングでは、関数が最も重要です。つまり、関数は他の関数の入力パラメーター値として使用したり、関数から値を返したり、変更したり、変数に割り当てたりすることができます。
1-4. まとめ
構造化プログラミング、オブジェクト指向プログラミング、関数型プログラミングの 3 つのプログラミング パラダイムはすべて、作成されるプログラムに制限を課します。各パラダイムは、コードを記述する特定の方法を制約します。
構造化プログラミングは、プログラム制御の直接転送 (つまり、goto ステートメント) に限定されます。
オブジェクト指向プログラミングでは、プログラム制御 (つまりポインタ) の間接的な転送が制限されます。
関数型プログラミングは、プログラム内の代入演算を制限するものです。
言い換えれば、フレームワークであれプログラミング パラダイムであれ、核となるのは一種の仕様と制約であり、この制約の根底にある指導的なイデオロギーは「何をしてはいけないか」です。
2. 設計原則
2-1. 概要
設計原則の主な機能は、データと関数をクラスに編成する方法を伝えることです (ここでは「クラス」という言葉が使用されていますが、これから説明する設計原則がオブジェクト指向プログラミングにのみ適用できるという意味ではないことに注意してください)ここで、クラスとは単にデータと関数のグループを表し、これらのクラスをプログラムに組み合わせる方法を示します。
これらの設計原則の目的は主に次の点から構成されます。
1. ソフトウェアを柔軟かつ低コストで変更できるようにする。
2. ソフトウェアをより読みやすく、保守しやすくします。
3. 複数のソフトウェア システムで再利用できるコンポーネントを構築します。
2-2. 内容
SRP: 単一責任原則。ソフトウェア システムが「最適なアーキテクチャ」を実現できるかどうかは、システムの内部モジュールがどのように編成されているかによって決まります。したがって、「最適なアーキテクチャ」を実現するには、ソフトウェアの各モジュールが変更される理由が 1 つだけであることを確認する必要があります。言い換えれば、各モジュールは 1 つのことだけを担当します。
OCP: オープンクローズの原則。ソフトウェアは拡張に対してオープンである必要がありますが、変更に対してはクローズである必要があります。ソフトウェア システムがより柔軟に変更に対応できるようにしたい場合は、アーキテクチャを設計する際に、新しいコードを追加することでシステムの動作を変更できるようにし、元のコードの変更をできるだけ避ける必要があります。
LSP: リスコフ置換原理。基本クラスを参照するすべての場所は、そのサブクラスのオブジェクトを透過的に使用できる必要があります。別の観点から見ると、この原則は、置き換え可能なコンポーネントを使用してソフトウェア システムを構築する場合、これらのコンポーネントは同じ規約に従う必要があることを意味します。 . これらのコンポーネントを相互に置き換えることができるようにします。
ISP: インターフェース分離原則。この設計原則は主に、ソフトウェア設計者が設計内で不必要な依存関係を避け、無駄なメソッドや関数の使用を避けるように努めるべきであると警告しています。
DIP: 依存性逆転の原則。この設計原則では、高レベルの戦略コードは低レベルの詳細を実装するコードに依存すべきではなく、低レベルの詳細を実装するコードは高レベルの戦略コードに依存する必要があると規定しています。