こんな設計上の悩みをお持ちではありませんか?: 解答編

・設計上のお悩みの回答:その1(コンポーネント開発の実現)

Facade (ファサード) パターンを使うことで解決可能です。
コンポーネントを構成する各モジュールを外部から直接アクセスさせるのではなく、 玄関(Facade)役となるモジュールを設けて、当該モジュール経由でアクセスさせる方法です。





こうすることで、コンポーネントとしての公開インターフェースと、 コンポーネントの内部実装を切り離して管理することが可能となります。
公開インターフェースを担当するのが Facade であり、 既存のモジュール=内部実装はコンポーネント内部に閉じた構造となります。

このような形態をとることで、コードの可読性の向上等様々なメリットが生まれますが、最大のメリットは変化に強い構造となることです。
テスト自動化等の技術により、公開インターフェースである Facadeを守ることで、 内部実装を安全に改良することが可能となります。
デグレードの心配なくリファクタリングを施したり、機能を追加することができるようになります。


このようなコンポーネント開発の考え方の詳細については、こちらのトレーニングで紹介しています。

・設計上のお悩みの回答:その2(外部提供のAPI)

Adapter (アダプター) パターンを使うことで解決可能です。
外部ライブラリへの参照を各モジュール毎に行うのではなく、外部ライブラリアクセス専用の変換器(Adapter)役となるモジュールを用意して、 当該モジュール経由で外部ライブラリへとアクセスする方法です。




こうすることで、外部ライブラリの公開インターフェースへの依存関係を局所化し、 外部から提供される機能と、自前で実装する機能とを切り離して管理することが可能となります。
外部提供ライブラリへの依存関係を一手に担当するのが Adapter であり、 外部から提供されるインターフェースを、内部の独自インターフェースへと変換する意味を持ちます。

このような形態をとることでコードの可読性の向上等様々なメリットが生まれますが、最大のメリットは変化に強い構造となることです。
外部ライブラリのインターフェースが変更になっても、Adapter の実装を変更すればよくそれ以外のモジュールへと変更が波及することを防ぐことが可能となります。
また、Adapter 内部の参照先を切り替えることで外部提供ライブラリを差替えることができます。
特にテストにおいては、スタブと切り替えることで高速化や自動化に貢献することでしょう。


このようなコンポーネント開発の考え方の詳細については、こちらのトレーニングで紹介しています。

・設計上のお悩みの回答:その3(派生開発でコードが汚れる)

リファクタリングを用いることで解決可能です。





リファクタリングとは、機能追加することなく内部構造をキレイにする開発手法です。
維持する機能=インターフェースを自動化テストで固めておいて、テストを壊さないように内部構造に手を入れてゆきます。
変数名を読みやすいものに変えたり長すぎるメソッドを分割したりと、小さい単位から行うことが通常です。

リファクタリングの本質は、守るべきインターフェースを明確にする点にあります。
小さな内部メソッドのインターフェースを守りながら、メソッドの内部実装を修正することもあります。
大きな外部公開インターフェースを守りながら、内部のモジュール構造を修正することもあります。
いずれにしても、どこのインターフェースがどのような機能を提供すべきといった、モジュール間の責任構造を強く意識しながら開発を進めることで、 結果的に変化に強い構造へと成長させることが可能となります。

尚、リファクタリングを実施するにはインターフェースを明確にする他、当該インターフェースを自動化テストで守っておくことが必要となります。
その為、テスト駆動開発のような自動化テストを充実させる開発技法とセットで導入することが重要です。


このようなコンポーネント開発の考え方の詳細については、こちらのトレーニングで紹介しています。
問題編に戻る