- - PR -
現在のインスタンスを参照するthisキーワード、付ける？ or 付けない？
| 投票結果総投票数：259 | |||
|---|---|---|---|
| 付ける |  |
99票 | 38.22% |
| 付けない | |
66票 | 25.48% |
| 付けたり付けなかったり | |
94票 | 36.29% |
| |||
| 投稿者 | 投稿内容 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-07-12 09:09
> 「this.Foo」とあると、何となく、何故か、
> 「インスタンスの外部からもアクセス可能なメンバに内部からアクセス」っぽく感じる。 分かった、VB6を使っていたときのクセだった。 VB6では、Meで修飾すると、非公開メンバを呼び出せない。 VB 2005なら、非公開メンバも呼び出せる。 | ||||||||||||||||||||
|
投稿日時: 2007-07-12 09:44
おはようございます。
以下、完全に私のオレオレ理論ですが… C++の場合、演算子のオーバーロードやコピーコンストラクタなどで ”自分自身のインスタンスと他のインスタンスを区別する必要があります。” this, other, rhs(right hand side), lhs(left hand side)などのインスタンスのうち、 C++では暗黙の引数であるthisポインタは、キーワードにする必要があったかのかと… ＃今でこそ無闇な演算子オーバーロードは悪という風潮ですが、 初期のころのC++は、演算子オーバーロードの使用に積極的であったように思います。 なので、C++でthisを使用する場合は、”他のインスタンスとの区別をする”という 意味合いが強いのではないかと思います。 逆に言えば、自インスタンスと他インスタンスを区別する必要がないのなら わざわざthisを書かなくてもいいんじゃないの… という感じではないでしょうか。 ＃少なくとも私はそういう感じで使ってます。 | ||||||||||||||||||||
|
投稿日時: 2007-07-12 12:37
for(int i = 0; i < 100 ; i++)
Console.WriteLine("i = {0}", i); これにthisを付けてみそ〜〜。 と言う訳で付けたり付けなかったり。 | ||||||||||||||||||||
|
投稿日時: 2007-07-13 00:07
thisをつけるメリットがたくさん上がっているようです。たいへん説得力がある意見も多く、私も徐々につけるのがよい派に変化してきています。少なくとも、「つけない」から、「付けたり付けなかったり」へは転向してしまっています。
しかし。とはいえ。つけないメリットがどうも理解されていないように感じるので、つけないメリットの説明もせねばと、孤軍奮闘ですがもう少し頑張ってみようと思います。
愚行ってのは確かにたいへん言葉がきついですね。すみません。 いや、そのきつい部分に賛同というわけではないのですが。 賛同ってのは、内容の部分です。
ふむ。 その辺が今一つ伝わらない原因なのではないでしょうか。 少なくとも私が言っているのは、"実装上の工夫"の話ではないのですから。 coasmさんも、実装レベルまで引きずり落とす、と言ってますし。 詳しく説明しようとしたのですが、長く書くほどわかりにくくなるのなるべく簡潔に書くと。 つまるところ、コードを埋め尽くすのは抽象的なものであるべきだ、っていうことです。 悩むべきなのは、何を作りたいかであって、どう作りたいかではない。ということです。 アクセス範囲とかも重要なのは間違いないですが、先頭文字の大文字小文字くらいの目立ち具合が適切ではないのか？ また、大文字小文字は定義のときだけ気をつければインテリセンスに任せきりでいいですが、thisは書くとき、訂正するときに、常に人間が注意を払っていないといけない。 重要さに比較して、使うコストが大きすぎるのではないか、ということです。 設計については、やっぱり私がへぼなだけかもしれないような気もしてきました。 いずれにしても、実際にはわざわざ言うほど手間がかかるわけではないので、あまり関係なかったかもしれません。 やっぱり修正時の手間よりは、読む時に常に読みやすく、という方がメインとなると思います。 ただ、具体例を質問されたのがありましたので、それだけでも簡潔に。
機能のみの提供なので静的クラスの方が使いやすいかと思って作っていたら、ポリモーフィズムを使う必要が出てきたのでインスタンスを利用するように書き換えた、ことがあります。内部で分割していて、かつ外から見えないからいいやとprivateフィールドを使っていてちょっと面倒だったことが確か数度。thisと言っても、メソッドの呼び出しの話になりますね。
具体例としては、 フィールドやメソッドをprivateで指定しておけば、クラス外や継承先ではその存在を忘れていられる。 メソッド内変数でも、スコープを工夫することにより、離れた場所では忘れていることができる。 とかそういうことですね。 あとは。
thisをつける派の方が、趣味でやっているなら自由だけど、などと言っていたので、thisをつけない派としてもちゃんと業務のことを考えているのだと明記しておく必要を感じて書きました。 それを見て、thisをつけない派が自分たちだけが業務のことを考えていると解釈されたなら。 なかなか皮肉で不毛なことですね。 ひょっとして、お互いに同じことを感じあっているだけなのでしょうか。 | ||||||||||||||||||||
|
投稿日時: 2007-07-13 09:40
実装と設計を自分の定義したルールに合わせるという意味を持ちますから、そちらのルールと異なるというだけだと思います。 手段が異なるだけでどちらも同じところを目指しているのだと思います。
これは同名を使う場合の話ですね。 私の場合は、プロパティ変数ではアンダースコアをつけているため頭 1 文字を除けば同名になりますが、上記の問題にはヒットしません。 コンストラクタは同名を使うパターンが多いですが、これは "絶対的に明示すべき" だと考えているので問題なしと判断しています。 大文字小文字だけとなると、VB の場合はそれ以外の場面で注意が必要になりますね。 同名がある前提だと C# も気を付けるという点では同じかもしれませんが。
なるほどです。 今のところはそういった経験はありませんが、あり得る話ではあると思います。 ご説明ありがとうございます。
(ひとつ前の投稿で書こうとした内容のままになってしまいますが) そもそもそのためのアクセス修飾子なわけですが、"this" は、インスタンス内での話なのでクラス外は関係ないのではないでしょうか? 「プライベート メンバにすればそのクラスの中では忘れても良い」 なんてことにはなりません。 それだったらローカル変数やブロック変数にするべきでしょう。 どこから隠蔽したいがために Private なのかという前提を考えるとどうも私とはクラス設計思想さえも異なっているのかもしれません。
もちろんそうなのでしょう。 最初にも書きましたが目指しているところは同じで、趣が個人によって依存しているから分かれているにすぎません。 # 予想どおり、「付けたり付けなかったり」 が急に増えてきましたね。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||||||||||
|
投稿日時: 2007-07-13 11:59
「感じていること」の解釈が合っているか自信はないのですが… 先のまとめでも強調しておきましたが、
という目的は概ね同意が取れているのだと思います。 この目的に限って言えば、this派とプレフィックス派がいて、そのどちらでもない という主張の人はいませんね。系統は違えど目的は同じことの証左ではないでしょうか。 よりメタな目的で言えば「生産性の向上」という話で、 インテリセンスの利用や教育の効果といった話題も同じ方向を見ているのだと思います。 | ||||||||||||||||||||
|
投稿日時: 2007-07-14 23:58
どちらでもないという主張です。 私のほかにも二人くらい見かけたような覚えが。 はっきりと明言していたわけではないですが。 私も明言していなかったかな？ 意思の疎通というのは非常に難しいものです。 とにかく、私はどちらでもない派です。 理由としては。 適切な変数名を付けていれば、紛らわしいことはあまりないと思うのです。 クラス全体で話題となっている「もの」を示すものを呼ぶ名前が、 メソッド内で使う「もの」を呼ぶためにつけられた名前と全く同じになるってことは、 あまりないのではないでしょうか？ もしそれであえて同じ名前をつけたくなるようなら、 メソッド内の出来事とクラス全体にかかわる出来事は全く別に扱うという認識でそのメソッドは書かれているということで、 その場合はthisをつけるべきでしょうし、またつけないとバグになるわけですが。 クラスフィールドが存在したかしないか覚えきれないほど多量のクラスフィールドがある状況があるとしたら、クラスが大きすぎるんじゃないか、とも思えますし。 日本語でも、たとえば母親を示す時に、会社なんかでいう時や、家に友達を読んだときには「うちの母親」(myFamiry.Motherとかthis.mother)なんて表現を使わないとわけがわかりますが、家の中でその意味を伝えようとすると、お母さん（何もつけないmother)とかになるでしょう。 家の中で家族相手にいちいち、我が家の母親(this.mother)って言っていたら、話が伝わりやすいかというと。 くだくだしくってかえって分かりにくいだけじゃないでしょうか。 とはいえ。よく自分の経験を考えてみたら。 多人数での開発も、クラス設計もやったことはありますが。 一つのクラスを複数の人間でいじるってことは、あまり経験がないのですよね。 実際、そんなに混乱するものなのでしょうか？ 人のプログラムを見ていて、メソッド変数とクラスフィールドが同じ名前になっていて、 どっちを書いているかわからなくて困ったということはそんなにあることなのでしょうか？ 特にVSを使っていると、クラスフィールドではXMLコメントが表示されたりもするので、混乱するようには思えなかったりするのですが。 実際やってみると、混乱するものですか？ [ メッセージ編集済み 編集者: まりも 編集日時 2007-07-14 23:59 ] | ||||||||||||||||||||
|
投稿日時: 2007-07-15 02:42
プレフィックスではない適切な変数名、ということですね？ 変数名に限れば私はプレフィックス派。 理由は、複数言語を使うので、プレフィックスは言語依存が少なくルールとして身に付きやすいから。 | ||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。