「開発現場で役立たせるための設計原則とパターン」への反論

2018-09-14

開発現場で役立たせるための設計原則とパターン

この記事がはてブで大絶賛されてるが、個人的にはセンス無いなーと感じたので言語化してみる。

処理を見るに「NotificationPoster」的な名前のstaticクラスにすべき
もしくは「Notification」って名前のまま行くなら
- 通知種別ごとにコンストラクタ分けて、そこではbodyとtarget_usersの生成のみ行う
- コンストラクタとは別にPost()メソッド作って、そこでNotificationTable.Insert!()呼ぶ

Wikipediaを参照すると分かるが、開放閉鎖原則には継承を伴う
今回の例だと、Notificationクラスを抽象クラスにし、サブクラスとして「CommentNotification」や「StarNotification」を作るのが開放閉鎖原則
そうすることで、将来「あしあと通知」が追加された場合も既存クラスを修正することなく「FootprintNotification」の追加だけで修正が可能となる

今回の仕様を図で書くと

コメント→→→コメント通知
スター→→→スター通知
あしあと→→→あしあと通知

みたいな感じになるとする。

すると、今回スライドで問題視しているのは矢印の右側の通知の部分が1クラスに共通化されている点。

しかし、オブザーバーパターンの出番は図の矢印の部分が絡まり合って処理が複雑になってしまった場合。

今回は1つのイベントから複数のリアクションが発生することは想定しないので

そもそも問題認識(通知部分が問題)と解決策(矢印部分を解決)がズレてるから話がおかしな方向にいってる。

Notificationクラスのサブクラスを作ろう、ならまだ分かる。

質疑応答で「コメント自体の変更とコメント通知の変更が1つのクラスに存在してるのは責務が複数では？」とい質問に対し「どんな変更を予期するか次第」と答えているが、例え質問のような変更が発生する可能性が0だったとしてもこの2つの処理はクラスを分けるべき
なぜなら通知というのはコメントに付加されているオマケみたいなものなので、これをCommentクラスの中にがっつり描くのは不自然。まだ平気だが、将来Commentクラスが神クラスになりそうな匂いがする。
スライドの結論の設計だと確かにコメント通知の変更に必要な変更はCommetnクラスだけなのだが、その後にNotificationクラスを呼んでいるため、結局はNotificationクラスの中も確認する必要を捨てきれない
- 例えばNotificationクラスにCommentを引数とするコンストラクタがあれば、Notificationクラスを見るだけで「変更はこのクラスだけだな」ということが明確になる

確かに設計を言語化するのは大事だが、言語化というのは「それっぽいことは幾らでも言える」危険性がある。そもそもプログラミングというのは芸術であり文学なんだから、センス無いのに言語化を頑張っても「一見それっぽく聞こえるけど間違ってる説明」しか出てこない。