「開放閉鎖原則」を含む日記 RSS

はてなキーワード: 開放閉鎖原則とは

2018-09-14

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

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

https://nekogata.hatenablog.com/entry/2018/09/10/163206

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

Notificationクラスが不親切。

Notificationクラスそもそも単一責任原則に反してない

開放閉鎖原則勘違いしてる

Notificationクラスと何のクラスが密結合なのか説明されてない

  • 『それ以前の問題というか「本来バラバラに書かれるべきものが、すべてここに書かれてて密結合しちゃってる」とみることができるかと思います。』?
  • 密結合というのであれば、コメント通知を変更した時にNotificationクラスとCommentクラスの両方に変更が生じてしまうことを示すべき

オブザーバーパターンが出てくる意味が分からない

今回の仕様を図で書くと

コメント→→→コメント通知

スター→→→スター通知

あしあと→→→あしあと通知

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

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

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

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

オブザーバー不要なのは当然。選択肢に出てくるほうがおかしい。

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

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

人間の可読性が考慮されてない

まとめ。

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

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん