天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

オブジェクト指向のこころを読む会 Vol.11に参加してきた

yr-camp.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。(なお、コピーがついているのはわざとということです笑)

会の概要

会のタイトル通りオブジェクト指向のこころを読んでいくイベントです。

会の様子

応用問題1

意味としては関連または依存し合うオブジェクトをカプセル化するパターンで、例としてはOSごとに挙動差異があるような場合などはAbstract Factoryが使えるのではないか?という話になりました。

余談〜Abstract Factoryは移植性を高めるか?〜

移植性を高めたい場合、Abstract Factoryは候補手の一つとはなりそうだけれども、移植性を高めたいならAbstract Factoryを使うしかないという訳ではなさそうだという話が出ていました。(1つインターフェースを噛ませたりするだけでも移植性は高まる)

余談〜図11.7はコンポジションが良い?集約が良い?〜

まず本の例で考えると、ライフサイクルをともにしているように思えるのでコンポジションが良さそうに思えるのですが、LRPDを作ってからPrinterDriverがLRPDを使うためにアダプターをかませているのでコンポジションではなく集約の方がいいのではないか?という話になりました。

また、結合性をまずは低く実装したいという意味で、とりあえず最初は集約から実装しようという考え方自体は悪くなさそうだという話もありました。

あなたの意見1

ファクトリが抽象クラスになっていて、その抽象クラスが具象クラスを生成するからこのような命名規則になっているという誤解を生み出しそうなので、できればFactory Interfaceなどといった名前のほうが良さそうに思えるという意見が挙がっていました。

あなたの意見2

Switchで振る舞いが変更されることに加えて、オブジェクト生成のバリエーションが増えたり減ったりするのであればAbstract Factoryは使いたくなるのかな?という話をしていきました。

また、実務ではあまりAbstract Factoryを使わないという方がいて、

  • フレームワーク側で吸収している可能性がある
  • OS間の差異吸収などMainに近い部分の処理で使うイメージが多いので、既存システムのリプレイスとかだと使わないかも知れない

という話がありました。
加えて、コンストラクタにif文などを書いてオブジェクトの生成をしているような場合、Abstract Factoryを使うと良いのではないか?という話もありました。

会全体を通した感想

今日は問題も少なかったので、時間との格闘をすることなく、雑談多めで楽しくイベント参加することができました。

次回はエアコンでモデリング大会してみようという話になったので、腕を奮って参加しようと思います笑