背景
飲み会でgetter/setterが話題に上がったので、調べてみた。
Javaのgetter/setterのまとめ
- getter/setterの慣習についてはJavaBeans仕様の影響があるという説が強い getter/setterとはなんだったのか - プログラマーの脳みそ
- やりたいこと：内部のフィールドはprivateアクセスとして外から直接いじれないようにしつつ、操作をメソッド経由で行う。
- いけていないこと1：単純なgetter/setter（内部で加工していない）だと、カプセル化になっていない
- いけていないこと2：メソッド名がオブジェクトよろしくない（詳しくはGetter/Setterは悪だ。以上。 | To Be Decided）
最近のプログラミング言語でのgetter/setter
- C#, Ruby, Swiftなどはプロパティ構文を持っている（裏でgetter/setterのようなメソッドを介している） 結局のところgetter／setterは要るのか？要らないのか？ - Qiita 参照
参考になったブログと引用文
getter/setterとはなんだったのか - プログラマーの脳みそ
内部のフィールドはprivateアクセスとして外から直接いじれないようにしつつ、操作をメソッド経由で行う。
getter/setterの慣習についてはJavaBeans仕様の影響があるという説が強い。
現代ではimmutable(いみゅーたぶる)という思想が広まっているが、前世紀のころ、Java界隈でimmutableという言葉を聞くことはあまりなかったように思う。getter/setterでやりたいことのひとつはこのimmutableだった。
immutableの実現に関してはgetter/setterに対するプロパティ構文をどうするかという議論より、関数型言語における不変データ型をサポートしてくれ的な議論が主流だろう。
結局のところgetter／setterは要るのか？要らないのか？ - Qiita
本来カプセル化はフィールドへのアクセスを制限するためのものだが、getter／setter（特に、内部で一切の加工を行わないもの）を使ってフィールドへアクセスできてしまうと意味がない。
Getter/Setterは悪だ。以上。 | To Be Decided
オブジェクト指向設計 getter, setterを使うなとはどういうことか - Qiita
「getter, setterを使うな」というのはより正しく言うならば、「そのgetter, setter呼び出しは呼び出される側への責務の割り当てに置換できないか検討しろ」ということになります
