関心の分離を意識した名前設計で巨大クラスを爆殺する - Qiita

大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で、様々なクラスと密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、命名に関する考え方を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 巨大クラスを爆砕し、小さなクラス群に分割する。 クラス結合度を下げ、影響範囲を小さくすることで保守コストや変更コストを下げる。 ダメな例 例えばECサイトの「商品」を考えてみます。 よくありがちなのは、商品をそのまま「商品クラス」と設計してしまうこと。 単純な商品クラスは、往々にして出品、予約、注文、発送など、様々なユースケースのクラスと結合してしまいがちです。 商品クラス自体も、結合したクラスに関連する知識(ロジック)を持ち始め、どんどん巨大化複雑化していきます。

[paz3]

巨大クラス「商品」を関心の分離により「在庫品」「予約品」「注文品」「発送品」に分ける。同じユニークIDを使うことで一意性を確保できる。可能な限り具体的で意味範囲の狭い特化した名前を設計する。

[masuda220]

「名前を設計する」という表現がよいなあ。こうやって具体的で意味が明確なクラス名を見つけるのが、クラス設計のコツなんだよなあ。

[tattyu]

大量のクラスも限度を超えると糞と化すんだよな。なんでライブラリでも無いものに汎用性を求めてしまうんだろうか。

[swdrsker]

頭の中でわかっているけど最初からやれって言われても出来ない

[igrep]

"利用規約には、製品の取り扱いやルールに関して極めて厳密な言い回しで書かれており、特化した名前の参考になります。" なるほど。うまく設計すれば逆の現象も起こせるかも

[griefworker]

「命名」ではなく「名前を設計する」、という表現が良いな。

[d4-1977]

適切な名前をつけられるとき、理解できた感があるなあ（いま、名付けができないので理解できていない感が強いデス）

[takezaki]

関心の分離に貢献する名前を付与しても、「商品」というエンティティで共通化できる部分はあるんだよなあ

[ledsun]

商品の状態遷移の設計が必要そうに思える。と、思えるのは適切な名前をつけたからか

[xlc]

名前ではなく設計で解決すべき課題だと思うが。コーディングより先にDB設計があるべきで、であればトランザクションテーブルごとにモジュールは分かれるはず。コピペプログラマに丸投げしてるのかね。

[aobon700]

悪い人間だけを滅ぼせええええええ！！！！

[n314]

注文の仕様変更で、予約者数や発売日や在庫数や発送先住所で計算が変わる仕様になったら、まとめた方が楽だったとか思っちゃうんだよな〜。

[sasasin_net]

良き