アクロニム、30回くらい使って初めて覚えられるので、新しい概念の略語には向いてない
僕の中の欲望バトルが起こってしまうので、まずいじる前に、ロリに倒すか、ちょっと大人に倒すかを決めておいたほうがいいな。コンセプト大事
プロパティ自体はあんまり好きじゃなくて、 GetHoge, SetHoge のほうが好きなんですけどね。メソッド呼び出し感があるので。それはそれとして自動実装プロパティは、 public メンバーとしてあるべき契約のあり方(つまり getter, setter。値を記録するストレージを隠蔽する)でフィールドを公開できるという点でうまい
代入式が使えるプロパティより、 GetHoge, SetHoge メソッドの形式を推すのは、どちらにしてもメソッド呼び出しだからです。メソッドの契約は名前だけ(言い過ぎ)であって、内部の実装はなんでもいい、例えば通常の変数へのアクセスより、その getter のほうが 100 倍遅い可能性だってあるわけで、それをばんばか使われるわけには行かない。そういう意味で、メソッド形式であるべきで、呼び出した結果は、呼び出し元がしばらく持っておけと思うわけです。
100倍遅いのはデータ構造が悪いけど、でも getter の中身がフィールドアクセスとは限らない、例えば Dictionary のルックアップなこともあるでしょ?
Dictionary をストレージとする getter はあります。例えば JSON を辞書に変換したものをバックに持ち、それが持っているであろうフィールドをメソッドとして提供するなどが考えられます。裏側を動的なデータ構造にしつつ、メソッドとして提供することはあるかと
@orumin {"a":1} に対して、 GetA を提供するという意味で、 Find("a") を提供するという意味ではありません
そういうのを含めてストレージの隠蔽をするために getter, setter を定義するのでしょう。じゃなかったらフィールド外出しでいい
フィールド外出しだと mutability の制御とか validation とかかけられないことがあるから、そのために getter と setter が用意されるものだと思っていた (C++er 並感)
public メンバーとして、あとでバリデーション追加しようみたいな案件に対応できないから最初から getter, setter にしておけ、が OOP 的隠蔽 way だと思ってる