class A { private String propA; public String getPropA() { return this.propA; } public Void setPropA(String propA) { this.propA = propA; }
}
class B { private String propB; public String getPropB() { return this.propB; } public Void setPropB(String propB) { this.propB = propB; }
}
と云う書き方をするのは普通なので、
A.propA = B.propB;
と書くと、
プロパティ参照でスコープ違反になりコンパイル・エラーになるから
A.setPropA(B.getPropB());
と書かねばならない。
上の２つの代入式を見ると、下の式の方が括弧が多く、読みにくく、しかも長い。
※老眼になってくると「））」の部分は特に読みにくい。
だが、今風なのだ。なぜこうなったのかは、古い世代にしか判らない。
ことの発端はBASIC言語である。
BASICではパラメータが無い関数には（）を付けないので、
A.propA = MethodC( )
とはならず
A.propA = MethodC
と書く。これと先のプロパティの代入式を並べると
A.propA = B.propB
A.propA = MethodC
A.propA = B.propB
A.propA = B.propB
な感じになって、区別が付きにくい。
そこで代入式を Setterメソッドの形式で表現すると
A.setPropA ( B.propB)
A.propA = MethodC
A.setPropA ( B.propB)
A.setPropA ( B.propB)
見分けやすくなる。
ついでなので、Getterも使ってみると
A.setPropA ( B.getPropB())
A.propA = MethodC
A.setPropA ( B.getPropB())
A.setPropA ( B.getPropB())
これだけ括弧を入れれば、大抵の人はメソッドの呼び出しとプロパティの代入式を区別できる訳だが、
見た目上の違いはあるものの、実際には全てメソッドの呼び出し（単純なメソッドの呼び出し＋Setter/Getterメソッドの呼び出し）で統一されてしまっているのだ。
あからさまに云えば、
- 普通のメソッド呼び出し
- くどいすぎるSetter/Getterメソッドの呼び出し
となり、
くどいすぎる表現
を使うことで見分けやすくしているのだ。
また、Visual-BASICでは、オブジェクト型の変数の代入式は
SET A.propA = B.propB
の様に書かなければいけない。
しかも、MS-AccessのRecordSetなら確実に A.propA の中身が宙ぶらりんになりメモリー・リークが起きてしまうので、
SET A.propA = Nothing
SET A.propA = B.propB
と書かないといけないが、
SET A.propA1 = Nothing
SET A.propA1 = B.propB1
・・・
SET A.propAn = Nothing
SET A.propAn = B.propBn
これが沢山あったら・・・
毎回代入式の前にNothingの代入式を書くのはウンザリする。
ならば、
BASICでのSetter/GetterはPUT／GETを、
PUT propA(propA As String)
SET me.propA = Nothing
SET me.propA = propA
END PUT
※多分、こんな文法だったハズ
と書けば毎回SETやNothingの代入式を書かずに済むので人に優しいコードになる。（ハズ
この様にして、BASICではSetter／Getterを使うことが良いことになった。
Javaの方にはSETなど妙な宣言無いので、
A.propA = B.propB;
と当初は書いていたのだが、Getter/Setter方式なら内部で入力値をチェックしたり補正したりスローしたりできるので、便利なんじゃないか？ということになり、BASICを真似る風潮が出来上がった。
一時は、無駄に設定値のチェック文が書かれていたこともあったが、
幸運なことにGetter/Setterに無駄に設定値のチェックを入れない方向に世の中は動いていく。
Javaも使いだして数年が経つと
当初はプロパティの値が０と１しかなかったが、仕様を拡張し２や３も許容するケースが出てくる。
そうなると、Getter/Setterに入力チェックで２や３も許容する様な手直しが必要になる。
さらに、仕様が変わっていない呼び出し側は０～１のみ許容する必要があるから・・・
「仕様の変更が無い処理を変えなければいけない」というのは、かなり違和感のある事態が発生することになった。
これが仕事なら、仕様変更が無い箇所を書き換えなければいけない理由を説明するのはとても難しい。
そんな、大人の都合から、一律にGetter/Setterの内部では入力チェックをしない方向に逝ってしまったのだった。
だったら、
A.propA = B.propB;
に戻ればいいのだが、「古い書式に戻す」ことになるので、これが仕事なら予算が出るケースは稀であろうから「放置」されることになる。
よって、何のためにGetter/Setterを使うのかは？後付け（＝こじつけ）で、
「プロパティを直接操作することは好ましくない。」
という趣味の話になってしまうのであった。
なぜならば、そんなことは・・・
C++の様に代入演算子をオーバーライトできる様にすれば、済む話なので、何の根拠にもならないのである。
※だから、いつまでたっても演算子のオーバーライトは実装されない。（と、予言しとこう・・・