オレンジの場合で、（Delphi / C# での）プロパティが返すものを予め準備するか否かはケースバイケースで、例えば最初に呼ばれた時に用意して、次回からはキャッシュしたやつを返す、再計算が必要な時にも用意したり用意しなかったりする
みたいに、呼ばれる側が自動でいい感じにいろいろしたい時は、むしろプロパティじゃなきゃ気持ち悪い＞＜
手動でそういうの制御できるようにもしたい時には設定用のプロパティを作ったり、明示的に準備させるメソッドを用意したりする＞＜
オレンジ的には隠蔽するんだから、重いかもしれない可能性も含めて隠蔽される（隠蔽されてしまうけどそういうもの）みたいな考えだった＞＜
orange
さんがブースト
そういうのを含めてストレージの隠蔽をするために getter, setter を定義するのでしょう。じゃなかったらフィールド外出しでいい
orange
さんがブースト
あれはインデクサ、または引数付きプロパティ
orange
さんがブースト
orange
さんがブースト
Dictionary をストレージとする getter はあります。例えば JSON を辞書に変換したものをバックに持ち、それが持っているであろうフィールドをメソッドとして提供するなどが考えられます。裏側を動的なデータ構造にしつつ、メソッドとして提供することはあるかと
orange
さんがブースト
C# の文脈だと
public string this[string key] {
return this.dict[key];
}
が存在するので別名を付けたくないモチベーションはある
表記ゆれが＞＜；
平均tじゃなく最大値、最小値だってそうだよね＞＜
「そういうの一切プロパティにするな」ってそれプロパティ畑（？）の人っぽくない＞＜（プロパティー畑（？）であるDelphiが好きな人です＞＜）
例えば平均値を返すプロパティは存在していいのかみたいな話・・・？＞＜（「呼ばれてから平均を調べる可能性があるならプロパティにして欲しくない」みたいな話かも？＞＜）
そういう話じゃなく、実際の処理が重いかどうか、場合によっては予め返すものを用意してるか否かがみたいなのが不安なのが問題って話じゃないの・・・？＞＜
orange
さんがブースト
さっきも書いたけどそういうのは lookup とかそういう別名がちゃんと付けられるはずで，基本的に setter/getter ってただのフィールドアクセスだと思ってたのだけれども
orange
さんがブースト
それ getter ではなくない
orange
さんがブースト
100倍遅いのはデータ構造が悪いけど、でも getter の中身がフィールドアクセスとは限らない、例えば Dictionary のルックアップなこともあるでしょ？
メソッドでも軽いか重いかわかんないけどメソッドは重い覚悟をする（？）みたいな感じ？＞＜； プロパティも同様に考えればよくない・・・？＞＜
プロパティだと中味の処理が軽いか重いか、何らかの結果をキャッシュしたりしてるかしてないか、そういうのが不安というか、「プロパティの方が軽いことを期待しちゃう」みたいな意味かも・・・？＞＜
orange
さんがブースト
代入式が使えるプロパティより、 GetHoge, SetHoge メソッドの形式を推すのは、どちらにしてもメソッド呼び出しだからです。メソッドの契約は名前だけ（言い過ぎ）であって、内部の実装はなんでもいい、例えば通常の変数へのアクセスより、その getter のほうが 100 倍遅い可能性だってあるわけで、それをばんばか使われるわけには行かない。そういう意味で、メソッド形式であるべきで、呼び出した結果は、呼び出し元がしばらく持っておけと思うわけです。
GetHoge, SetHoge 方式だと、プロパティ方式よりもコンパイラがバグを見つけにくいかも？＞＜
orange
さんがブースト
プロパティ自体はあんまり好きじゃなくて、 GetHoge, SetHoge のほうが好きなんですけどね。メソッド呼び出し感があるので。それはそれとして自動実装プロパティは、 public メンバーとしてあるべき契約のあり方（つまり getter, setter。値を記録するストレージを隠蔽する）でフィールドを公開できるという点でうまい
- ＠orange_in_space
2017年 4月に登録
