読書記録 C#実践開発手法 第１部-第2章
第2章は依存関係と階層化でした。
今回の読書記録では、個人的に勉強になったと感じた依存関係についてまとめておきます。
クラス間の依存関係
不適切な依存関係を持つソフトウェアの保守は大変になります。
一部の変更が意図しない箇所に影響したり、別のクラスやDLLを使用する際に余分なリファクタリングが必要になるからです。
まずは不適切な例を示します。
public class ControllerClass { private readonly ServiceClass service; public ControllerClass() { this.service = new ServiceClass(); } public void ChangePassword(Guid userID, string NewPass) { var userRepo = new UserRepository(); var user = userRepo.GetByID(userID); this.service.ChangeUserPassword(user, newPass); } }
この例のように、使用したいクラスControllerClassの中でServiceClassとUserRepositoryという二つのクラスが使用されています。
要するにControllerClassが二つのクラスに依存しています。
この状態では、ControllerClassを使うときにはこの二つのクラスが必ず必要になるため、単体テストや移植が難しくなってしまっています。
この根本的な原因は、ControllerClassが二つのクラスを直接生成しているためであります。
この問題を解決するために、今回は依存性の注入(DI)を適用します。
全体的な流れとしては、二つのクラスそれぞれに適切なインタフェースを設計し、ControllerClassは設計したインタフェースに依存するようにします。
リファクタリングしたコードが次の通りです。
public class ControllerClass { //ServiceClassはIserviceClassインタフェースを持つ private readonly IServiceClass service; public ControllerClass(IServiceClass ser) { if(ser == null) //何らかの例外処理 this.service = ser; } public void ChangePassword(Guid userID, string NewPass) { //UserRepositoryはIServiceClassに含まれるようになった this.service.ChangeUserPassword(userID,NewPass); } }
このようにすることで、ServiceClassとUserRepositoryの実装が変わっても、インタフェース仕様さえ守っていれば
ControllerClassから問題なく使用できます。
また、コンストラクタ内でnullチェックすることで、以降の処理で例外を危惧するコストを抑えることもできます。
このように、IServiceClassに対する依存性を注入されることで変更に強いクラスになります。
アセンブリ間の依存関係
クラス間の依存関係では、あるクラスが別のクラスに依存するときには、実体に依存するのではなくインタフェースに依存する
ほうが良い、ということについて述べました。
これをアセンブリレベルで実現するには、インタフェースと実装を別のアセンブリにすることで問題の解決を図ります。
この方法の利点として
- 実体に直接アクセスできなくなるため不適切な生成(安直なnew構文)が使えない
- 別の依存関係を注入するとき一つのアセンブリが膨張することを防ぐ
の２点があります。
インタフェースと実体が同じアセンブリにある悪いパターンを「Entourageパターン」、別である良いパターンを「Stairwayパターン」と呼ぶそうです。
以上になります。
次回の更新は1/27を予定しております。
読書記録 C#実践開発手法 第１部-第１章
予定していた日付より早まりましたが、第１部「アジャイルの基礎」の第１章「スクラムの紹介」を読み終わりました。
この本の最終的なゴールは変更に強いコードを作成するノウハウの紹介、ということになるそうなので、その第一歩としてソフトウェアの開発体系の紹介をしていました。驚きなのは、作者がウォーターフォールな開発を完全に否定しているところで、アジャイル開発を推しているところでした。
本章のざっくりとしたテーマは、システムの開発を進めるにあたり、作業の細分化や技術者への割り当て、工数見積もりの指標策定、フィーチャーの完成をいかに定義するかなど、システム開発を定量的に進めることで、見通しが立ちやすく、スケジュールの変更にも柔軟に対応できるようにする。というものでした。
個人的に気になった点として、各技術者の開発速度を実装したストーリーのポイントから算出して、次のストーリーの割り振りや開発の遅れを見つける技法はぜひ日々の作業に取り入れたいところです。
次回の更新は1/5頃予定しています。
良いお年を。
