天の月

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

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

yr-camp.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

オブジェクト指向のこころを読んでいく会です。今回は第6章と第7章を読んでいきました。

会の様子

第5章の問題を解く

前回はNOOの話で盛り上がりすぎて問題を解けなかったので、今回は問題を解いていくところからスタートしました。

応用問題1

書籍の内容から回答するのであれば、パターンという形で言語化することで実装に込められた意図や解決したい課題が明確化されるため、パターンを使うことで明らかなものを見失うことを避けられるという話がありました。

一方で、パターンをとりあえず使ってしまうみたいな状態に陥ったり、慣れ親しんできたパターンを盲目的に使う状態になってしまうリスクもあるため、そう考えるとパターンで明らかなものを見失うことを避けられるというのは論理が通らない気がするという意見も出ていました。
ただし、そういった状況になっているのは、そもそもパターンを使っていると言えないのではないか?という話があり、パターンの目的に対してフォーカスしてこそパターンを使っていると言えるのではないか?ということになりました。

また、CSD研修ではパターンを適用してみることで現象の理解を深めるという話もあったそうで、これは「課題を考えろ」というけれど、まず解決策を打ってみてその後に解像度があがった状態で課題を改めて考えるみたいなアプローチも有用なことを示唆していそうだという話をしていきました。

応用問題2

優れた実装や問題解決策を観察することによって生まれた、でよさそうという話になりました。

応用問題3

最初は書籍の内容にしたがって、フォースを事細かに記述すると因果関係が導き出されるという話が出ていたのですが、フォースって無数にある解決策を制限するようなものなので因果関係とは関係なくないか?という話になりました。

因果関係を制限するようなものがフォースなのでは?という意見もあったのですが、因果関係って何かによって制限されることはないものでは?(例えば薬Aを飲むと風邪が治るという事象に対して薬を買う予算がないというフォースが働いても、薬Aで風邪が治るという因果関係は変わらない)という話になり、訳語の因果関係という単語ではなく、原文のconsequenceから改めて考えることにしました。

その結果、因果関係ではなく結果という単語で考えると、パターンが解決したい問題を解決する方法をフォースが制限して、結果が生まれるという風に解釈できそうだという結論で落ち着きました。(GOFデザインパターン本でも「結果」と訳されているので、consequenceはやはり因果関係として捉えなくてもよさそうだという話もありました。)

応用問題4

変更されやすい要素(変更される可能性のある要素)であるDBやOSごとのパス記法ルールが流動的要素であり、その要素を利用したい外部が内部の変更を気にしなくてよいように隠蔽化することを意味しているという話が出ました。

応用問題5

最近話題になっていたブログの内容を中心に話をしていきました。

mametter.hatenablog.com

第6章と第7章の応用問題

続いて、第6章と第7章の応用問題を解いていきました。5章の応用問題の議論で大分時間を使ったため、現実世界でパターンを説明すると?の問題を解いていきました。

facadeパターンを現実世界で例えると?(応用問題2)

割となんでもfacadeになりそうだという話になり、

  • 会計士に領収書を提出して税務処理をやってもらう
  • つみたてNISA
  • 実家にいるとき、親にご飯を作ってもらうようにお願いする

などが例として挙がっていました。

adapterパターンを現実世界で例えると?(応用問題2)

こちらは、

などが例として挙がっていました。

会全体を通した感想

今回も問題+問題から連想されるトークが盛り上がりすぎて、本の感想や今回のお題だった章の話が全然できませんでした笑

今回は、よくわからないことに対して向き合い、考えをモブで深めていく経験ができたのも非常によかったです。