パスワードを忘れた? アカウント作成
544963 journal

argonの日記: 利用者から見た Setter/Getter 10

日記 by argon

前回は Setter/Getter の作成者の視点だったが、
利用者の視点から検討してみることにする。

Setter/Getter を用いるときとそうでないときで、
利用する記述が異なるとストレスを感じる。
Java の場合、公開メンバ変数にアクセスする記述は
以下になる。

bar = foo.item ;
foo.item = bar ;

if ( foo.item == baz ) hoge() ;

Setter/Getter を介すると、記述が大きく変わる。

bar = foo.getitem() ;
foo.setitem( bar ) ;

if ( foo.item() == baz ) hoge() ;

Delphi の場合は、公開メンバアクセスと property による
Setter/Getter の呼び出しの記法は同じにできる。
オブジェクトの実装に因らないので、自然に隠蔽されている。

bar := foo.item ;
foo.item := bar ;

if foo.item = baz then hoge ;

Ruby の場合は、公開メンバ変数というものを持たずに Setter/Getter を
通してアクセスする。accessor は、メンバ操作と同様の記法であるため
読みやすい。

bar = foo.item
foo.item = bar

if foo.item == baz then hoge end

理由があるにせよ、メンバアクセスと Setter/Getter で記法が異なって、
実装を隠蔽しきれていないというのは OOP としては欠点だ。
Eclipse などの環境が Refactoring してくれても扱いづらいと思う。

