アーキテクチャ基本技術
アーキテクチャ基本技術とは、ソフトウェアアーキテクチャを適切に構築するために必要な基礎原理です。適切にソフトウェアアーキテクチャを構築するには、基礎となるいくつかの原理に基づいて実行する必要があります。ソフトウェア開発の歴史の中で数多くのプログラマーが蓄積してきた実践的で膨大な経験に基づいている。ある問題に対する特定の解決策が他の方法より優れているという事実をプログラマが認識し、その解決策を何度も再利用してきたところ、それがまさに基本技法である。
抽象
抽象とは、概念的に明確な線引きを行うことです。線ずれによって、あるモジュールをそれ以外のモジュールから明確に区別する。抽象は思想と一般化という２つの観点からまとめられる。
思想
- 複雑な対象のいくつかの性質を捨てて特定の性質に注目するのだ。
- 不要なものを捨てて本質を把握するのだ。
一般化
- 具体的な対象から共通の性質を抽出し、より汎用的な概念に正式化するのだ。
- 他の複数の対象に集中するときに共通の性質を見つけ、共通点を組み合わせて汎用的な概念を構想する。
カプセル化
関連するデータとロジックをグループ化して1つのモジュールを定義します。関係性の強いデータとロジックをモジュールというシェルで包むことをカプセル化と呼ぶ。 グループ化を通じて関連する要素同士だけが特定の抽象概念を担当するようにモジュールに集める。これにより、次のような利点が得られます。
- 関連のない要素が混在しないため、コードが読みやすくなります。
- 変更時の影響はモジュールに限定されます。
- 影響度が明確になるので、コードの変更が容易になる。
- それぞれ独立した部品なので再利用性が高くなる。
- 小さな単位に分割されるので、複雑な問題に対処できる。
情報隠蔽
モジュールの実装は、そのモジュールを使用するクライアントから隠蔽されます。 モジュールがクライアントが知る必要のない内部の詳細部分を隠蔽すると、インタフェースが小さくなり、情報のやり取りが簡単になり、コード全体の複雑性を下げることができる。 情報隠蔽を実現するには、カプセル化を使用します。カプセル化と情報隠蔽はもともと異なる概念です。
- カプセル化
- 関係のある要素を集めてモジュール化するのだ。
- 関係の深いデータと関数を一箇所に集める。
- 情報隠蔽
- モジュールの内部状態や内部関数を隠蔽するのだ。
- 内部への外部からの直接アクセスをブロックする。
パッケージ化
モジュールを意味のある単位で次のすべてにグループ化します。これはソフトウェア全体を意味のある単位に分割することです。このように分割された単位をパッケージと呼ぶ。 ある程度大規模なソフトウェアになると、今回は大量に作成されたモジュールがむしろ複雑性を生み出す結果を招く。これがまさにパッケージだ。パッケージ化には次の利点があります。
- ソフトウェア全体がパッケージと呼ばれる小さな単位に分割されるため、複雑さが低くなります。
- パッケージ内に無関係なモジュールが混在しないため、モジュールを管理しやすくなります。
- 修正への影響度がパッケージ内にとどまる可能性が高いので、コードを変更しやすくなる。
- 依存関係が整理され、パッケージ単位で再使用しやすくなります。
関心の分離
関心とは、ソフトウェアの機能や目的を意味する。関心を分離するということは、各関心に関連するコードを集めて独立したモジュールにして他のコードから分離することを意味します。 設計技術では、パターンの大部分は関心の分離を実現するという目標を持っています。最も代表的なパターンがMVCパターンである。MVCパターンでは、ビジネスロジック、ユーザーの表示、入力処理を分離します。
充足性、完全性、プリミティブ性
カプセル化によって関連する要素は、特定の抽象概念を担当するモジュールに集まります。モジュールが担当する抽象の表現は十分で完全でプリミティブでなければなりません。 充足性とは、モジュールが表現したい抽象がそれを伝えるのに十分かどうかを意味します。たとえば、モジュールがコレクションを表現しているときにremoveが提供されても、addが提供されない場合は、コレクションであることを伝えるには不十分です。
完全性とは、モジュールが表現したい抽象がすべての特徴を備えているかを意味します。何か抜けたことなくすべてを備えていると、どのクライアントでも使いやすくなります。たとえば、モジュールがコレクションを表現しているときに要素の数を取得するサイズが提供されていない限り、完全であるとは限りません。
プリミティブ性とは、モジュールが表現したい抽象がすべて純粋であるかどうかを意味します。たとえば、モジュールがコレクションを表現しているときに1つのアイテムを追加するaddが提供されている場合、10個のアイテムを追加するadd10は必要ありません。抽象の純度という観点から見ると、むしろ不要な機能だ。
ポリシーと実装の分離
モジュールはポリシーまたは実装を扱います。ただし、1つのモジュールで両方を扱ってはいけません。
ポリシーモジュール
該当ソフトウェアの全体に依存するビジネスロジックやその他のモジュールのパラメータを選択する部分である。 該当ソフトウェアに特化している。そのソフトウェアに変更があると、ポリシーモジュールは変更を強制されます。
実装モジュール
ソフトウェアの前提に依存しない独立したロジック部分です。 特定のソフトウェアに依存しない純粋なモジュールなので、他のソフトウェアでも再利用できます。
インタフェースと実装の分離
モジュールは、インターフェース部分と実装部分の2つの別々の部分で構成されています。 インターフェース部分とは、モジュールが持つ機能を定義し、モジュールの使用方法を決める部分である。クライアントからアクセス可能な関数の円形で構成されています。 実装パーツとは、モジュールが持つ機能を実現するコード部分である。モジュールが内部で使用するロジックとデータが表示されます。実装部品はクライアントからアクセスできません。 モジュールのインターフェース仕様だけが提示されるので、シンプルで理解しやすくなり、モジュールを簡単に使用できる。使用法と機能の実現方法が互いに独立性で確保できる。 モジュール間の呼び出しは相互にインターフェースのみを使用します。インタフェースの実装は、インタフェースの背面に隠して、それを直接呼び出すことを許可しないようにします。
参照の単一性
モジュールの要素に関する宣言と定義は1回に制限されます。定義が1回という言葉は、例えば、変数値を初期化した場合、以降の値を変更しないという意味だ。これにより、数値の変化を追跡する必要がなくなり、直感的なコードになります。
基準透過性
- 呼び出しの結果がパラメータにのみ依存する：パラメータに同じ値を渡すと、常に同じ戻り値を返す、つまり戻り値がパラメータ値にのみ依存する特性です。 このような特性を指して純粋だと表現する。
- 呼び出しは他の機能の動作に影響を与えません：関数は副作用を持たない特性です。副作用とは、ある処理が状態の変更を引き起こして以後の処理結果に影響を与えることである。
分割征服
大きな問題をそれ自体で解決するには難しくなり、時間がかかります。最悪の場合、解決できない場合もある。規模が大きすぎるため問題が複雑すぎるからだ。制御しやすい規模まで問題を分割し、そこから着手する方式が効率的だ。
