- PR -

文字列をequalsで判定する時

«前のページへ 7|8|9|10|11|12|13|14|15|16|17 次のページへ»
投稿者投稿内容
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2008-02-13 16:46
引用:

あぶぽんさんの書き込み (2008-02-13 15:56) より:
少なくとも10年前にこの話題は有り得なかったんじゃないでしょうか？
僕は聞いたことがありません。


単にオブジェクト指向が普及したのがここ10年ぐらいというだけのことでは。
（オブジェクト指向自体はもっと昔から存在しますが）

Javaなどはプリミティブ型という非オブジェクト指向的な機能を持つ
ハイブリッド型ですが、純粋オブジェクト指向言語ならば、
リテラルもオブジェクトであるわけだから、メソッド呼び出しはできて当然。

先に発言したと思いますが、"hoge"という文字定数を「オブジェクト」と
捉える事が出来るか否かが「気持ち悪い」と感じるかどうかの分かれ目だと思います。

"hoge"はString型のオブジェクトなのだから、当然Stringの持つメソッドが呼び出せる。
だから、"hoge".equalsだろうが"hoge".charAtだろうが、呼び出せるのも当然。
Javaでは不可能ですが、純粋オブジェクト指向言語であれば、
123.hoge()といったようなメソッド呼び出しも可能になります。
これは123がオブジェクトではない環境下では「ありえない」コードだし、
その感性からすれば「気持ち悪い」ことでしょう。

私は「君子豹変す」をモットーとしていますから、いいものは取り入れる主義です。
その際に自分で取捨選択をするし、考察をするだけのこと。
ですからアジャイル教とか、ＸＰ教とかいう教団があったとしても決して信者にはなりません。
考えず、ただ信じるというのは技術者の姿としてはいかがなものか。
あぶぽん
大ベテラン
会議室デビュー日: 2005/10/20
投稿数: 205
投稿日時: 2008-02-13 17:03
引用:

先に発言したと思いますが、"hoge"という文字定数を「オブジェクト」と
（中略）
これは123がオブジェクトではない環境下では「ありえない」コードだし、


これに関してはまったく同意見です。

僕はSmalltalkもかじっていましたから、
Javaで、「"Hoge"」や「123」が純粋にオブジェクトになったときには、
感動ものでした。

「"hoge".charAt()」とか、「123.toString()」とか、
そういうのはまったく気持ち悪くないです。

僕が気持ち悪いのは、

「"Yes".equals(answer)」

です。

「answer.equals("Yes")」

と書きたいです。


引用:

ですからアジャイル教とか、ＸＰ教とかいう教団があったとしても決して信者にはなりせん。
考えず、ただ信じるというのは技術者の姿としてはいかがなものか。


その点、誤解でした。申し訳ないです。


引用:

あぶぽんさんの書き込み (2008-02-13 15:56) より:
少なくとも10年前にこの話題は有り得なかったんじゃないでしょうか？
僕は聞いたことがありません。

単にオブジェクト指向が普及したのがここ10年ぐらいというだけのことでは。
（オブジェクト指向自体はもっと昔から存在しますが）
[/quote]

そうでしょうか？

リテラルがどうのというのではなく、

左辺に比較対照がくるという文化って、アジャイル（特にＸＰ）が、
流行りだしてからだと思うのですが、

それ以降、サンプルコードなどでもＢ派が散見するようになりました。
未記入
大ベテラン
会議室デビュー日: 2008/02/07
投稿数: 115
投稿日時: 2008-02-13 17:19
引用:

Javaで、「"Hoge"」や「123」が純粋にオブジェクトになったときには、感動ものでした。 「"hoge".charAt()」とか、「123.toString()」とか、そういうのはまったく気持ち悪くないです。

123 が純粋なオブジェクトって･･･。いったい、どこの Java だよｗｗ
あぶぽん
大ベテラン
会議室デビュー日: 2005/10/20
投稿数: 205
投稿日時: 2008-02-13 17:46
引用:

未記入さんの書き込み (2008-02-13 17:19) より:
123 が純粋なオブジェクトって･･･。いったい、どこの Java だよｗｗ