C#, VB.Net なら get/set で定義しておくことで同様に書けるし、
C++ なら operator overroad するものかもしれない。
いつか Java にもこのような改良が入る日がくるだろうか。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • Javaの場合、Setter/Getterを使ってアクセスしてるよ
    ってのをプログラムに「明示」することに意義があると思います。

    言語でそのへんが隠蔽されてると
    知らない人にとって逆にオブジェクト指向理解への妨げになるのでは。
    もちろん、スクリプト言語の目指すところに「書きやすさ」があるので、それはそれとして‥
    • by argon (3541) on 2005年12月30日 16時45分 (#857428) 日記
      > ってのをプログラムに「明示」することに意義があると思います。

      利用者にはどうでもいいことだと感じます。

      OOP は実装方法を隠蔽することに意義があるので、
      実装が見えすぎるのはよくないと思います。

      > 知らない人にとって逆にオブジェクト指向理解への妨げになるのでは。

      記法は OO理解への妨げにはならず、むしろ助けになると考えます。

      C で OOP していたころは下記(1)で書いてましたが、
      Java なら (2) のように書けます、
      C# なら (3) の記法が使えます。

      (1) Foo_set_item(*foo, bar);
      (2) foo.setitem(bar);
      (3) foo.item = bar;

      > もちろん、スクリプト言語の目指すところに「書きやすさ」があるので、それはそれとして‥

      Java と同時期か、それ以降に設計された Delphi も C# もスクリプト言語ではありません。
      スクリプト言語にのみ採用される仕様というわけでもないですね。
      親コメント
      • >> もちろん、スクリプト言語の目指すところに「書きやすさ」があるので、それはそれとして‥
        > Java と同時期か、それ以降に設計された Delphi も C# もスクリプト言語ではありません。
        > スクリプト言語にのみ採用される仕様というわけでもないですね。
        ふむふむ、というわけでDelphiの本読んできたんですが
        (3)の記法はDelphiでいうとこのプロパティを使ってる
        てことでええのですかね。

        素朴な疑問としてこれ
        UMLと対応とれないんじゃないかと思うのですが
        どうなんでしょ。

        # とかいいつつ、便利でいいなぁという第一感想
        親コメント
        • by argon (3541) on 2005年12月31日 17時45分 (#857793) 日記
          > (3)の記法はDelphiでいうとこのプロパティを使ってる
          > てことでええのですかね。

          そうです。

          > UMLと対応とれないんじゃないかと思うのですが

          なぜそう思われたのかがわかりません。
          UML が Java 向けに作られているからということですか?
          UML 表現がないと開発できないわけでもないですね。

          たとえば Enterprise Architect というアプリは C# や Delphi に
          対応してますね。property をどう扱うかは見てませんが。
          親コメント
          • >> UMLと対応とれないんじゃないかと思うのですが
            > なぜそう思われたのかがわかりません。
            > UML が Java 向けに作られているからということですか?
            > UML 表現がないと開発できないわけでもないですね。
            UMLを出したのは、オブジェクト指向分析設計の
            表記法として一番身近にあるからですね。

            そもそもオブジェクト指向分析設計と
            Delphiの「プロパティ」はそりが合ってないように思える
            ということです。
            (オブジェクト指向だと「状態」は「振る舞い」を通して変化するものですし)

            そのへんのことをいろいろ検索してみると
            どうも昔から議論の的(というかフレーム元‥)
            になるらしいので、あまりつっこまないほうが
            賢明のようです。
            参考 [atmarkit.co.jp] ← 長い && 脱線が激しい(笑

            > たとえば Enterprise Architect というアプリは C# や Delphi に
            > 対応してますね。property をどう扱うかは見てませんが。
            残念ながらUML→ソースではどうなるか、情報が出てこないですね。
            ただプロパティを使ったソース→UMLをすると、(ソースと比較して)冗長になるらしいです。
            親コメント
            • by argon (3541) on 2006年01月01日 22時30分 (#858149) 日記
              > UMLを出したのは、オブジェクト指向分析設計の
              > 表記法として一番身近にあるからですね。

              私が UML を使ってないから気にならないというのはあると思います。

              property は更新、参照と役割が明確に決まっているのに

              > そもそもオブジェクト指向分析設計と
              > Delphiの「プロパティ」はそりが合ってないように思える

              のはなぜですか?

              > (オブジェクト指向だと「状態」は「振る舞い」を通して変化するものですし)

              OO の言葉では「メッセージ送信」によって「振る舞い」が
              起こされて「状態」が変化することですね。
              言語でどういう記法であるかとは無関係だと思います。
              Objective-C ならメッセージ送信は別の表記ですし、
              C++ や Java での関数呼び出し表現は便法に過ぎません。
              親コメント
              • > property は更新、参照と役割が明確に決まっているのに
                >> そもそもオブジェクト指向分析設計と
                >> Delphiの「プロパティ」はそりが合ってないように思える
                > のはなぜですか?
                簡単な例でいうと、クラス図に「プロパティ」の入る隙間が無い
                とこですかね。

                私は分析開発手法の一つとしてオブジェクト指向を習い
                その表記法の一つとしてUMLを知り
                その実装法の一つとしてJavaを習得した
                という人間なので
                分析開発表記法と実装法にズレが少ないのが「好き」なんですね。
                (「好き」であって、それが正義とかは考えてないですよ)

                その立場からすると、「プロパティ」は「気持ち悪い」というだけです。

                といいつつも、一プログラマとしてならばプロパティは便利だなぁと思うし
                MVCでいうとこのモデルクラスはクラス図作ってると
                「状態」の数*2「振る舞い」を作業的に書かないといかんので
                「メンドクサ」とか思ったりします(笑

                >> (オブジェクト指向だと「状態」は「振る舞い」を通して変化するものですし)
                > OO の言葉では「メッセージ送信」によって「振る舞い」が
                > 起こされて「状態」が変化することですね。
                > 言語でどういう記法であるかとは無関係だと思います。
                ここは「前者の立場でいえば」無関係ではないです。
                OO分析設計開発の「理想郷」は、分析開発の成果物が
                そのまま実装に置き換えられて、あとは「振る舞い」の
                中身を書けば出来上がり、なわけで。
                (あくまで理想で、実際はこんなうまくいかないわけですが)
                その中身にプロパティが出てきちゃうと
                例えば後で保守する人がソースとクラス図と見比べたときに
                「ナンデスカコレ」ってことになっちゃうわけで。

                そうすると
                「開発設計表記にプロパティを表記できるようにすれば」
                「いや、それは‥」
                と、一つ前の私のコメントであげたURLのような議論が始まっちゃうんだと思います。

                外野からすると不毛なので、これ以上踏み込まないほうが良いとおもいます。

                > Objective-C ならメッセージ送信は別の表記ですし、
                > C++ や Java での関数呼び出し表現は便法に過ぎません。
                Objective-Cなんて初めて知りました。こんなんあるんですね‥
                調べてみたところ、メッセージ送信の表記はメソッドの呼び出し方の話なので
                別に言語依存してもいいところじゃないでしょうか。
                プロパティとの話とはちょとズレてる気がします。
                親コメント
              • by argon (3541) on 2006年01月02日 19時45分 (#858346) 日記
                > 「開発設計表記にプロパティを表記できるようにすれば」
                > 「いや、それは‥」
                > と、一つ前の私のコメントであげたURLのような議論が始まっちゃうんだと思います。

                で、プロパティのような表記がよくない積極的な理由はあるのですか?
                UML は良くも悪くも Java と密接すぎなのでしょう。
                私は UML などは最近流行のフローチャートの一種だと思っています。
                それ自体で仕様を記述できるのでなければ techinical option のひとつにすぎません。
                私は UML 使っていませんし、そのような対応であると知れば
                これからも重要視しないでしょう。

                > プロパティとの話とはちょとズレてる気がします。

                method call は関数呼び出し風の表現である必要もないという例として挙げました。
                親コメント
              • >> 「開発設計表記にプロパティを表記できるようにすれば」
                >> 「いや、それは‥」
                >> と、一つ前の私のコメントであげたURLのような議論が始まっちゃうんだと思います。
                > で、プロパティのような表記がよくない積極的な理由はあるのですか?
                一つ前にも書きましたが、善い悪いとかの話ではありません。
                オブジェクト指向開発設計・および実装の流れでの中では
                delphiの「プロパティ」という存在は、現在、浮いてしまっている
                と、「私が思っている」だけです。
                (何故そう思うかは前コメの例を見てください)

                > UML は良くも悪くも Java と密接すぎなのでしょう。
                ここは、私がJava以外のオブジェクト言語を習得していないので
                コメできませぬ orz 不勉強ですみません。

                私はUMLはコミュニケーションの道具と思っています。
                UMLでモデリングされていれば、大人数での開発や保守
                においても、少なくともUMLの読み方さえ知っていれば
                自然言語の仕様書のみよりもスムーズに意思疎通が可能になるはずです。
                また、顧客とのコミュニケーションにも
                有用な技法がUMLには含まれています。

                まあ、使う使わないは自由ですが
                私はいろいろな職場をわたり歩いてきたので
                標準化された「設計の成果物」が欲しくなってしまうのです。
                # 特に保守、ソースが仕様書ってこともしばしばですからね( ´Д⊂ヽ
                親コメント
              • by argon (3541) on 2006年01月02日 23時30分 (#858406) 日記
                > 私はUMLはコミュニケーションの道具と思っています。

                同意します。が、

                > UMLでモデリングされていれば、大人数での開発や保守
                > においても、少なくともUMLの読み方さえ知っていれば
                > 自然言語の仕様書のみよりもスムーズに意思疎通が可能になるはずです。

                残念ながら、この仮定が私の環境では成立しません。
                つまり UML を読み書きできる体制ではありません。orz.
                そのため UML のメリットを享受できず、単なるお絵かきレベルでしか使えません。

                > また、顧客とのコミュニケーションにも
                > 有用な技法がUMLには含まれています。

                OOA/OOD のレベルで話をすることができれば有用なのかもしれませんね。

                結局、私の周囲では Delphi や Ruby でのプロトタイプベース開発が
                現実的な開発手法として使われています。
                親コメント
typodupeerror

私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson

読み込み中...