Tell, Don't Ask.
2020年にする話題じゃないが、getter,setterの意味が分からない。
C#の「get;」でreadonlyにしたりする使い方は理解できる。
プロパティの意味を理解していないと使えない変数なので、
アクセスするときに実装するのであればただのプロパティと変わらないのではないか。
と思ったら、諸先輩方はとっくの昔からそうしたことに議論を重ねてきたみたいで、
僕の思った疑問はそんなに的外れじゃないみたいだ。下のblogを読むと腑に落ちた。
https://qiita.com/katolisa/items/6cfd1a2a87058678d646
色々なblogを引用してくれてて、下記のsentencesに言いたいことがまとめられていた。
https://www.kaitoy.xyz/2015/07/22/getters-setters-evil/
カプセル化原則違反
setterを通してどんな新たなデータも入力できるので、 一つのオブジェクトをその他の様々なオブジェクトが様々に扱うことができてしまう。 また、だれでもオブジェクトを変更できるので、 オブジェクトが単純に自身の状態を安全にカプセル化できない。
そう、カプセル化してprivateなフィールドを見えなくしているのに、 setter、getterをsetで用意してそれを使ったら実質同じ事じゃないか。言語化されていてすっきりした。
Javaの歴史
調べたらJavaの歴史についてまとめたページがあった。
当時はIDEも貧弱だったのでいろんなところにPrintlnを仕込んで確認していたそうだ。
となると、setter/getterの力はバカにならない。
https://nagise.hatenablog.jp/entry/20141010/1412930502
C#は後発で、その際にプロパティ構文が出来たらしい。
プロパティとして使えるのを標準として、
あとからエラー処理など必要になった時様に、拡張できるようにしたのか。流石に後発は考えられている。
IDEの補完や、EntityFrameworkがsetter/getterを必要とするので、 僕のコードにもset;とget:は出てくる。
何か釈然としないが、世の中とは常に過去の歴史の延長線上にある。
ThunderBoltコネクタはなくならないし、getter/setterもなくならないだろう。
C#は構文に従うだけでずいぶん見通しの良いコードがかける。
Java時代を知らないままWeb開発者になったのは幸せなのか、不幸せなのか。
