長いので章ごとにしてます。
8 密結合 ―絡まって解きほぐせない構造―
8.1 密結合と責務
- リスト8.1… もーどうして、割引管理が商品を一個ずつ受け取るの…！カゴとかリストとかじゃないの？とか思っちゃいます。
- スタートがおかしすぎてバランス取れる自信が><
- addするときに割引情報渡すの？ううむ……。
- リスト8.2… ん？SummarDiscountManagerがDiscountManagerを所有…？
意味がわからん…。コンポジション構造かな？ - 夏季限定割引の仕様にわざわざ
通常割引と同じって…。これを忠実に実装してるんですね…。 - マイナス価格の商品………ううむ……。
8.1.1 発生する様々なバグ
- 夏季限定割引の仕様にわざわざ
通常割引と同じとあったので、コード変更なしで適用されてよかった！…とはならなかったか。だよね、だよね…。
8.1.2 ロジックの置き場所がちぐはぐ
- せやなw
8.1.3 単一責任の原則
- 借金の例は…世の中そんな単純じゃないと思いますね。世の中はひどい商売をしてるひともいますから。
8.1.4 単一責任の原則違反で生まれる悪魔
- 相変わらず言い方が強め…。
8.1.5 責務が単一になるようクラスを設計する
- 定価をクラスに？Priceクラスを作って、商品がそれを属性に持つのじゃダメ？
- 割引価格クラス？
- 自分だったら…
- 割引上限もあるので、ショッピングカートに紐付けるかも。
- 季節の割引は…年によって変わりそうなので、もしかすると年を入れるかも？
8.1.6 DRY原則の誤用
- DRYにしようとしてしくじった系だと…。
- 概念が違うかどうか、それの判断って結構難しいですよね。
- 違うものをくっつけられて、今も苦労してます><
Column クソコード動画「共通化の罠」
- 前職の古いコードを思い出しました…。
- 反面教師だったと思います。
- あとからビジネス概念が変わるケースは……もうどうにもならないですね><
- 最初から入ってても、ガラッと変わりますもん。
- 全く違うものになったのに、ビジネス上は同じ名前。絶対混乱するのに同じに扱おうとして…結構大変…。
- スクリーン名とIDのように名前を分割してやりたいです…。
8.2 密結合の各種事例と対処方法
8.2.1 継承に絡む密結合
Column クソコード動画「継承」
- それぞれの責任の場所のコードを変えて！に尽きる…。
8.2.2 インスタンス変数ごとにクラス分割可能なロジック
- リスト8.18…まぁ、ありますよね><
- 「影響スケッチ」よく描くけどそんな名前だったとは…。しかもツールがあったりするかもだと…？
8.2.3 なんでもpublicで密結合
- ヒットポイント回復クラス？
- Rubyでプライベートなクラスってどーやるんだ？
- docs.ruby-lang.org
- あんまり大規模なものをやってないせいか、必要に感じたことがありません。
- なんにも書かないとpackage private。言語としてはよいデフォルトを示してますよねえ…。
- ただアクセス修飾子にもpackage privateを用意してほしいような…。書かないと何になるのか、混乱しちゃいそう。
8.2.4 privateメソッドだらけ
- プライベートメソッドを多く持つクラスは、多くの責務を負ってしまってるかも？って、たしかにそうなりそうですね…φ(･･
8.2.5 高凝集の誤解から来る密結合
- なるほど、高凝集と密結合、誤解しそうですねw
- しかし、販売価格に集めるかなあ…とも思いますが、近いことは大いにありそうです。
8.2.6 スマートUI
- あああ……よくやりそうになる…！
- 一応、表示に直結するものだけにして、その表示の意味合い的なものはデコレータに持っていくようにしているけども…。
- 意味に名前をつけられないときには放置しちゃいますね><
8.2.7 巨大データクラス
- ああ…わかる、これつらい><
- 明らかにこのクラスから分離したほうがいいだろー？みたいなものがくっついて、ずっと困ってる><
8.2.8 トランザクションスクリプトパターン
- Railsで、コントローラのメソッドにすべての処理が書かれてるのはこれにあたるかしら…。
- こういうのは、テストがホント書きづらくて…何があってもおかしくない…。
- 少しずつ直してます。
8.2.9 神クラス
- これは…幸い会ったことがないかも。
8.2.10 密結合クラスの対処法
- 機能変更に関係した箇所は、少しずつ少しずつテストを足して、細かくメソッドに分けていったりしながらやってます。
