argonの日記: 利用者から見た Setter/Getter 10
前回は 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 にもこのような改良が入る日がくるだろうか。
あくまで私見として (スコア:1)
ってのをプログラムに「明示」することに意義があると思います。
言語でそのへんが隠蔽されてると
知らない人にとって逆にオブジェクト指向理解への妨げになるのでは。
もちろん、スクリプト言語の目指すところに「書きやすさ」があるので、それはそれとして‥
こちらも私見ですが (スコア:1)
利用者にはどうでもいいことだと感じます。
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# もスクリプト言語ではありません。
スクリプト言語にのみ採用される仕様というわけでもないですね。
Re:こちらも私見ですが (スコア:1)
> Java と同時期か、それ以降に設計された Delphi も C# もスクリプト言語ではありません。
> スクリプト言語にのみ採用される仕様というわけでもないですね。
ふむふむ、というわけでDelphiの本読んできたんですが
(3)の記法はDelphiでいうとこのプロパティを使ってる
てことでええのですかね。
素朴な疑問としてこれ
UMLと対応とれないんじゃないかと思うのですが
どうなんでしょ。
# とかいいつつ、便利でいいなぁという第一感想
Re:こちらも私見ですが (スコア:1)
> てことでええのですかね。
そうです。
> UMLと対応とれないんじゃないかと思うのですが
なぜそう思われたのかがわかりません。
UML が Java 向けに作られているからということですか?
UML 表現がないと開発できないわけでもないですね。
たとえば Enterprise Architect というアプリは C# や Delphi に
対応してますね。property をどう扱うかは見てませんが。
Re:こちらも私見ですが (スコア:1)
> なぜそう思われたのかがわかりません。
> UML が Java 向けに作られているからということですか?
> UML 表現がないと開発できないわけでもないですね。
UMLを出したのは、オブジェクト指向分析設計の
表記法として一番身近にあるからですね。
そもそもオブジェクト指向分析設計と
Delphiの「プロパティ」はそりが合ってないように思える
ということです。
(オブジェクト指向だと「状態」は「振る舞い」を通して変化するものですし)
そのへんのことをいろいろ検索してみると
どうも昔から議論の的(というかフレーム元‥)
になるらしいので、あまりつっこまないほうが
賢明のようです。
※参考 [atmarkit.co.jp] ← 長い && 脱線が激しい(笑
> たとえば Enterprise Architect というアプリは C# や Delphi に
> 対応してますね。property をどう扱うかは見てませんが。
残念ながらUML→ソースではどうなるか、情報が出てこないですね。
ただプロパティを使ったソース→UMLをすると、(ソースと比較して)冗長になるらしいです。
Re:こちらも私見ですが (スコア:1)
> 表記法として一番身近にあるからですね。
私が UML を使ってないから気にならないというのはあると思います。
property は更新、参照と役割が明確に決まっているのに
> そもそもオブジェクト指向分析設計と
> Delphiの「プロパティ」はそりが合ってないように思える
のはなぜですか?
> (オブジェクト指向だと「状態」は「振る舞い」を通して変化するものですし)
OO の言葉では「メッセージ送信」によって「振る舞い」が
起こされて「状態」が変化することですね。
言語でどういう記法であるかとは無関係だと思います。
Objective-C ならメッセージ送信は別の表記ですし、
C++ や Java での関数呼び出し表現は便法に過ぎません。
Re:こちらも私見ですが (スコア:1)
>> そもそもオブジェクト指向分析設計と
>> Delphiの「プロパティ」はそりが合ってないように思える
> のはなぜですか?
簡単な例でいうと、クラス図に「プロパティ」の入る隙間が無い
とこですかね。
私は分析開発手法の一つとしてオブジェクト指向を習い
その表記法の一つとしてUMLを知り
その実装法の一つとしてJavaを習得した
という人間なので
分析開発表記法と実装法にズレが少ないのが「好き」なんですね。
(「好き」であって、それが正義とかは考えてないですよ)
その立場からすると、「プロパティ」は「気持ち悪い」というだけです。
といいつつも、一プログラマとしてならばプロパティは便利だなぁと思うし
MVCでいうとこのモデルクラスはクラス図作ってると
「状態」の数*2「振る舞い」を作業的に書かないといかんので
「メンドクサ」とか思ったりします(笑
>> (オブジェクト指向だと「状態」は「振る舞い」を通して変化するものですし)
> OO の言葉では「メッセージ送信」によって「振る舞い」が
> 起こされて「状態」が変化することですね。
> 言語でどういう記法であるかとは無関係だと思います。
ここは「前者の立場でいえば」無関係ではないです。
OO分析設計開発の「理想郷」は、分析開発の成果物が
そのまま実装に置き換えられて、あとは「振る舞い」の
中身を書けば出来上がり、なわけで。
(あくまで理想で、実際はこんなうまくいかないわけですが)
その中身にプロパティが出てきちゃうと
例えば後で保守する人がソースとクラス図と見比べたときに
「ナンデスカコレ」ってことになっちゃうわけで。
そうすると
「開発設計表記にプロパティを表記できるようにすれば」
「いや、それは‥」
と、一つ前の私のコメントであげたURLのような議論が始まっちゃうんだと思います。
外野からすると不毛なので、これ以上踏み込まないほうが良いとおもいます。
> Objective-C ならメッセージ送信は別の表記ですし、
> C++ や Java での関数呼び出し表現は便法に過ぎません。
Objective-Cなんて初めて知りました。こんなんあるんですね‥
調べてみたところ、メッセージ送信の表記はメソッドの呼び出し方の話なので
別に言語依存してもいいところじゃないでしょうか。
プロパティとの話とはちょとズレてる気がします。
Re:こちらも私見ですが (スコア:1)
> 「いや、それは‥」
> と、一つ前の私のコメントであげたURLのような議論が始まっちゃうんだと思います。
で、プロパティのような表記がよくない積極的な理由はあるのですか?
UML は良くも悪くも Java と密接すぎなのでしょう。
私は UML などは最近流行のフローチャートの一種だと思っています。
それ自体で仕様を記述できるのでなければ techinical option のひとつにすぎません。
私は UML 使っていませんし、そのような対応であると知れば
これからも重要視しないでしょう。
> プロパティとの話とはちょとズレてる気がします。
method call は関数呼び出し風の表現である必要もないという例として挙げました。
Re:こちらも私見ですが (スコア:1)
>> 「いや、それは‥」
>> と、一つ前の私のコメントであげたURLのような議論が始まっちゃうんだと思います。
> で、プロパティのような表記がよくない積極的な理由はあるのですか?
一つ前にも書きましたが、善い悪いとかの話ではありません。
オブジェクト指向開発設計・および実装の流れでの中では
delphiの「プロパティ」という存在は、現在、浮いてしまっている
と、「私が思っている」だけです。
(何故そう思うかは前コメの例を見てください)
> UML は良くも悪くも Java と密接すぎなのでしょう。
ここは、私がJava以外のオブジェクト言語を習得していないので
コメできませぬ orz 不勉強ですみません。
私はUMLはコミュニケーションの道具と思っています。
UMLでモデリングされていれば、大人数での開発や保守
においても、少なくともUMLの読み方さえ知っていれば
自然言語の仕様書のみよりもスムーズに意思疎通が可能になるはずです。
また、顧客とのコミュニケーションにも
有用な技法がUMLには含まれています。
まあ、使う使わないは自由ですが
私はいろいろな職場をわたり歩いてきたので
標準化された「設計の成果物」が欲しくなってしまうのです。
# 特に保守、ソースが仕様書ってこともしばしばですからね( ´Д⊂ヽ
Re:こちらも私見ですが (スコア:1)
同意します。が、
> UMLでモデリングされていれば、大人数での開発や保守
> においても、少なくともUMLの読み方さえ知っていれば
> 自然言語の仕様書のみよりもスムーズに意思疎通が可能になるはずです。
残念ながら、この仮定が私の環境では成立しません。
つまり UML を読み書きできる体制ではありません。orz.
そのため UML のメリットを享受できず、単なるお絵かきレベルでしか使えません。
> また、顧客とのコミュニケーションにも
> 有用な技法がUMLには含まれています。
OOA/OOD のレベルで話をすることができれば有用なのかもしれませんね。
結局、私の周囲では Delphi や Ruby でのプロトタイプベース開発が
現実的な開発手法として使われています。