getter/setterがなぜマズいか - kawasima

getterとsetterは、クラスをみせかけのデータ構造に変える。で、そのデータ構造は独自のAPIをもつことになる。XとYの属性を持てば、getXとsetX, getYとsetYというように。で、これを使う人はこれらを使って業務をどう組み立てなくてはならないかを学ぶ必要がある。 まぁ、これはまだ良いのだが、データモデリングの観点からいうと、問題を先送りできちゃうことがよりマズいのだ。「Xが変わる可能性があるので、Xをセットできる必要があります。このオブジェクトをインスタンス化した後で変更する必要があるかもしれません。」というように。Xをセットするとして、その変更が業務上何を意味するのか? 全く考えていない。「Xがいつ変更されるのか、またどのような条件下で変更するのかを決めるのは、コードの他の部分に任せるつもりです。」

[programmablekinoko]

アーキテクチャの話というよりビジネスロジックの話だった、ビジネスロジックに絡むところで使ってはいけない

[lyiase]

setter,getterは基本的に「好きにとってもいいよ」「目的の値を現在から変更しければ好きに使ってね」と言うものだと思ってる。よって、手順に絡むものは良くないと思ってるな。

[kazkun]

上昇志向系のいい考え方だけどさ、対象ドメインの前提がない気がする。getterだってsetterだって必要な場面はある。対象ドメインの中で、制約の範囲での最適解が実務では偉いのであって。

[tattyu]

setterは基本使わないもんだと思うけど、そんなのメソッドでも対して変わらなくない？って思う。結局無闇矢鱈にステートフルなIF公開するなで終わりだと思うな。

[coppieee]

setterはダメだけど、getterだけなら別に問題ないだろ

[y2q_actionman]

lispcast.com とな。 Clojure 関連の人か。

[turanukimaru]

アリストテレスは言った。属性は取得することはできるが与えることは出来ない。属性は操作に付随して変化するもので直接操作できない。例えば物を真中で切れば大きさは半分になるが切らずに半分にすることはできない

[castaneai]

"給料について業務上どういう変化があるかを考えずに「3ドルに設定する」というのは、設計の先送りだ。従業員の給料を直接読み書きしたり、好きなように設定したりできるのは業務としてはなんの意味もない"

[kunigaku]

問題を先送りにすることのデメリットがきになる

[dalmacija]

タイトルから予測できる通りの内容だった

[kenjiro_n]

文脈的意味を持たないこれらのメソッドはよくないという意見。