getterはevilっていう話へのモヤりとアドバイス
単純なgetterは悪なので何らかの計算結果を返すべしって話にモヤる理由がなんとなくわかってきたかも プロパティの隠蔽が出来ているなら、そのクラスの利用者からはプロパティの値をそのまま返してるかどうかはわからないはずなので、getterを一律に禁止するのはそれこそカプセル化の失敗を意味する?
2020-02-17 00:21:50@strtyuu たぶんその理解で正しいと思います。getFirstName, getLastName, getFullName があったとして、getFullName はおそらく文字列結合をやってる、他の2つはおそらく内部に保持してるやつをそのまま返してるけど、それを使う側が知る必要ない的な感じ。
2020-02-17 12:24:09@strtyuu データ構造自体とそれを使ったロジックがどっちが安定しているか、要はどっちからどっちに依存させたいかみたいな話で、構造のほうが安定でロジックが変化しやすいんだったら構造側はgetter提供してロジックがそれに依存するっていうほうがいいとは思いますね。納期計算は日付型に依存する的な。
2020-02-17 12:29:12@strtyuu ロジックが漏れるというより、getterがただの値を返し、その値を利用した計算処理が外部にたくさんある(依存がたくさんある)と、変更が難しくなってしまうっていう話が getter は evil だという話だと理解しています
2020-02-17 00:43:17@tenjuu99 僕の言葉遣いが雑すぎましたね〜〜 > ロジックが外に漏れるのがなぜリスクなのか これに関してはその値に依存しているロジックがいたるところにあると変更の時に大変になるという一点でリスクだと思ってたんですが、すえなみさんのリプでもっと深い考え方がありそうだなと思ったので今は説明できない
2020-02-17 12:49:18getter禁止的なやつは、DBテーブルと1:1に対応するクラスをまず作るという文化と内部に持つプロパティと1:1に対応するメソッドを作りそれをgetter/setterと呼ぶという文化が悪魔合体した結果生まれたキメラコードへの対抗策として生まれたものだと思ってるので、キメラ以外への効き目はアレ
2020-02-17 13:05:12