Commentどうもこんにちは。引き続き読書会を開催しています。題材としては「デザインパターンとともに学ぶオブジェクト指向のこころ」です。事前準備(一応途中参加も受け付けております。外部からの参加も全然OKです)appear.inにて参加(参加希望の方はfuruya0102@growth-and.comまでご連絡ください)音声通話の準備(マイクとヘッドホンの準備。今回は説明者は古家がやりました。この章から本格的にデザインパターンを紹介していく流れです。今までの前振りも重要ではありますがデザインパターンの森を見て木を見ていない状態でふわっとした感覚だけが漂っている感じでした。今回からは一つ一つのデザインパターンにフォーカスを当てて、現実に存在し得る厄介な問題と、その解決策に関して述べていくスタイルとなっていきます。パターンの特徴や構造を述べられている箇所に付せんでも貼っておくと後でリファレンス的な使い方も出来るようになるのではないでしょうか。Facadeパターン玄関の正面とか、見せかけという意味のパターンです。詳細な仕様を忠実に再現しなければいけないクラスライブラリなどがあった際に、そういうものを全員が共有しなければいけない状態であると属人化(その仕様を詳細に理解している人しか触れない)してしまったり、全員が専門家にならないと開発を共有出来ません。いうものを隠ぺいしてしまい、メンテナンスを一人に任せることで、具体的な手順や不要な処理を考えることなくアクセスできるようになる。ファサード経由のメソッドにすべて任せてしまえばそのファサードにはログ採取や速度解析などの付加価値を入れることだってできます。データベースにアクセスする際にエンティティやデータベースのコネクションなどを全員が理解するよりもDatabaseFacadeを作って、そこにアクセスを一任してしまう等の使い方があります。本書ではDatabaseFacadeという名前でしたが、こういうのはリポジトリパターンとも呼ばれますね。リポジトリパターンは抽象化レイヤを置きますが、ファサードは置かなくてもよいという違いこそありますが。ちなみに7章Adapterにもいえることで、本書には載っていない暗黙の指針ですが、インターフェイスを置く際にはStairway(階段)パターンとEntourage(取り巻き)アンチパターンにも注意しましょう。インターフェイスで分離したというのに、その実装をインターフェイスと同じアセンブリで持ってしまっていると、取り巻きのようにくっついてきてしまいます。いうものは別アセンブリに定義していつでも切り離せるような作りにしておくことで依存関係を効率的にコントロールできます。AdapterパターンFacadeパターンと対比させて述べられているパターンです。Facadeとよく似ていますが、Facadeは複雑な手順や不要な処理を隠ぺいする目的で、別にインターフェイスである必要もありませんが、Adapterパターンは合致しないインターフェイスを適合させる意味で用います。Adapterには2種類あり、ObjectをコンポジションしてしまうObjectAdapterとクラス継承を用いるClassAdapterがあります。どちらも一長一短ではありますが、個人的な感覚としては基本的にはObjectAdapterを使い、protectedメソッドやvirtualメソッドなどでカスタマイズする必要性が出てきたらClassAdapterに切り替える的な使い方をする気がします。次回について次回は6月26日になります。対象範囲は8章の視野を広げると9章のStrategyパターンで説明を井上さんに行っていただく予定です。authorfuruya0102C#とオブジェクト指向が大好き。炎上しないプロジェクトにどうやったら導けるかを常日頃考えている。保守性の悪いコードを見ると蕁麻疹を出し泡を吹き発作の末倒れる。プロジェクトが混乱しているとPMを憎むようになる。得意料理はきんぴらゴボウ。参加費は無料なので私に声かけていただければ。コメントデータの処理方法の詳細はこちらをご覧ください。Top第二回読書会を開催しました(デザインパターンとともに学ぶオブジェクト指向のこころ)。RSSWordPress.org。