パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

悩まされてしまうプログラミング言語の奇妙な特徴は?」記事へのコメント

  • Java の getうんたらsetうんたらは、一体なんなのであろうか。無意味なコードがただ増えるだけだ。たぶん、アクセサメソッドには、重要な価値があると信じられた時代があったのだろうが、しかし、今となっては、くだらない役立たずなのは明らか。じっさい、今出てきてる新しいプログラミング言語には、そのようなものは無い。

    べつに Java で public インスタンス変数使ってコード書いても、コンパイルエラーが出るわけじゃなし。かまやしないのだが、API がそうなってないから、自分のコードだけそうするってのも少し格好わるい。

    • メソッドの後ろにつけられた throws IOException とか throws ParseException も、あれが困りものだ。必ず catch して何かをしなきゃいけないと決められてもらっても、無視したいものは無視するし、catch したいとなったら、RuntimeException だろうとなんだろうと、try catch 構文を書く。あれのせいでインデントは深くなるし、コードは長くなって読みにくくなるし、なんなんだあれは。

      親コメント
      • by Anonymous Coward on 2014年09月06日 19時20分 (#2671969)

        あれ、割ときっちり考えられてたりもするので侮れない。

        マルチスレッドでIO処理を書いたりするとよく分かる。
        例外を投げうるメソッドを呼ぶ自作メソッドで、「いや、IOが失敗したら失敗しても良いよ、このメソッドは」というやつには、throwを付け、
        「このメソッドが例外で死んだらマルチスレッドの後処理が転けて辻褄が合わなくなるからcatchして…」とやって行くと、
        結構、過不足無く、処理忘れの例外を撲滅できて、その合理性を実感できる。
        そういうプログラムって、ややこしい構造になりがちなので、とても助かる。
        例外ハンドリングの強要が無いC#でプログラムしてると、catch残しが出てきて苦労する。

        けどまあ、そんなめんどくさいプログラムは滅多にないので、普段使いだと、
        コンパイルオプションで全部チェックをOFFにしたくなる。

        むしろ、追加の静的型チェックツールかなにかで、別途提供されるべき仕組みなんじゃないかと思う。

        親コメント
        • by Anonymous Coward

          発生しうる例外をスーパークラスが決めるのは理不尽だと思う

        • by Anonymous Coward

          interface などが、どのような例外があるのか予言するのは奇妙だと思います

          • by Anonymous Coward on 2014年09月07日 10時46分 (#2672188)

            検査例外は、実行時例外みたいに処理の関係上起こるものではなく、どちらかというと業務エラーなんかの仕様として起こり得る例外なので、それがI/Fに書けないというのは例外の設計がちゃんとできてないだけ。

            # その割には、標準APIに「いやこれが検査例外なのはおかしいだろ」ってものが多々あるぞ?というツッコミは受け付ける。仕組みは正しいと思うが、運用があんまりうまく行われていない気はする。

            親コメント
        • by Anonymous Coward

          プライベートでJavaの勉強を始めた頃、なんで符号無し整数がないんだろうと思いました。
          業務でJavaを使うようになってしばらくした頃、なんで明示的にメモリの解放ができないんだろうと思いました。
          ちゃんと意味があるんですよね。

      • by Anonymous Coward

        Javaはいろいろ新しい事にチャレンジした言語なんだよ。
        検査例外は失敗だったけどね。
        でもその失敗のおかげで後発の言語が検査例外を導入しなくて済んだんだ。

      • by Anonymous Coward

        スーパークラスの throws は非常に奇妙だと思う。

        • by Anonymous Coward
          いや、親クラスでこのメソッドはほにゃらら例外しか投げませんとか宣言されちゃうと、サブクラスでそれ以外の例外が必要になったとき親書き換える権限ないと実装不能だから結局未チェック例外投げるはめになるんで、finalでないクラスでthrowsキーワードが役に立つケースは万に一つもありえないんだが。そしてfinalなクラスは大抵の場合final外さなきゃならない仕様変更が入るに決まってるので、finalなクラスでもthrowsに意味はない。
    • えっと、それは本気で Java でパブリックフィールドを使わずにアクセサーを使う理由を理解できないと言っているの? 「Java には C# のプロパティーに相当する機能がなくてアクセサーメソッドだらけになるのが古臭い」とか言うならわかるけれど。

      親コメント
      • アクセサメソッドは要らないでしょう。JavaScript、Go、Haskell、Dart で書かれたコードを見れば明らかなように、アクセスコントロール機構なんて無くても、誰もまったく困らない。

        親コメント
        • これまでの話とアクセスコントロール機構の有無の関連も今一つ不明瞭だし、 Haskell にアクセスコントロール機構がないとか言い出すし (モジュールのユーザーはモジュールからエクスポートされた識別子しか使えない、というのが Haskell のアクセスコントロール機構だよ)、何言っているんだとしか思えないんだけど。

          親コメント
        • Objective-Cで書かれたコードを見れば悪施さメソッドは明らかに必要。 Javaでプログラムしていると、無指定はprivateにして欲しいと切に願う。
          --
          -- 哀れな日本人専用(sorry Japanese only) --
          親コメント
        • >アクセサメソッドは要らないでしょう。

          アクセサとは、オブジェクトの利用者に仕様通りの使い方を強制するためのものです。
          つまり、不特定多数の人が使うようなライブラリには必要なものです。

          逆に言うと、そうでないその場限りのプログラミングには不要だと思います。

          親コメント
        • by Anonymous Coward

          JavaScriptには機能が追加されたようですが。

          誰かが困ったんでしょうね。

          • by Anonymous Coward

            追加されてはいない。
            そもそもJavaScriptだとインスタンスとクラスの結びつきがないから、そのクラスでのみ読めるという仕組みがあわない。

            • by Anonymous Coward

              Object.definePropertyができましたね。

              JavaだってC#だって、そのクラスのみ読めるというようには普通作らないでしょう。
              そのインスタンスのみ読めるように作ります。

              • by Anonymous Coward

                あーアクセサの話ね。
                setter、getterはそりゃいるよ、で入ったのは結構前。
                上の話はprivate云々の話のつもりで書いた。

        • by Anonymous Coward

          DartもGoも変数の頭文字でprivate変数か指定できるけど、

          例外なのはJavaScriptだけで
          プラウザ上では1スレッドしか使えないので、データ競合が起きないし
          DOMはhtml文書の構造を変更する手段を提供APIだから、レンダリングはブラウザが勝手にやってくれる。

          • by Anonymous Coward

            スレッド云々は関係ないよ。
            JSでもprivateはある。
            WeakMapのラッパー(インスタンスと変数群オブジェクトを登録する)で実現する。

        • by Anonymous Coward

          アクセサメソッドは、必ずしもアクセスコントロールのために必要とされているのではないのですが……。
          参照/代入のタイミングを横取りできるのが重要なんです。
          インスタンス変数をむき出しにしたら、Lazy Initialization(遅延初期化)とか実装できないじゃないですか。

          • by Anonymous Coward

            インスタンス変数へのアクセス方法を別途カスタマイズ可能にする、という方法もあるよ(例:CLOSのMOP)。コードの字面だけ見て何やってるかわかりにくいからJavaでは採用しないだろうけど。

      • パブリックフィールドをそこまで嫌う理由もよくわからない。

        親コメント
        • by Anonymous Coward

          C#ならともかく、Javaはダイレクトアクセスをアクセサ呼び出しに書き換えるコストが大きいから用心のため最初からアクセサ呼び出しにするのが定石。

          • by Anonymous Coward

            Javaの文法にプロパティが追加されたらいらなくなる?
            あとリファクタツールで間に合う程度の小規模なら害はないが大規模でライブラリ多用するようになると追うのが大変なので必須、というのは正しい?(小規模でも癖にならないよう、あるいはコード流用される可能性があるので義務づける、というのは別の話として)

          • by Anonymous Coward

            コストなんか大きくないだろjk。

            ステップ1:eclipseで Refactor -> Encapsulate Field

            以上。
            当然、影響箇所は全てテストをするわけで、そっちのコストの方が大きい。
            これは最初からセッタゲッタを使ってたとしても、中のロジックを変えたのならやっぱりテストは必要。C#だって同じ。
            それに比べたら、リファクタリング作業なんてサガミオリジナルの0.01mmよりも無に等しい存在。
            なおサガミオリジナル0.01mmはお一人様1箱でお願いします。

        • by Anonymous Coward
          現実問題、VB6, VB.NET, C#のプロパティあたりでローカル変数からの出し入れしかしていないなら、パブリック変数でいいじゃんと思う。
          外部とのインターフェース変わらないからいつでも変更できるし。

          readonlyとかset onlyなものは欲しいケースはあるのでプロパティがいらないわけじゃないけどね。

          javaの場合は他の都合でgetとsetをつけないといけない分そうもいかないけど。
    • メンバー変数への直アクセスだと、複数スレッドから書き換えられた場合結果が保障できない。
      javaでスレッドセーフなのはローカル変数のみ。外部に公開するAPIはアクセッサメソッドでないと困るだろうに。

      親コメント
      • by Anonymous Coward

        JavaScriptみたいに全部が連想配列でいいのにね

    • JavaというかC#だけど、フィールドを宣言するだけで、それがアクセサの糖衣構文になればいいのに、とは何度も思った。

      親コメント
      • by Anonymous Coward

        public int Hoge {get;set;}

        たったこれだけ書くのすら面倒なら、プログラマ辞めた方がいいんじゃない?

        • 一応解説すると、例えば
          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されたらイベント発火するだけでも自動プロパティ使えなくなる上に
          // 自前でフィールド作らなきゃいけないのも、なんとかなればいいなあと

          親コメント
          • by Anonymous Coward

            省略案があまりよくないとは思うが。
            にたような要望はいろいろあるようで。

            C#6.0で、

            public class Fuga
            {
                    private readonly int hoge;

                    public int Hoge
                    {
                            get{ return hoge;}
                    }
                    public Fuga(int hoge)
                    {
                            this.hoge = hoge;
                    }
            }

    • by Anonymous Coward on 2014年09月06日 20時08分 (#2671983)

      誰も言及していないのが不思議ですが、Java Beansの命名規約がset, getを要求しているため、広まったのだと思います。
      一応、JavaBeans仕様に従えばいろんなフレームワークやライブラリで使い回せるというお題目もありましたし。

      // Java Beans仕様を知らずに、なんとなくでset, getを機械的に書く人が、私の観測範囲で多く見られるからそれだけが理由ではないかも

      私はJavaBeansとしてそれが必要である場合にしかgetやsetメソッドは書きません。
      逆に必要であれば、対応するフィールドが無くてもgetやsetメソッドを書きます(あまり重い処理ではやってはいけない)。
      メンバーには驚かれますが、説明して納得してもらっています。

      親コメント
    • by Anonymous Coward

      は?C#でも書き方が違うだけで同じこと要求してるだろ。
      ソースコードとしても、その書き方の違いが重要なので同じといいたくないが、存在理由は同じこと。
      public インスタンス変数を使わずに済む機構がない新しい言語ってどんなよ。

    • by Anonymous Coward

      あるでしょ。C#のpropertyとか。
      methodに見えないように隠蔽されてるからpublic インスタンス変数にダイレクトアクセスしてるように見えるけど。

      • by Anonymous Coward

        言語にそういうくだらないコードを書かなくて済む仕掛けがないのがおかしい。

        • by Anonymous Coward

          下らなくないよ。
          インスタンス内のメモリへアクセスさせるだけじゃなく、アクセスされることに付随する別の処理を行う必要性に対する答えはアクセサを書く以外に無いんだから。
          アクセサ書く必要が無いのに妄信的に書く必要があると考えてるから書かされてる感が嫌気になってるだけでしょ。

          • by Anonymous Coward

            アクセサがくだらないんじゃなくてgetなんたらsetなんたらといちいち書かされることがくだらないと言ってる。

            • by Anonymous Coward

              アクセサが必要になるまでアクセサ書きたくくないだけでしょ。
              Javaなんて捨ててC#使え。

              • by Anonymous Coward

                > Javaなんて捨ててC#使え。

                つまり「getうんたらsetうんたらをいちいち書かされるJavaはうんこ」ってことだよね。元コメが「public変数使えばいいのに」などとわけのわからない供述をしなければこんなに紛糾することもなかっただろうに。

              • by Anonymous Coward

                C#にしたところで、{get; set;}とアクセサかかなきゃいけないんですけどね。
                C#のほうが書きやすいし、解りやすいから好きですけど。

              • by Anonymous Coward

                いや、VBに来てくれ
                Public Property Hoge As String

              • by Anonymous Coward

                すでにほかのコメントでも指摘されてるとおり、追加で処理が必要ないなら書く必要はないし、アクセッサを後から書き足しても呼び出し側のソースに一切変更は必要ないC#のほうがずっとスマート。

              • by Anonymous Coward

                後発の言語でスマートな実装がされない方が怖い。

              • ほとんど全てのケースにおいて、それが分からないから、あれこれ後で変更を入れやすいように仕組みを入れるんであってだな(ry

                とはいえ、無駄なget/setが大量に並ぶことは多々あるから、Lombokのアノテーションみたいな仕組みを標準で使えるようにしてほしいとは思うけど。

        • by Anonymous Coward

          要するに・・・

          ・呼び出し側はアクセッサの存在を考えずにa=1とかb=a+1と書いていい。
          ・実際の動作はクラスの中でアクセッサがなければデフォルトアクセッサ(?)みたいな
           単に代入するとか参照する動作となり、明示的にアクセッサがあればそれを呼び出す。

          って事かな? アノテーションでも使ってうまく定義出来ればよさげではある。

          # なんかセキュリティリスクがあるかもしれないけどその辺は全然考慮してません。はい。

    • by Anonymous Coward

      Lombok使うと幸せになれたよ

    • by Anonymous Coward

      publicフィールドって継承されるんだっけ。
      多態性とか使うときはどうなるんだろう。
      読み書き許可、読み込み専用、書き込み専用、継承考慮、多態性考慮、・・・とか使い分ければいいんだよ
      と言われればそれまでかもしれませんけど。

身近な人の偉大さは半減する -- あるアレゲ人

処理中...