getterはevilっていう話へのモヤりとアドバイス

getterを使って結合度を下げた方がいい場面もあるし、データ構造とロジック、安定している方に依存するようにした方がいいし、チームの状況によっては一律getter禁止もまぁあるし、難しいですね
1
吉田あひる @strtyuu

単純なgetterは悪なので何らかの計算結果を返すべしって話にモヤる理由がなんとなくわかってきたかも プロパティの隠蔽が出来ているなら、そのクラスの利用者からはプロパティの値をそのまま返してるかどうかはわからないはずなので、getterを一律に禁止するのはそれこそカプセル化の失敗を意味する?

2020-02-17 00:21:50
吉田あひる @strtyuu

getterを作ることでそのクラスの責務のロジックが外に漏れるリスクが上がるってのは、まぁそうだよなと思う

2020-02-17 00:26:22
吉田あひる @strtyuu

単純に、そのクラスに必要なAPIを生やしましょうねってだけな話か

2020-02-17 00:27:27
すえなみ @a_suenami

@strtyuu たぶんその理解で正しいと思います。getFirstName, getLastName, getFullName があったとして、getFullName はおそらく文字列結合をやってる、他の2つはおそらく内部に保持してるやつをそのまま返してるけど、それを使う側が知る必要ない的な感じ。

2020-02-17 12:24:09
すえなみ @a_suenami

@strtyuu データ構造自体とそれを使ったロジックがどっちが安定しているか、要はどっちからどっちに依存させたいかみたいな話で、構造のほうが安定でロジックが変化しやすいんだったら構造側はgetter提供してロジックがそれに依存するっていうほうがいいとは思いますね。納期計算は日付型に依存する的な。

2020-02-17 12:29:12
天重誠二 @tenjuu99

@strtyuu ロジックが漏れるというより、getterがただの値を返し、その値を利用した計算処理が外部にたくさんある(依存がたくさんある)と、変更が難しくなってしまうっていう話が getter は evil だという話だと理解しています

2020-02-17 00:43:17
天重誠二 @tenjuu99

@strtyuu あと、ロジックが外に漏れるのがなぜリスクなのかの説明が入ってないのかなと思いました

2020-02-17 12:28:38
吉田あひる @strtyuu

@tenjuu99 僕の言葉遣いが雑すぎましたね〜〜 > ロジックが外に漏れるのがなぜリスクなのか これに関してはその値に依存しているロジックがいたるところにあると変更の時に大変になるという一点でリスクだと思ってたんですが、すえなみさんのリプでもっと深い考え方がありそうだなと思ったので今は説明できない

2020-02-17 12:49:18
n @n_1215

むやみにgetterを生やすと外部からの介護であらゆることができてしまうのでオブジェクトくんが自立してくれない傾向にあるんだよな?

2020-02-17 12:30:39
吉田あひる @strtyuu

@n_1215 実際のチームの状況によっては一律にgetter禁止する方がマシってのは普通にありそうですよねー

2020-02-17 12:54:47
n @n_1215

@strtyuu わかる。Eloquent Modelを育てるよりService全振りのほうがワーストケースの被害が少ない

2020-02-17 12:56:05
n @n_1215

本来漏れているべきというか結合度を下げるべきロジックが無理やり詰め込まれる悲しい事件もあるんですよねー。はーむずかしい

2020-02-17 12:51:28
すえなみ @a_suenami

ActiveRecordしかロジックの置き場所がないフレームワークがあってですね(ry

2020-02-17 12:55:05
すえなみ @a_suenami

getter禁止的なやつは、DBテーブルと1:1に対応するクラスをまず作るという文化と内部に持つプロパティと1:1に対応するメソッドを作りそれをgetter/setterと呼ぶという文化が悪魔合体した結果生まれたキメラコードへの対抗策として生まれたものだと思ってるので、キメラ以外への効き目はアレ

2020-02-17 13:05:12