『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
プログラマー日記より。
「Setter/Getterを作るのがめんどくさかった」ので、 グローバル変数を多用して泥沼にはまってしまった人を見て、 嘆いている人を見て。
「Setter/Getter をいちいち作るのがめんどくさかった。」という言い訳を聞いて、めんどくさがらずにちゃんと作れ！と怒るのは簡単なんですが、そうじゃないんです。そうじゃなくてSetter/Getterを作るのがめんどくさい言語仕様に疑問を持つべきなんです。あるいは、Setter/Getterを作るのがめんどくさくないようにするにはどうしたらいいかを考えるべきなんです。
...
実は、初心者の疑問や意見には、ときどきハッとするものがあります。ただそれは普通に聞くと「初心者の戯言」にしか聞こえません。特に技術力があればあるほど、そういう傾向になります。これは仕方ないことではあるんですが、しかし頭の思考をそこから一歩抜け出して、「なぜこの初心者はこういうことをいったのだろう？」と考えてみることが大事です。なんというか、初心者の言葉を第三者として外から眺めてみる感じでしょうか。
その通り。その延長線上にRubyのデザインがある。
っちゅーか、たまに自分で大きめのプログラムをRubyで書いてみると 「こんなのめんどくさいなー」と感じることがあり、 それが文法の「改善」の動機になることは比較的多い。 見逃してはいけないデザイン上のインプットだと思う。
Rubyについては最近はだいぶ安定したけど。
というか、子供できちゃうと本当に時間がない。まつもとさんはよくできるなぁ、4人もいるのに。
それはもう経験の差ではないかと。もう１３年も父親やってますから。
なんてね、実際は内助の功が大きいのであった。 最初、父親に慣れてない頃は主に会社で開発してたから(自宅にはPCがなかった)、 子育てはあんまり影響してないし。 最近は上の子を活用したり。私の仕事はコミュニティがだいぶ肩代わりしてくれてるし。
『Z会と大学受験支援サイト』には、 各大学の著名卒業生のリストとかが載っているわけだが、 筑波大の「経済界」のリストに
まつもとゆきひろ - オブジェクト指向スクリプト言語Rubyの作者、情報学類卒
が入っているのはどうかしてると思う。もっとも、そのリストの先頭は
登大遊 - ソフトイーサ代表取締役、情報学類在学中
だったりするのだが。なんてACな。
しかし、「いとうまゆ」やら「犬丸りん」やらが同窓生だとは知らなかったな。
2006年忘年会。今回は和食。
今年は良かった。悪い良い方をする人も目立たなかったし、 宴会の余興も楽しめた。ギター演奏やら舞踊やら。 普段見れない才能を堪能した。
こういうのを見ると音楽的才能を伸ばさなかったことが悔やまれるな。 まあ、早いうちに人生をプログラミングに最適化してしまった結果ともいえるのだが。
食事にも会話にも余興にも満足した。 忘年会は来年もこうありたいものだ。
This work is licensed under a Creative Commons License.
>OB<br>Wikipediaのコピペと思われます。<br>http://ja.wikipedia.org/wiki/%E7%AD%91%E6%B3%A2%E5%A4%A7%E5%AD%A6
>Setter/Getterを作るのがめんどくさい言語仕様に疑問を持つべきなんです。<br>これもまた『言語を作成する設計者の視点』に偏った見方ですね。<br>言語の研究という意味では『言語仕様に疑問を持つ』『Setter/Getterを作るのがめんどくさくないようにするにはどうしたらいいかを考える』という態度は正しいかもしれません。しかし、別の視点……例えば「教育の研究」「指導方法の研究」という視点からすると、Setter/Getterを楽になるように言語仕様を見直す／支援機能を強化するなどの対応は、本質を教え込まずに表面的に取り繕っただけの非常に不味い対応かと思います。<br><br>確かにアイディアの種はそこら中に転がっていますが、全てのアイディアの種が、『その問題を解決するための正しいアイディアではない』ことに気をつけないといけないですね。
Wikipediaのコピペって、それって、GFDL守られていますか?
あ、ありました、失礼。
「匿名の臆病者」さんへ。<br><br>私の視点が「『言語を作成する設計者の視点』に偏った見方」であることには同意します。だって言語設計者だもん。また、「全てのアイディアの種が、『その問題を解決するための正しいアイディアではない』こと」には心から同意します。<br><br>ただ、一般的にそういう事実があることを示そうとするために用いられたと思われる「Setter/Getterを作るのがめんどくさくないようにするにはどうしたらいいかを考える」ことが「本質を教え込まずに表面的に取り繕っただけ」であるというご意見には賛成しかねます。<br>少なくともプログラミングの領域では、「教育のため」とかいうような視点を設計に導入することは大きな誤りだと思います。<br><br>ただ、「匿名の臆病者」さんは「すべてのアイディアの種が正しいものとは限らない」という最終的な結論を引きだすための例として「教育の研究」という視点を用いられただけでしょうから、本質でないことは理解しています。この点における反論は不要です。
＜Setter/Getterを楽になるように言語仕様を見直す／支援機能を強化するなどの対応<br>という発想自体がすでにSetter/Getterに呪われているように感じます。Rubyの場合、CluだかLispだかの流れを汲む「変数とメソッドを区別すること自体が錯覚なんだからどっちの姿をとってもいいじゃない」という立場、と理解しているのですが。(違ったらすいません)
これはあくまでも「ある言語(Java)の仕様に課題がある」ことを示す例なので、Rubyに適用してもあんまり意味はないでしょう。<br>Rubyの立場についてはご推察通りです。流れを汲むのはEiffelでしょうけどね(Lisp(CLOS)もCluも属性とメソッドの区別がある)。
Setter/Getterの問題って本当にJava言語の仕様の問題なのかなあ？<br>Java言語でもSetter/Getterを作るのが面倒だったらpublicなメンバ変数にすればいいし、必ずprivateにしなければならないという縛りはないはず。privateにしなければならないというのは慣習がそうなっているというだけで、その慣習を疑うべきだと思います。<br>元記事のグローバル変数うんぬんも誤りです。Javaでいうところのグローバル変数ってpublicなクラス変数のことだと思います。publicなインスタンス変数はきちんとオブジェクトにカプセル化されてますよ。
サブクラスでオーバーライドできないので「統一原理」の点からは「問題」ですよね。そんなの問題のうちに入らないってのは一つの立場だと思いますが。<br><br>グローバル変数うんぬんが誤りかどうかは元記事を書いた人ではないのでわからないのですが、publicなクラス変数はグローバル変数と意味的に等価で引き起こす問題も同じなのですから、その点をことさらに取り上げて「誤り」と断じてもあまり意味がないように思います。
大本のブログを読むと、C++で書いた時の話らしいんですが、いつの間にかJavaの話になっちゃってますね。最初にJavaの話をしだしたのは まつもとさんじゃないですし、言語レベルで言えば「getter/setter 作るのが面倒くさい」ってのはJavaも同じだとは思いますが。
>Java言語でもSetter/Getterを作るのが面倒だったらpublicなメンバ変数にすればいいし<br>publicなメンバ変数をあとからSetter/Getterに置き換えるのは、最初からSetter/Getterをつくるよりも何倍も面倒なわけで、未来永劫ポリモーフィズムも引数チェックもロギングもいらないと言い切れるのでなければ、その解決策はいかかがなものかと思います。(という前に何のためのSetter/Getterなのかを考えれば、こんな話は出ないと思いますが...)<br><br>>まつもとさん<br>悪い良い方 ⇒ 悪い酔い方<br>ですよね。
> 最初からSetter/Getterをつくるよりも何倍も面倒<br><br>Javaは知らんけど、いまどきの C++ はジェネリックプログラミングに毒されているので、そういう発想を突き詰めてゆくのであれば、最初 public な単純変数だったものでもラッパーで済むんですよね。たとえば int な変数を、operator int () と operator = (int) を持ったクラスに変えるとか。<br>オフトピックで失礼。
どうもよくわからないのですが、「Setter/Getterをいちいち作るのがめんどくさいから、グローバル変数にしてはまった」ということを、皆さん前提にして会話されてませんか?<br> private ←→ publicと、static ←→ 非staticは、直交した軸であり、Setter/Getterは、通常インスタンス変数をprivateにするために作るものだと思います。そして、グローバル変数は、staticなpublic変数です。「Setter/Getterを作るのが面倒だからグローバル変数にした」というのは、ふたつの軸を斜めに横切っているのであり、本当に単に「Setter/Getterを作るのが面倒」なだけであれば、yoosakiさんのおっしゃるとおり、publicなインスタンス変数にすればよいだけの話です。<br> もちろんそれはそれで問題があるのかもしれませんが、ふたつの問題をごっちゃにして議論するのは生産的ではないのではないでしょうか。satoshiさんの記事にある「本来あってはならない依存関係がたくさんできていた」というのは、どちらかというとstatic変数の「ひとつしかない」という特徴により発生しがちなもののように私には思えますし。
>publicなメンバ変数をあとからSetter/Getterに置き換えるのは、最初からSetter/Getterをつくるよりも何倍も面倒なわけで<br><br>その問題は「publicなメンバ変数をあとからSetter/Getterに置き換える機能」を開発環境に持たせることでも解決できるわけですよね。<br>Eclipseならリファクタリングのメニューから「フィールドのカプセル化」を選べば、指定した変数のSetter/Getterを作ったうえでその変数へのアクセスをSetter/Getter経由に置き換えるところまで自動でやってくれます。<br><br>もちろんこれはJavaの話なのでC++での事情は異なるかと思います。
>「Setter/Getterを作るのが面倒だからグローバル変数にした」<br><br>この対応の問題は『リソース管理の責任分担があいまいになること』で、その結果、<br>- 各プロセスがどこまでリソースを処理するのかがあいまいに<br> なり、依存関係が増大する<br>- リソースの責任分担が分散するため、リソースの管理が<br> 困難になる<br>といった問題が発生することでしょうな……<br>C++の場合、public メンバ変数についても同様のことが言えそうですね。Delphiの様にメンバ変数へのアクセスとアクセッサメソッドの表記方法が同一なら、最初はメンバ変数アクセスにして、きっちり管理する必要が出てきたらアクセッサメソッドに切り替える手もありますが、C++じゃリファクタリングが面倒ですね……<br><br>何だかんだいってもプログラムの基本はデータとアルゴリズムですので、いかにデータとアルゴリズムを支配・管理するかが重要なんでしょう。
＜その問題は「publicなメンバ変数をあとからSetter/Getterに置き換える機能」を開発環境に持たせることでも解決できるわけですよね。 <br>「リファクタリングされる可能性のある内部実装に利用者を依存させたくない」ためにメソッドで一端クッションを作るのがSetter/Getter(カプセル化)の意義なので、結局外部実装も入れ替える方針は本質的な解決ではないと思われます。少なくとも予防的な立場では完全に誤りでしょう。何より変更の影響範囲が理論上無限大に発散する可能性があるのは、主にプログラマにかける心理的な負荷が無駄に高いと思うのですが。
プログラマー日記には「もちろんEclipseではSetter/Getterを簡単に作れますが、そもそもたかがSetter/Getterを作るのにそんなウィザードみたいなのが必要な時点で間違っています」とあるので、Eclipseの機能では十分ではないと考えていらっしゃるのでしょう。良かったらリンク先を読んでください。<br><br>http://www.programmers-paradise.com/tdiary/?date=20051223#p02<br><br>まあ、今回の私の主張は「Javaは間違っている」でも「Getter/Setterは簡単に作れるべきだ」でもなく、「初心者の不満にヒントが隠されている」なので、個別の件がどうであっても別にかまわないんですが。
初心者の不満にヒントが隠されているかも知れないが、玉石混淆の状態から玉を探し出したいのですか。<br>じゃあ今回出てたSetter/Getterについて結局言語側の機能として必要ないという結論であれば（のように見える）これは玉ではないわけで、議論の発散ぶりを考えるにSN比を考えないと痛いね、という結論になる。<br><br>結論：作りたいやつが作りたいように作れ。だいたい作りたいやつだって同じ人間なんだから、作りたいやつが使いたいように作られるはず。
その通りです。今回の話からは初心者の意見には思ったよりも玉が多い（と、松本が思っている）ということを感じていただければと思います。<br><br>あと、私はykさんの結論に完全には同意しません。間違いとも思わないけど、「良いものを作る」ためにはあんまり役に立つ結論とは思えないので。
結局Setter、Getterのサポートに関して言語の機能として必要さそう。つまり初心者の意見には玉が多い（と思っている）。<br>うーん。<br>俺の読解力が無いだけか。つまり、引用中で意味があるのは「初心者の疑問や意見には、ときどきハッとするものがあります。〜略〜と考えてみることが大事です。」の部分だけで、前半が引用されてることでSetter、Getterの話なんだとミスリーディングしてるだけなんだな。<br>このコメントはどう見てもチラシの裏です。<br>ありがとうございました。
繰り返しになりますが、今回の最重要点はあくまでも「初心者の意見には玉が多い」です。<br><br>「Setter/Getter」については、私には常識に思えるレベルですが、同意していない人も多いようですし、OOSCすら読んでない人も多い状況ではまともな議論はできないでしょう。今回の主戦場でないところで無駄な議論はしたくないです。
つ「チラシの裏」