勢いあまりました（爆）
ranco
大ベテラン
会議室デビュー日: 2007/11/02
投稿数: 112
投稿日時: 2008-02-13 19:29
> "hoge"という文字定数を「オブジェクト」と
> 捉える事が出来るか否かが「気持ち悪い」と感じるかどうかの分かれ目だと思います。
それは、まったく違います。All string literals in Java programs, such as "abc", are implemented as instances of this class.は、まず最初に教えますからね。

問題は、コードのその部分の文脈におけるprincipal object（主役）は何かということですから、principalがString varなら、今まさにvarをモンダイにしているのなら、
"literal".equals(var)と同様、anotherStr.equals(var)も気持ち悪いわけです。
コードの自然なわかりやすさ、リーダビリティにもつながってくる話だと思います。

逆に、"literal"がprincipalでvarが脇役である文脈なら、"literal".equals(var)が自然です。
この"literal"ってやつは、varと同じかな…、と、"literal"をモンダイにしているわけです。
OTAKE
会議室デビュー日: 2008/02/08
投稿数: 18
投稿日時: 2008-02-13 19:36
引用:
リテラルがどうのというのではなく、

左辺に比較対照がくるという文化って、アジャイル（特にＸＰ）が、
流行りだしてからだと思うのですが、

単純な比較文(==)で数値などを左に持っていくのは、Cの時代からありましたね。
定数を左に置くと、==と=を間違えたときにコンパイルエラーとなるので、間違いを見つけやすくなると。
これについても、信じる人と信じない人とで、議論が発生しています。

"hoge".equals(str)については、JUnitがメジャーになったころからじゃないですかね。
assertEquals()では期待される値("hoge"など)を最初(左)に持ってくるので、そこから、何でもかんでも文字列は左に書くと勘違いした人が多かったんじゃないかと想像しています。
assertEquals()でリテラルを左に書くのは、ちゃんとした意味があってのことなんですけどね。
未記入
大ベテラン
会議室デビュー日: 2008/02/07
投稿数: 115
投稿日時: 2008-02-13 19:43
引用:

それは、まったく違います。All string literals in Java programs, such as "abc", are implemented as instances of this class.は、まず最初に教えますからね。

ふーん。でも、この発言は、あなたのさきほどの発言と矛盾するんじゃないの？

引用:

初心者に教えるという文脈では、オブジェクトがそのインスタンスメソッドを呼び出すという形として、Stringオブジェクトがvarなら、var.equals("literal") しかありえません。

文字列リテラルがオブジェクトインスタンスであることを最初に教えてるんだったら、"literal" だって当然 String インスタンスだということを、その人は認識しているのだよね。なら、"literal".equals(var) だって理解できるんじゃないの？

あなたの最初の発言を「文字列リテラルがオブジェクトインスタンスであることを明確に理解していない初学者にとっては、var.equals("literal") しかありえません。」という意味だと私は認識したのですけど。私があなたの最初の発言の意図を取り違えていたということかな。
OTAKE
会議室デビュー日: 2008/02/08
投稿数: 18
投稿日時: 2008-02-13 19:57
昨日の私のまとめについては大した反論も無く、概ね同意してもらえたみたいです。
もちろん、全員の同意を得るのは無理ですが、感覚的には過半数の同意は得られたかなと思っています。

私の言いたいことは「A派しか認められない」ではなくて、「A派とB派にはこういうメリット/デメリットがある」ということなので、この議論の流れには満足しています。
各個人がA派になるのもB派になるのも、その人や参加するプロジェクト内で決めればいい話ですから。

読みやすいコードとは誰にとって読みやすいかが問題になります。
将来に渡って自分以外が見ることが無いなら、自分にとって読みやすければいいわけです。
誰が見るか分からない場合は、大多数の人が読みやすいと思うであろうコードになるわけです。
で、ここまでの流れから、B派よりもA派の方が多くの人にとって読みやすいと同意が得られました。

実際に書くときにA派とB派のどちらに属するかは、その人なりプロジェクトで決めればいいわけですね。
使い捨てのコードなら読みやすさよりも書きやすさを優先すればいいし、長期間保守が予想されるなら、最初にコストをかけても読みやすいコードにした方が、トータルのコストは節約できるでしょう。
また、人のコードを見ることが無い人に読みやすいコードの重要性を説いても、きっと理解はしてもらえないでしょう。

個人的には書くよりも読むほうが多いので、A派の人が増えてくれると助かりますが。
«前のページへ 7|8|9|10|11|12|13|14|15|16|17 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）