- - PR -
今から始めるJAVA
«前のページへ
1|2|3
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2003-03-26 20:36
>C++だったら、あれもこれも、あんなことやこんなことも・・・
>なんでJAVAはできんのや!! これについてはEffective C++が参考になるかも知れません. この本を初めて読んだとき,愕然としました. こんな欠陥言語が,今まで最も普及したOOP言語だったなんて! Javaが出た途端にヒットした理由を,初めて理解した気がします. 「なんでもできる便利な機能」が,いかに悪質なバグの原因になり得るか. それを排除することでどれだけ堅牢なプログラミングが可能になるか. やはり過去の失敗事例を勉強しておくことは重要ですね. >ってしらんだけかもしれません・・・(汁 本当に出来ない可能性もあります. でもtype safe enumのように,プログラミングスタイルを変更する ことでカバーできる場合がほとんどだと思います. | ||||
|
投稿日時: 2003-03-28 14:43
欠陥はちょっと言い過ぎやと思いますが・・・(汁
確かにJAVAに比べてやらなあかんことは気をつけないかんことは多いと思うけど・・・ JAVAでも適当に作ってたらNullPointerExceptionの嵐になったりとかするし。 ま、システムがハングすることは少ないとは思うけど無いことも無いし・・・ 私はC++は全然欠陥だとは思いませんよ。 欠陥があるのは作ったプログラムの方やし。 私は未だにC++のほうが好きですな。 JAVAはなんとなくなじめません。 ってか、C++に比べて制約が多い分使いにくいと感じることが多々ありあます。 安全性を重視するか自由度を重視するか。 やっぱりクラスの概念をストレートに表現するのは 自由度が高い分C++に分があると思いますよ。 って、やっぱり知らんだけかもしれませんが C++やったらあんなクラスやこんなクラスも作れるのに なんでJAVAは出来んのや!!(できるのかもしれんけど) って、いっつも思ってます。(ストレス溜まりまくり) | ||||
|
投稿日時: 2003-03-28 16:39
>JAVAでも適当に作ってたらNullPointerExceptionの嵐になったりとかするし。
>ま、システムがハングすることは少ないとは思うけど無いことも無いし・・・ それは多分設計ミスです. NullPointerExceptionとかダウンキャストとか,そういうのは極力使わないように するのがJava流です.(ダウンキャストはC++も同じか.) >私はC++は全然欠陥だとは思いませんよ。 >欠陥があるのは作ったプログラムの方やし。 まあそう思うのならお好きなように. #いつまでたっても「アプリケーションが不正な処理をしました.」 #が減らないのはどういうわけでしょうね. | ||||
|
投稿日時: 2003-03-28 20:15
>やっぱりクラスの概念をストレートに表現するのは
>自由度が高い分C++に分があると思いますよ。 #「クラスの概念をストレートに表現」って, #一体どういう設計してるんだろう....f(^^; >C++やったらあんなクラスやこんなクラスも作れるのに >なんでJAVAは出来んのや!!(できるのかもしれんけど) あ,ひょっとしてこれが原因なのでは. 発想がC++レベルなんで,Javaの機能が全然使いこなせていないんですよ. Cプログラマー上がりのJava初心者などでは良くあることのようです. 私の場合, 「Javaだったらこういうことが保証できるのに, C/C++だと保証できないからバグが出る可能性が排除できない〜!」 って,そういう意味でストレスが溜まりますね. C/C++を使う限り,開発効率の低下とバグの増大はまず避けられませんから. #記述性が欲しければ,多分Rubyを使うでしょう. #いずれにしてもC++を使うメリットは無い. | ||||
|
投稿日時: 2003-03-31 14:43
もう識者各位の意見があらかた出て、既に落ち着いた感がありますが、私も記事をみて一言もうさせていただきたい衝動に駆られてしまいましたので投稿させて頂きます。
「第4回 クラスの継承の本質を知る」については、そもそも「継承」が何を「継承」するのかという点が大きく本質とずれていると思います。 クラスの継承は、基本クラスの「セマンティクス」を継承することを意味すると私は考えます。 createCustomer()というメソッドがあった場合、このメソッドをオーバーライドする際は、メソッドの本来持っている「意味」を変えるようなオーバーライドは×でしょう。 つまりBaseCustomer.createCustomer()では、基本的な顧客を表すCustomerオブジェクトを作るか、「顧客オブジェクトを作成するメソッド」として抽象メソッドにし、派生クラスでは、VIPCustomer.createCustomer()など、更に意味(VIP顧客である)を追加した”顧客の作成”を実装すると思います。しかし、本記事の説明ではそのあたりが全く説明されていません。 また、オブジェクト指向の設計において非常に重要なファクターと私が考えます、「比喩」を否定しているように見えます。オブジェクト指向設計では業務に登場する「役割」等をうまく「喩え」てクラスの粒を導きだしたりする作業が重要と私は考えます。 このあたりが「抽象的なので理解しにくい」点であるということは私も同感ですが、この部分をなくして(むしろ否定して)オブジェクト指向(OOPLであるJava言語)を語るのは如何なものか?と強く思います。 私は、皆様が申されるように、この記事を読んで理解が進むのであれば幸いかとも思いますが、おそらくその理解は誤った方向を向くと思われるので、多分に危機感を感じます。 | ||||
|
投稿日時: 2003-03-31 19:46
メリット・デメリットというより、好き嫌いから来てます。 java嫌い、C++好き。 ということで。 なんていうか、いろいろいじりたいというか(汁 やっぱり、しってるしってないの部分が大きいですね。 javaも使い込んでいけば好きになると思いますが。 2年と10数年の違いはやっぱりでかいです。 どうしても慣れてる方がやりやすいというかなんというか。 ま、哲学や宗教の話はこれぐらいにしましょう。 | ||||
|
投稿日時: 2003-04-01 00:46
同感です。またその前の第3回の「クラス」の説明についても内容に大いに疑問があります。 クラスという概念を理解する上で(あるいは説明する上で)、カプセル化と多態性は 非常に重要なポイントだと思うのですが、何故かそれらには全く触れられていません。 (尤も多態性については述べるとしたら第4回の「継承」ところでしょうが) …いや、それ以前に「クラス」や「メンバ」や「メソッド」とは何かといった説明さえ 十分にされているとは言いがたいですね…。 例題にはmain()以外のメソッドは存在せず、更にpublicや、privateといったアクセス 限定子も(public static void main(String args[])という「お約束」の部分を除けば) 出てきていません。 (この説明だと「なんだ!要はCの構造体と同じじゃないか!」という感想になるでしょう) オブジェクト指向やJavaの初学者に対してこのように「クラス」を説明することは、 クラスひいてはオブジェクト指向全体についての理解を歪めることになると思います。 [ メッセージ編集済み 編集者: みたらいなおゆき 編集日時 2003-04-01 00:58 ] | ||||
«前のページへ
1|2|3
