一応解説すると、例えば public virtual readonly int Hoge; public HogeClass(int hoge) { this.Hoge = hoge; } と書いただけで private readonly int __hoge; public virtual int Hoge { get { return _hoge; } } public HogeClass(int hoge) { this.__hoge = hoge; } このような感じに自動的に解釈してくれるとうれしいな、って思ったんです。
言語というよりはAPIの特徴か (スコア:2)
Java の getうんたらsetうんたらは、一体なんなのであろうか。無意味なコードがただ増えるだけだ。たぶん、アクセサメソッドには、重要な価値があると信じられた時代があったのだろうが、しかし、今となっては、くだらない役立たずなのは明らか。じっさい、今出てきてる新しいプログラミング言語には、そのようなものは無い。
べつに Java で public インスタンス変数使ってコード書いても、コンパイルエラーが出るわけじゃなし。かまやしないのだが、API がそうなってないから、自分のコードだけそうするってのも少し格好わるい。
Re:言語というよりはAPIの特徴か (スコア:3)
メソッドの後ろにつけられた throws IOException とか throws ParseException も、あれが困りものだ。必ず catch して何かをしなきゃいけないと決められてもらっても、無視したいものは無視するし、catch したいとなったら、RuntimeException だろうとなんだろうと、try catch 構文を書く。あれのせいでインデントは深くなるし、コードは長くなって読みにくくなるし、なんなんだあれは。
Re:言語というよりはAPIの特徴か (スコア:3, 参考になる)
あれ、割ときっちり考えられてたりもするので侮れない。
マルチスレッドでIO処理を書いたりするとよく分かる。
例外を投げうるメソッドを呼ぶ自作メソッドで、「いや、IOが失敗したら失敗しても良いよ、このメソッドは」というやつには、throwを付け、
「このメソッドが例外で死んだらマルチスレッドの後処理が転けて辻褄が合わなくなるからcatchして…」とやって行くと、
結構、過不足無く、処理忘れの例外を撲滅できて、その合理性を実感できる。
そういうプログラムって、ややこしい構造になりがちなので、とても助かる。
例外ハンドリングの強要が無いC#でプログラムしてると、catch残しが出てきて苦労する。
けどまあ、そんなめんどくさいプログラムは滅多にないので、普段使いだと、
コンパイルオプションで全部チェックをOFFにしたくなる。
むしろ、追加の静的型チェックツールかなにかで、別途提供されるべき仕組みなんじゃないかと思う。
Re: (スコア:0)
発生しうる例外をスーパークラスが決めるのは理不尽だと思う
Re: (スコア:0)
interface などが、どのような例外があるのか予言するのは奇妙だと思います
検査例外は仕様としてのエラー (スコア:1)
検査例外は、実行時例外みたいに処理の関係上起こるものではなく、どちらかというと業務エラーなんかの仕様として起こり得る例外なので、それがI/Fに書けないというのは例外の設計がちゃんとできてないだけ。
# その割には、標準APIに「いやこれが検査例外なのはおかしいだろ」ってものが多々あるぞ?というツッコミは受け付ける。仕組みは正しいと思うが、運用があんまりうまく行われていない気はする。
Re: (スコア:0)
プライベートでJavaの勉強を始めた頃、なんで符号無し整数がないんだろうと思いました。
業務でJavaを使うようになってしばらくした頃、なんで明示的にメモリの解放ができないんだろうと思いました。
ちゃんと意味があるんですよね。
Re: (スコア:0)
Javaはいろいろ新しい事にチャレンジした言語なんだよ。
検査例外は失敗だったけどね。
でもその失敗のおかげで後発の言語が検査例外を導入しなくて済んだんだ。
Re: (スコア:0)
スーパークラスの throws は非常に奇妙だと思う。
Re: (スコア:0)
Re:言語というよりはAPIの特徴か (スコア:3)
えっと、それは本気で Java でパブリックフィールドを使わずにアクセサーを使う理由を理解できないと言っているの? 「Java には C# のプロパティーに相当する機能がなくてアクセサーメソッドだらけになるのが古臭い」とか言うならわかるけれど。
Re:言語というよりはAPIの特徴か (スコア:2)
アクセサメソッドは要らないでしょう。JavaScript、Go、Haskell、Dart で書かれたコードを見れば明らかなように、アクセスコントロール機構なんて無くても、誰もまったく困らない。
Re:言語というよりはAPIの特徴か (スコア:2)
これまでの話とアクセスコントロール機構の有無の関連も今一つ不明瞭だし、 Haskell にアクセスコントロール機構がないとか言い出すし (モジュールのユーザーはモジュールからエクスポートされた識別子しか使えない、というのが Haskell のアクセスコントロール機構だよ)、何言っているんだとしか思えないんだけど。
Re:言語というよりはAPIの特徴か (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
Re:言語というよりはAPIの特徴か (スコア:1)
>アクセサメソッドは要らないでしょう。
アクセサとは、オブジェクトの利用者に仕様通りの使い方を強制するためのものです。
つまり、不特定多数の人が使うようなライブラリには必要なものです。
逆に言うと、そうでないその場限りのプログラミングには不要だと思います。
Re: (スコア:0)
JavaScriptには機能が追加されたようですが。
誰かが困ったんでしょうね。
Re: (スコア:0)
追加されてはいない。
そもそもJavaScriptだとインスタンスとクラスの結びつきがないから、そのクラスでのみ読めるという仕組みがあわない。
Re: (スコア:0)
Object.definePropertyができましたね。
JavaだってC#だって、そのクラスのみ読めるというようには普通作らないでしょう。
そのインスタンスのみ読めるように作ります。
Re: (スコア:0)
あーアクセサの話ね。
setter、getterはそりゃいるよ、で入ったのは結構前。
上の話はprivate云々の話のつもりで書いた。
Re: (スコア:0)
DartもGoも変数の頭文字でprivate変数か指定できるけど、
例外なのはJavaScriptだけで
プラウザ上では1スレッドしか使えないので、データ競合が起きないし
DOMはhtml文書の構造を変更する手段を提供APIだから、レンダリングはブラウザが勝手にやってくれる。
Re: (スコア:0)
スレッド云々は関係ないよ。
JSでもprivateはある。
WeakMapのラッパー(インスタンスと変数群オブジェクトを登録する)で実現する。
Re: (スコア:0)
アクセサメソッドは、必ずしもアクセスコントロールのために必要とされているのではないのですが……。
参照/代入のタイミングを横取りできるのが重要なんです。
インスタンス変数をむき出しにしたら、Lazy Initialization(遅延初期化)とか実装できないじゃないですか。
Re: (スコア:0)
インスタンス変数へのアクセス方法を別途カスタマイズ可能にする、という方法もあるよ(例:CLOSのMOP)。コードの字面だけ見て何やってるかわかりにくいからJavaでは採用しないだろうけど。
Re:言語というよりはAPIの特徴か (スコア:1)
パブリックフィールドをそこまで嫌う理由もよくわからない。
Re: (スコア:0)
C#ならともかく、Javaはダイレクトアクセスをアクセサ呼び出しに書き換えるコストが大きいから用心のため最初からアクセサ呼び出しにするのが定石。
2つほど質問 (スコア:0)
Javaの文法にプロパティが追加されたらいらなくなる?
あとリファクタツールで間に合う程度の小規模なら害はないが大規模でライブラリ多用するようになると追うのが大変なので必須、というのは正しい?(小規模でも癖にならないよう、あるいはコード流用される可能性があるので義務づける、というのは別の話として)
Re: (スコア:0)
コストなんか大きくないだろjk。
ステップ1:eclipseで Refactor -> Encapsulate Field
以上。
当然、影響箇所は全てテストをするわけで、そっちのコストの方が大きい。
これは最初からセッタゲッタを使ってたとしても、中のロジックを変えたのならやっぱりテストは必要。C#だって同じ。
それに比べたら、リファクタリング作業なんてサガミオリジナルの0.01mmよりも無に等しい存在。
なおサガミオリジナル0.01mmはお一人様1箱でお願いします。
Re: (スコア:0)
外部とのインターフェース変わらないからいつでも変更できるし。
readonlyとかset onlyなものは欲しいケースはあるのでプロパティがいらないわけじゃないけどね。
javaの場合は他の都合でgetとsetをつけないといけない分そうもいかないけど。
Re:言語というよりはAPIの特徴か (スコア:2)
メンバー変数への直アクセスだと、複数スレッドから書き換えられた場合結果が保障できない。
javaでスレッドセーフなのはローカル変数のみ。外部に公開するAPIはアクセッサメソッドでないと困るだろうに。
Re: (スコア:0)
JavaScriptみたいに全部が連想配列でいいのにね
Re:言語というよりはAPIの特徴か (スコア:2)
JavaというかC#だけど、フィールドを宣言するだけで、それがアクセサの糖衣構文になればいいのに、とは何度も思った。
Re: (スコア:0)
public int Hoge {get;set;}
たったこれだけ書くのすら面倒なら、プログラマ辞めた方がいいんじゃない?
Re:言語というよりはAPIの特徴か (スコア:2)
一応解説すると、例えば
public virtual readonly int Hoge;
public HogeClass(int hoge) { this.Hoge = hoge; }
と書いただけで
private readonly int __hoge;
public virtual int Hoge { get { return _hoge; } }
public HogeClass(int hoge) { this.__hoge = hoge; }
このような感じに自動的に解釈してくれるとうれしいな、って思ったんです。
// 他にもsetterされたらイベント発火するだけでも自動プロパティ使えなくなる上に
// 自前でフィールド作らなきゃいけないのも、なんとかなればいいなあと
Re: (スコア:0)
省略案があまりよくないとは思うが。
にたような要望はいろいろあるようで。
C#6.0で、
public class Fuga
{
private readonly int hoge;
public int Hoge
{
get{ return hoge;}
}
public Fuga(int hoge)
{
this.hoge = hoge;
}
}
Re:言語というよりはAPIの特徴か (スコア:1)
誰も言及していないのが不思議ですが、Java Beansの命名規約がset, getを要求しているため、広まったのだと思います。
一応、JavaBeans仕様に従えばいろんなフレームワークやライブラリで使い回せるというお題目もありましたし。
// Java Beans仕様を知らずに、なんとなくでset, getを機械的に書く人が、私の観測範囲で多く見られるからそれだけが理由ではないかも
私はJavaBeansとしてそれが必要である場合にしかgetやsetメソッドは書きません。
逆に必要であれば、対応するフィールドが無くてもgetやsetメソッドを書きます(あまり重い処理ではやってはいけない)。
メンバーには驚かれますが、説明して納得してもらっています。
Re: (スコア:0)
は?C#でも書き方が違うだけで同じこと要求してるだろ。
ソースコードとしても、その書き方の違いが重要なので同じといいたくないが、存在理由は同じこと。
public インスタンス変数を使わずに済む機構がない新しい言語ってどんなよ。
Re: (スコア:0)
あるでしょ。C#のpropertyとか。
methodに見えないように隠蔽されてるからpublic インスタンス変数にダイレクトアクセスしてるように見えるけど。
Re: (スコア:0)
言語にそういうくだらないコードを書かなくて済む仕掛けがないのがおかしい。
Re: (スコア:0)
下らなくないよ。
インスタンス内のメモリへアクセスさせるだけじゃなく、アクセスされることに付随する別の処理を行う必要性に対する答えはアクセサを書く以外に無いんだから。
アクセサ書く必要が無いのに妄信的に書く必要があると考えてるから書かされてる感が嫌気になってるだけでしょ。
Re: (スコア:0)
アクセサがくだらないんじゃなくてgetなんたらsetなんたらといちいち書かされることがくだらないと言ってる。
Re: (スコア:0)
アクセサが必要になるまでアクセサ書きたくくないだけでしょ。
Javaなんて捨ててC#使え。
Re: (スコア:0)
> Javaなんて捨ててC#使え。
つまり「getうんたらsetうんたらをいちいち書かされるJavaはうんこ」ってことだよね。元コメが「public変数使えばいいのに」などとわけのわからない供述をしなければこんなに紛糾することもなかっただろうに。
Re: (スコア:0)
C#にしたところで、{get; set;}とアクセサかかなきゃいけないんですけどね。
C#のほうが書きやすいし、解りやすいから好きですけど。
Re: (スコア:0)
いや、VBに来てくれ
Public Property Hoge As String
Re: (スコア:0)
すでにほかのコメントでも指摘されてるとおり、追加で処理が必要ないなら書く必要はないし、アクセッサを後から書き足しても呼び出し側のソースに一切変更は必要ないC#のほうがずっとスマート。
Re: (スコア:0)
後発の言語でスマートな実装がされない方が怖い。
>追加で処理が必要ないなら書く必要はない (スコア:0)
ほとんど全てのケースにおいて、それが分からないから、あれこれ後で変更を入れやすいように仕組みを入れるんであってだな(ry
とはいえ、無駄なget/setが大量に並ぶことは多々あるから、Lombokのアノテーションみたいな仕組みを標準で使えるようにしてほしいとは思うけど。
Re: (スコア:0)
要するに・・・
・呼び出し側はアクセッサの存在を考えずにa=1とかb=a+1と書いていい。
・実際の動作はクラスの中でアクセッサがなければデフォルトアクセッサ(?)みたいな
単に代入するとか参照する動作となり、明示的にアクセッサがあればそれを呼び出す。
って事かな? アノテーションでも使ってうまく定義出来ればよさげではある。
# なんかセキュリティリスクがあるかもしれないけどその辺は全然考慮してません。はい。
Re: (スコア:0)
Lombok使うと幸せになれたよ
Re: (スコア:0)
publicフィールドって継承されるんだっけ。
多態性とか使うときはどうなるんだろう。
読み書き許可、読み込み専用、書き込み専用、継承考慮、多態性考慮、・・・とか使い分ければいいんだよ
と言われればそれまでかもしれませんけど。