インターフェイスに関する記述は基本的なこと、あるいは専門的すぎる内容が多かったため、インターフェイスについてはまとめず、デザインパターンのみについてまとめた。
はじめに
私は普段C#を使ったUnity開発に取り組んでいます。これまではどちらかと言えば、「良いコードを書きたい」というより、「バグがなくてきちっと動けばそれで良い」という考えでコードを書いてきたように思います。ただ、エンジニアとしてはそれではやはり不十分でしょう。そこで、『Adaptive Code ~ C#実践開発手法』を読んで勉強することにしました。
「アダプティブ」とは、コードを大幅に変更することなく、新しい要求や予想外のシナリオに対処する適応力のことです。
ただ、本書は基本的に.NET Frameworkでの開発を前提として書かれていますし1、文字数も多いので、自分にとって重要な箇所を抜き出してまとめながら学習を進めることは意味のあることだと思います。
今回のまとめは第4章の内容に当たります。
アダプティブデザインパターン
デザインパターンはうっかりすると使いすぎてしまうことがある。また、常に適用可能であるとは限らず、単純なソリューションのはずが、クラス、インターフェイス、間接化、抽象化だらけの意味もなく複雑なソリューションになってしまうこともある。
正しいパターンを適用する正しい場所を見つけることがポイント。
本章、あるいは本書に含まれるデザインパターンは、アダプティブコードの作成に役立つかどうかという観点から選択されている。
Null Object パターン
Null Objectパターンの目的は、nullオブジェクトをチェックするコードだらけになるのを防ぐこと。
戻り値がnull出ないことをすべてのクライアントがチェックして、NullReferenceExceptionのスローにつながるnullの逆参照を阻止する。
→サービスコードでNull Objectパターンを実装する。2
// サービスコードpublicclassUserRepository:IUserRepository{privateICollection<User>users;publicUserRepository{users=newList<User>{newUser(Guid.NewGuid()),newUser(Guid.NewGuid()),newUser(Guid.NewGuid()),newUser(Guid.NewGuid())};}publicIUserGetByID(GuiduserID){IUseruserFound=users.SingleOrDefault(user=>user.ID==userID);if(userFound==null){// ①userFound=newNullUser();}returnuserFound;}}// クライアントコードclassProgram{staticIUserRepositoryuserRepository=newUserRepository();staticvoidMain(string[]args){varuser=userRepository.GetByID(Guid.NewGuid());user.IncrementSessionTicket();// ②}}①:返されたUserオブジェクトが実際にnull参照かどうかをチェックして、null参照である場合は、NullUserというIUserのサブクラスのインスタンスを返す。可能な限り、すべてのメソッドを「何もしないメソッド」に近いものとしてオーバーライドするのがNullUserクラスの正しい実装である。
②:nullチェックの実行責任をサービスコードとしているので、ここではnullチェックは必要ない。
NullUserのコード↓
publicclassNullUser:User{publicvoidIncrementSessionTicket(){// 何もしない}}NullUserオブジェクトのメソッドまたはプロパティから別のオブジェクトへの参照を返すことが期待される場合も、常に、それらの型のNull Objectを実装を返すようにする。つまり、すべてのNUll Object実装で再帰的なNull Object実装を返す必要がある。これにより、クライアント側でnull参照をチェックする必要がなくなる。
これには、記述しなければならないユニットテストの数が少なくなるという利点もある。クライアントごとにチェックを実装する必要があるとき、そのチェックが存在することを確認するユニットテストも必要なので。この場合はリポジトリ実装が、NullUser実装が返されることを確認するためのユニットテストになる。
IsNull プロパティアンチパターン
Null Objectパターンでは、IsNullというBooleanプロパティがインターフェイスに必要になることがある。このインターフェイスの本来の実装はすべて、このプロパティに対してfalseの値を返し、このインターフェイスのNull Object実装はtrueの値を返す。以下は、先の例に基づいて、これがどのような仕組みになるのかを示す。
publicinterfaceIUser{voidIncrementSessionTicket();stringName{get;}boolIsNull{get;}}publicclassUser:IUser{･･･publicstringName{get;privateset;}publicvoidIncrementSessionTicket(){sessionExpiry.AddMinutes(30);}publicboolIsNull{get{returnfalse;}}privateDateTimesessionExpiry;}publicclassNullUser:IUser{publicvoidIncrementSessionTicket(){// 何もしない}publicboolIsNull{get{returnfalse;}}publicstringName{get{thrownewNotImplementedException();}}}このプロパティには、そもそもカプセル化を目的としているオブジェクトからロジックがこぼれ出てしまうという問題がある。例えば、本来の実装とNull Object実装とを区別するために、クライアントコードにif文が入り込むようになる。これでは、さまざまなクライアントに同じロジックが実装されるのを阻止するという、このデザインパターンのそもそもの目的が台無しになってしまう。以下のコードは、この問題がどのようなものであるかを示す。
staticvoidMain(string[]args){varuser=userRepository.GetByID(Guid.NewGuid());// Null Objectパターンを適用しないと、ここで例外がスローされるuser.IncrementSessionTicket();stringuserName;if(!user.IsNull){userName=user.Name;}else{userName="unknown";}Console.WriteLine("The user's name is {0}",userName);Console.ReadKey();}この問題を修正するには、NullUserクラスでnullユーザーの名前をカプセル化する。正しくカプセル化すれば、IsNullプロパティは不要になる。
publicclassNullUser:IUser{publicvoidIncrementSessionTicket(){// 何もしない}publicstringName{get{return"unknown";}}}staticvoidMain(string[]args){varuser=userRepository.GetByID(Guid.NewGuid());// Null Objectパターンを適用しないと、ここで例外がスローされるuser.IncrementSessionTicket();Console.WriteLine("The user's name is {0}",userName);Console.ReadKey();}Adapter パターン
Adapterパターンは、オブジェクトインスタンスが実装していないインターフェイスにクライアントが依存していたとしても、そのオブジェクトインスタンスをクライアントに提供できるようにするデザインパターンである。このデザインパターンが使用されるのは、一般に、目的のインターフェイスに合わせてターゲットクラスを変更することが不可能な場合である(クラスがsealedで宣言されているとか、手出しできないアセンブリに含まれているとか)。Adapterパターンの実装方法には、Class Adapterパターンを使用する方法と、Object Adapterパターンを使用する方法の2種類がある。
Class Adapterパターン
Class Adapterパターンは、アダプター(実装)としての継承を利用する。つまり、クライアントが期待しているインターフェイスに適用させる必要があるのは、ターゲットクラスのサブクラスである。実際の仕組みは以下のようになる。
publicclassAdaptee{publicvoidMethodB(){}}publicclassAdapter:Adaptee{publicvoidMethodA(){MethodB();}}// クライアントコードclassProgram{staticAdapterdependency=newAdapter();staticvoidMain(string[]args){dependency.MethodA();}}Class Adapterパターンは、それほど利用されない。これは主に、開発者が継承よりも合成を優先するように教えられているため。継承はホワイトボックスの再利用であり、サブクラスをそのインターフェイスだけでなくクラスの実装にも依存させる。合成はブラックボックスの再利用であり、依存関係はインターフェイスに限定されるため、クライアントに悪影響をおよぼさずに実装を変更することが可能である。
※「ホワイトボックスの再利用」と「ブラックボックスの再利用」の2つの擁護派それぞれ、実装の内部を確認できることと、実装の内部が調べられないように隠されていることを意味する。
Object Adapterパターン
Adapterパターンとしてはこちらの方が一般的。
Object Adapterパターンは、合成を利用することで、インターフェイスのメソッドを外側のカプセル化されているオブジェクトへ委譲(デリゲート)する。
以下は、Object Adapterパターンの実際の仕組みを示す。アダプターはターゲットクラスをコンストラクターのパラメーターとして受け取り、それに対して委譲する。
publicinterfaceIExpectedInterface{voidMethodA();}publicclassAdapter:IExpectedInterface{privateTargetClasstarget;publicAdapter(TargetClasstarget){this.target=target;}publicvoidMethodA{target.MethodB();}}publicclassTargetClass{publicvoidMethodB(){}}// クライアントコードclassProgram{staticIExpectedInterfacedependency=newAdapter(newTargetClass());staticvoidMain(stirng[]args){dependency.MethodA();}}Strategy パターン
Strategyパターンでは、指定された1つ以上の「戦略」に基づいてクラスの振る舞いを変更できる。使用するのは、オブジェクトの状態に応じてクラスの振る舞いを切り替える必要がある場合。この振る舞いをクラスの現在の状態に応じて実行時に変更できる場合、Strategyパターンはその振る舞いをカプセル化するのに最適。以下は、Strategyパターンをインターフェイスとして定義し、クラスで使用する方法を示す。
publicinterfaceIStrategy{voidExecute();}publicclassConcreteStrategyA:IStrategy{publicvoidExecute(){Console.WriteLine("ConcreteStrategyA.Execute()");}}publicclassConcreteStrategyB:IStrategy{publicvoidExecute(){Console.WriteLine("ConcreteStrategyB.Execute()");}}publicclassContext{privatereadonlyIStrategystrategyA=newConcreteStrategyA();privatereadonlyIStrategystrategyB=newConcreteStrategyB();privateIStrategycurrentStrategy;publicContext(){currentStrategy=strategyA;}publicvoidDoSomething(){currentStrategy.Execute();// 呼び出しごとに戦略(ストラテジー)を切り替えるcurrentStrategy=(currentStrategy==strategyA)?strategyB:strategyA;}}さらなる汎用性を求めて
インターフェイスには、ダックタイピングやミックスインなど、より専門的な機能があり、本書はそれについてもまとめられているが、そうした機能が利用されることはまれなのでここでは省略する。
まとめ
インターフェイスは、クラスの多様性をカプセル化することを可能にするポリモーフィズムを促進し、デザインパターンを成長させる原動力となる。それでいて、インターフェイスは実際には何もしない。
インターフェイスは実装がなければ使いものにならないことを思い出してほしい。しかし、インターフェイスがなければ、実装とそれらに関連する依存関係がコードに染みついてとれなくなり、保守や拡張が難しくなってしまう。うまく配置されたインターフェイスは、サービスコードのダーティな実装上の詳細と、うまく構造化されたクライアントとを隔てる防壁となる。