こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
今日はイベントタイトル通り、オブジェクト指向のこころを読んでいくイベントでした。今日は第12章でした。
会の様子
章で印象に残ったところの議論〜凝集度とは別に耐障害性を加味した設計を意識する必要はあるのか？〜
高凝集度なアーキテクチャを一定犠牲にしてでも、将来的には耐障害性を重視したほうがよいみたいなことはないのか？という話がありました。
ただし、適切な場所で落ちたり、システムによっては落ちずにそのままシステムが継続したりといった耐障害性が高い設計をするためには、テスト容易性や再利用性を犠牲にする必要はないので、耐障害性を意識するために凝集度を犠牲にするような状況は訪れないのではないか？ということになりました。
一方で、効率性や性能向上のために耐障害性を犠牲にすることはあるよね、という話も出ていました。
章で印象に残ったところの議論〜とりあえずインターフェースを切ってその後に抽象クラスというのはあり？〜
本書でこういうのもありかもしれないと書かれていたポイントとして、インターフェースを切ってその後に抽象クラスを切るというのは実践できそうか？という話が出ていました。
ただ、抽象度がばらばらになったり、コードを後で追っていくときに階層が深くなる&意味を追うために図で整理が必要になったりする、ということが起きやすいので、あんまりやってみてもおすすめはできないという意見がありました。
本書は書かれていたのが20年前近いので、安易な共通化のための継承に対して警鐘を鳴らしてはいるもののそこまで継承の悪さはひろまっていないみたいな時代背景があるが故の記述なのかな？という推測もありました。
応用問題1
いつもの通り「どういう意味でしょうか？」系の質問だったので、飛ばそうという話になりました。
応用問題2
inprementerを増やしやすく拡張性には優れていますが、inprementer自体が変わったり、概念モデルベースで見直しが走るような変更には弱いので、Open-Closedになっているという話がありました。
あなたの意見1
ビジネスの人たちとTOCやポリシーパターンを活用して会話したり、経験によるものが大きいという話は大前提としてありつつ、Making Softwareで言われているようにhot spotを意識してYAGNIを実践すべきじゃないか？という話が出ていました。
また、とりあえずインターフェースを切っておくみたいな感覚が近そうだという話もありました。
あなたの意見2
ベターですが、最初からパターンありきで考えるなどは誤用の例なのかな？という話が出ていました。
また、最初から詳細に立ち入るためにデザインパターンを活用するのもまずそうだという意見がありました。
誤用例を色々考えると、最終的には共通言語のような形で使うのかなあ？という話になりましたが、そこまで幅広く認知されているものでもないし、チームの中でデザインパターンを共通言語として使う機会ははたしてどれくらいあるんだろう？という疑問がありそうだという結論で終わりました。
全体を通した感想
今回は問題が少なかったのでスムーズに終わるかと思いきや、脱線に脱線を重ねて結果的にいつも通り時間オーバーになったのは面白かったです笑
品質特性の話や抽象クラスとインターフェースの話、どこまでYAGNIを実践するのかのバランスの話など、議論の頻出テーマの話を中心に色々と話しができたのが特に印象的でした。
