【Java叩き】なぜ年寄りはOOについてゆけないのか 4

その理由は、過去の栄光に縋り付いたバカだから。

彼らがオブジェクト指向を理解できない理由とは？
ただの時代遅れなのか？

前ｽﾚ
【Java叩き?】なぜ年寄りはOOを受け入れないのか 3
http://pc8.2ch.net/test/read.cgi/prog/1115573816/
【とりあえず】Java叩き【2回戦突入】
http://pc8.2ch.net/test/read.cgi/prog/1111397014/
Java叩き【年寄りが若年層を虐めているという構図】
http://pc5.2ch.net/test/read.cgi/prog/1095657902/

発端となったブログ
なぜ年寄りはOOを受け入れないのか
http://feather.cocolog-nifty.com/weblog/2005/05/oo_c9ac.html
Java叩き
http://feather.cocolog-nifty.com/weblog/2004/09/java.html

関連ｽﾚ 【C言語厨はなぜバカなのか】ｼﾘｰｽﾞw
C言語厨はなぜオブジェクト指向が理解できないのか
http://pc8.2ch.net/test/read.cgi/prog/1096039623/
C言語厨はなぜオブジェクト指向がわからないか★２
http://pc8.2ch.net/test/read.cgi/prog/1129989149/

http://feather.cocolog-nifty.com/weblog/2004/09/java.html

09/19/2004
Java叩き
にちゃんねるのプログラム板、プログラマ板ではJavaプログラマ(及びJava言語)を軽ん
じているス レッドが多い。
そこでは「Javaしかできないプログラマは駄目だ」という論理がしばしば展開されている。
しかし、考えてみると、Javaしかできないプログラマというのは、少なくともJavaが現れた後
にプログラマになった人である。
従って、大半が若い人である。
ということは、Javaプログラマ叩きは、年寄りが若年層を虐めているという構図というわけか。

私自身の経験より、私はCしかできなくなおかつ他の言語を学ぼうとしないプログラマが嫌いである。
もっとも、C言語以外のある言語だけしかできないプログラマに会ったことがまだ無いわけで、
もしかするとVBしかできないプログラマの方が潜在的には嫌い であるかもしれない。

なぜ年寄りはOOを受け入れないのか
http://feather.cocolog-nifty.com/weblog/2005/05/oo_c9ac.html

05/07/2005
なぜ年寄りはOOを受け入れないのか
(OOで開発を行うと昔とは全く違って素晴らしいシステムが出来上がる、という提言に対して)
そんなわけない、信じねえよ。
というのがこのスレッドにおけるOO非支持者の考えの根元にあるような。
(あとはもう少し卑近な考え「自分が今使ってる言語で不自由ない」
「今使ってる言語と同じ手段では(OOPLのひとつである)Javaで目的を達成できない」などか。)


冒頭の信じねえよ、という考えは正しいと思うし、もし信じてしまっている人がいれば
それはそれでどうかと思う。
しかし、では、どのようなアプローチで大規模化するシステム開発に対応していくのだろうか。

『C言語厨の特徴』のまとめ

●C言語厨はC++という言葉だけに酔いしれていたことが証明された。
●C言語厨は中身はC言語のみのコードでも拡張子をcppにしただけでC++熟練者なったと勘違いしている。
●C言語厨はヘッダファイルの使い方を間違えてオブジェクト指向を理解できないでいる。
●C言語厨はとにかく継承すれば拡張して再利用になると勘違いしてスパゲティコードを量産している。
●C言語厨はオブジェクト指向＝継承のみだと勘違いしている。
●C言語厨はJavaをライバル視し目の敵にして必死に叩こうとして変なスレを立てるも自惚れと厚顔無恥が目立つ。
●C言語厨はJavaエンジニアよりも自分の能力が優れていると勘違いし、自惚れている。
●C言語厨は問題を出して腕を試すと称して自分の宿題を他人にやらせようとするw
●そして相手が忙しいことも無視して返答を求めることにせっかちw
●相手に即答を求めることから、C言語厨は暇人NEETである可能性が高い
●C言語厨はC言語のenumとJava5のenumとの区別がつかない。
●C言語厨はResourceBundleの使い方も存在も知らない。

●C言語厨はレス内容のアホさ加減から友達が少なく誰かに相手にして貰いたがっていることが
　C言語厨の精神状態を伺わせている。
●C言語厨はグローバル変数が大好き。C言語厨はグローバル変数に取り憑かれているために
　いつまでたってもオブジェクト指向を理解できない。
●C言語厨はどんな大規模開発でも関数があればクラスなんて必要ないと豪語する。
●なっ、なんとぉ！ C言語厨はHibernateを知らないことが発覚してしまったぁ！
●C言語厨の知っているオブジェクト指向は継承のみで、
　ポリモーフィズム、カプセル化、委譲、集約も知らないという間抜けさ。
●C言語厨はバカだからクラスとは構造体とまったく同じだと思い込んでいる。
●C言語厨にクラスを作らせると性質がほとんど構造体と変わらなくなる。
●そしてメンバ関数はすべてstaticになるという失態。
●C言語厨はオブジェクト指向がわかってないのでメンバ変数が全くないクラスばかり作る。
●C言語厨は名前空間を知らないため、おかしな関数名をつける癖がある。
●C言語厨はデザインパターンを知らないから、デザインパターンを知っているC言語厨よりも高スキルな人間に対して
　「ポリモーフィズムを知らないだろw」と喧嘩を売ろうとする。そのさまはまるで蟻が像に喧嘩を売っているかのよう。
●オブジェクト指向が苦手なC言語厨の年齢層は30,40代に多い。まるでCOBOLerのように。

年寄りがオブジェクト指向についていけない理由は
制御工学ばかりやっていることと
抽象化の概念を理解できないことに尽きる。

オブジェクト指向を理解できない厨は
メタフィジックス(形而上学)を理解できない厨でもある。
つまり代数学も理解できない厨でもある。

ベクトル解析も理解できない厨でもあったりする。

どうでもいいんだけどさ、せっかくオブジェクト指向設計
してるのにレビューで指摘して構造化設計のように修正ってどういうこと？
オブジェクト指向推進してる会社のくせに。
まあ、説明するの面倒くさいから素直に聞き入れる俺も問題なんだけど。

>>4-5
●C言語厨は中身はC言語のみのコードでも拡張子をcppにしただけでC++熟練者なったと勘違いしている。
●C言語厨はグローバル変数が大好き。C言語厨はグローバル変数に取り憑かれているために
　いつまでたってもオブジェクト指向を理解できない。

いくらなんでもこんな奴いねぇだろ

>>7
オブジェクト指向設計のメリットとデメリットを述べよ
それが語れないでオブジェクト指向教に入信してる
おまえにあれこれ言う資格なし

はっちゃけて覚えようとしないからだよ。
変に学術学術した見方で覚えようとする奴ばっか。

勉強、というか自己研鑽をやめたら技術者は終わり。
年寄りに限らずOOについていけない輩はそういうこと。

だと思うが・・・

>>11
ぜんぜんちげーよ。
わくわくが足りねーんだよ奴らは。

>わくわくが足りねーんだよ奴らは。

同意。

胸ワクワクを失った代わりに、心臓バクバクを手に入れた！

>>14
ソースを見ると動悸がするのか？
精神的なものだから病院に行って薬貰ったほうがいいぞ

Java屋だけどCOBOLやLisp見て胸が躍る毎日だよ。
夜寝るとき吐き気まで伴って天国行きそう♪

これからは関数型言語、ラムダ抽象がわからないOO房が
同じような目にあう時代がくるかもよ。

>>17
そうでもないよ。
関数型言語とかラムダ抽象とかぐぐればいいんだし。

(´-`).｡ｏＯ（そういや、関数型言語は使ったこと無いなぁ。何か触ってみようかな？

>>9
メリットはね、楽になることがある。
デメリットはね、楽にならないことがある。

これ以上何があるってんだ？本質はこれだぞ。
小難しいことばっか期待して言って、うまくまいてるつもりか？
忘れるな、見抜く人は見抜く。

単純に学習しないからじゃねーの？

わくわくさん
ttp://www4.ocn.ne.jp/~hida/wakuwaku.html

OOPはノリノリで現実のに例えて覚えるとすんなり飲み込める。
「お前んちのソファーに隣んちの田中さんが座ってたら嫌だろ？」
実に能動的。どこが難しいのかさっぱりだ。

>>8
前者なら学生にそういうバカはいるだろうけどなw
後者もバカな学生にいそうだw

>>7
会社がバカなんだよ
会社名の頭文字か所在地でもいいから晒してみてよ。
そんで情報システム板に晒してさ

>>24
てかC++はグローバル変数やスタティック変数を心置きなく使うための言い訳言語と思えば理解早いよ。

>>26
んなわけない。グローバル変数もスタティック変数も原則禁止
(スタティック変数はごく一部ライブラリ内部で必要な所がある)
って縛りを入れないとC++ほど使いづらい言語はなくなる。

そうできてないのは実態がC厨の似非C++厨、
本当にC++使いこなしてれば原則禁止にしてるはず。

最低限必要なスタティック変数も、使う前に本当に必要なのかどうか、
社内の全プログラマ集めて会議してもいいくらいどうしても必要な場所は少ない。

>>27
クラスというプログラム単位にびっしりとprivateなるグローバル変数がはびこる言語じゃん。
externじゃないグローバル変数とどう違うん？

>>28
インスタンスに付随してるメンバ変数はインスタンスなしだと使えませんよ。
C++をもう少し勉強してからC++批判してね。林晴彦の本以外でね。

28の考え方のが正しい。なぜなら自分だから。

ついてけない

スマン、俺が勉強不足だったようだ
出直してくる

複数のプログラムによって作られるシステム、それを落とし込んでいけば自然とOOPとなる。
単一のプログラムではグローバル変数使いたい放題。
引数渡すなんて無駄なことしたくねーんだよ。レガシーな奴こそC++を使え。

馬鹿ｷﾀ━━━( ´∀`)･ω･) ﾟДﾟ)ﾟ∀ﾟ）･∀･)￣ー￣)´_ゝ`)−＿)ﾟ∋ﾟ)´Д｀)ﾟーﾟ)━━━!!!!

圧倒的に正しい意見の前に煽る事しかできなくなったか。

(ﾟωﾟ)
ﾟ_ゝﾟ)
ﾟーﾟ)
パーツ付け替えAAペースターでもつくろうかしら

>複数のプログラムによって作られるシステム、それを落とし込んでいけば自然とOOPとなる。

OOP風になる、ってならわかるけど、OOPにはならんだろ。

>単一のプログラムではグローバル変数使いたい放題。
>引数渡すなんて無駄なことしたくねーんだよ。レガシーな奴こそC++を使え。

ﾌﾟ

おおっと、まともな反論が未だにできませんｗ

>>36
その落とし込みをプログラム設計の場面だけで行うとすると、
落とし込めるまで一体何年かかるというのだ。
より上流からOO設計で最後の姿を想定しながら設計しないと
むりぽだよ。時間と金を無制限に出してくれるならいつやってもいいけど。

ぜんぜんそうじゃなくないのに子供の意見を否定し続ける親みたいなスレだな

>>8
＞●C言語厨はグローバル変数が大好き。C言語厨はグローバル変数に取り憑かれているために
＞　いつまでたってもオブジェクト指向を理解できない。

の実例が来たぞ
>>33

>>33は理解してるじゃん

２０年前、おれは小学生だった。
地方に住んでるおれは、東京のテレビ番組が見たくてしょうがなかった。
再放送なので情報も遅かった。
地方に居ながら東京のテレビ番組が見れる装置はないものだろうか。
そのとき、ビデオデッキのコマーシャルが流れた。

　「いつでも好きな番組が観れます」

オレは興奮した。これで東京のテレビ番組が観れる。
親にビデオデッキの購入をせがんだ。
そんなある日、VHSのビデオデッキをうちの親が買ってきた。
おれは、その「びでおでっき」に不満だった。
その「びでおでっき」クラスには
メソッド「地方に居ながら東京の番組をリアルタイムで観れる」
を実装していなかったのだ。
おれは親に抗議した。
この「びでおでっき」インツタンスは、
おれの「びでおでっき」クラスと実装が違う。

親はおれが何を言ってるのか理解できなかった。

急に口惜しくなった。

おれは発狂し親を攻撃した。

大人たちはおれのＯＯを受け入れなかったのだ。

結論
「ＯＯは子供の勘違い」

>>42
いい時代になったな

virtual machine言語なんて遊びの延長。

　　　　　　　　　　　 /　　　　　　　/　　ヽ　　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　 ...―/　　　　　　　　　　＿）　　＜ 　片瀬雪希とぽけっとチュッチュ♪
　　　　　　　　ノ:::へ＿　＿＿　　　　/　　　　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　　|/＼:::: :::: :／::: ::::　＼/_
　　　　　　　/-o-ヽ―ヽ::-o---::::（::::::::.ヽ
　　　　　　｜::￣/　　/:::::￣￣:　（:::::::::::::） 　─┼─
　　　　　　｜::::/　　:::: :::::::::::::　　　　ヽ/　　 　─┼─
　　　　　　 |　　＼｀　　　　＼　　　　 /　　　　 　│
　　　　　　 ＼　 ------　　　　　　/ 　　　　　　　|　| /
　　　　　　 　 ＼　　-　　　　　　 ／　　　　　　　　 　_/

コラ　前ｽﾚの1000取った奴
何のために1000を空けといたと思ってるんだ。

罰としてＯＯとは何か。答えろ。

若き日の迷い？

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

>>46
　　　,. -─ ''　"⌒'' ｰ- ､　　　　　　　　　　 __,,. -──- ､.
　　　　.／　,r' ´ ￣￣ `'' ‐-r--､　　　　　r=ﾆﾌ´　￣￣ ~｀` ‐､ ＼
　　 ／　　　　　 ,r--‐''‐ ､.._,,二ﾌ-､　 ,. -‐ﾞｰ-‐ ''､'ｰ--''-_､　　　　 ＼
　／　　　　 　 /　　　　 , '´　　　 ,.ｲ　ヽ__　　　　　}ノ´二 -‐ヽ._　　　　＼
　　　　　　　　{ 　 　 　 i　　　　　>{　　　 L　　　　,'ｰ 'ー ''´￣}
　　　　　　 　 ﾄ、　　 　 !.　　 　 〈/　　　　 }　　　/　　　　　 ,.ｲ
　　　　　　　　 ヽ､＿＿_ヽ、　 .／　ｶﾊﾟｯ　 ￣レ'　　　＿, ‐'
　　、 　 　 　 　 　 　 "　｀,二ヽ!　　　　　　　 r''二 ￣
　 　 ` ‐- ､..＿＿,. -‐─┴─'　　　　　　　　 ﾞ─‐'--''─- ､..＿＿_ ,.
　　　　　　　　　　　　　　　　　　　　‖‖
　　　　　　　　　　　　　　　　　　　　‖‖



　　　　　　　　　　　　　　　　　　　∧＿∧ 　
　　　　　　　　　　　　　　　　　　（・∀・∩）　知るかボケ！！
　　　　　　　　　　　　　　　　　　（つ　　丿
　　　　　　　　　　　　　　　　　　 （　ヽノ　　
　　　　　　　　　　　　　　　　　　 し（＿）

>>28
お前は変数名の衝突事件を知らないのか？
ｱﾌｫすぎる。
これだからC言語厨はオブジェクト指向が理解できないのかと

>>40
ﾜﾗﾀ

グロC厨w

グローバル変数を崇拝するガングロC言語厨w

>>42
それはお前のOOを受け入れなかったのではなく
お前の想像するインスタンス(実態)を受け入れなかっただけだろ。

お前の親は、「びでおでっき」というクラス、つまり「イデア」を
お前とは異なるものと解釈したわけだ。

お前の「ビデオデッキ」はビデオデッキクラスを継承してはいるが
東京の番組も見られる例えばケーブルテレビチューナを内蔵している
ビデオデッキクラスだ。そのビデオデッキクラスは
東京の番組を写すメソッドを搭載している。

だが、お前の親が想像していた(ビデオデッキクラスを継承してはいるが)
単なる録画メソッドと再生メソッドを実装するのみの
「録画再生専用ビデオデッキ」クラスにしかすぎなかったわけだ。

お前の親である大人は、OOをちゃんと受け入れている。
だが、お前のサブクラスのインスタンスを受け入れなかったのだ。

それはちがう
東京の知人に録画をお願いして
テープを郵送してもらってもいいじゃん
おいらが言いたかったのは

　「いつでも好きな番組が観れます」
　（ただしソースは自分で用意してね）

この「ソースは自分で用意する」
という制約条件をすっとばして
魅力的な宣伝文句に踊らされて
正しい使い方の目的をちゃんと勉強せず
自分の都合のいいように解釈した
そして実際やろうとしたら思ってたのと全然違ってた
これが子供の勘違い

ネットでよく見るＯＯの解説をよむと、
ＯＯというイメージの究極は
ブロックを積み上げる感覚でプログラミングができる
これを目指してるんだと思う
そんなふうになればいいなとは思うが
今の複雑に絡み合った社会情勢はどうにもならないし
モジュールとモジュールをつなぐには
テストとデバッグを繰り返す他に手はないと
オレは思っているし
なぜならプログラムの目的は
作ることじゃなくて正しくデータを通すことにあるからね。
この現実を受け入れなくなると

　「大人はＯＯを受け入れていない」

という理屈に論者なるんじゃないかな？

という理屈に論者はなるんじゃないかな？

だからＯＯは子供の勘違い

>>32
死ね。氏ねじゃない。死ね。

オレ４２で、フリーでやってるけど、仕事でJava普通に使ってる。

言語ってあるところをクリアしたら、言語が何だろうが別にどうでもいい。

いわゆるおっさんで、４０超えて、Javaとかについていけない香具師は、２０代の頃から、もともと他の言語でも、ついてこれなかった香具師多いよ。

その癖、知ったようなフリして、「オレはいつでもできるんだ」みたいに言うから、若い奴に笑われてもしょうがないと思うんだよね。

オレ、普通に７〜８種類は言語使えて、仕事できる。

Javaは、Cだけできても無理だと思う。個人的には。

要は前にどんな言語やったかじゃなくて、「これでメシ食えるか」だけのような気がする。

>>57
> Javaは、Cだけできても無理だと思う。個人的には。
同意。
C使いでも、「最終的にどんなマシンコードに落ちるか」を気にしながら
（つか、時にはアセンブラのソースを吐かせて確認しながら）書ける奴は
そんなにいない。で、そういう「書ける」奴が、自分のポカで変なことを
やっちゃわないような安全装置（チェック機構）が欲しくて
Java を使うような気がする。
「ヤバいのを承知で、処理系依存の速いコードを書く」必要があるときは、
native なコードを書きゃあいいわけで……
OOやりたいだけならC++でいいわけだし、安全性も含めたバランス感覚が、
Java 使いには求められる気がする。

Collectionフレームワークの違いを理解してない奴多いね。
何でもかんでもVectorとか、LinkedListの使いどころを知らないとか。
HashMapで文字列キーで取れるはずの値が取れないと騒ぐ奴とか。

ＯＯって何ですか？

Object Orientedの略。
OOA(Object Oriented Analysis;オブジェクト指向分析)、
OOD(Object Oriented Development;オブジェクト指向開発)、
OOP(Object Oriented Programing;オブジェクト指向プログラミング)、
OOPL(Object Oriented Programing Language;オブジェクト指向プログラミング言語)、
あたりのいずれか、あるいはこれらを総称したものをOOと呼ぶ？

OODは設計じゃないの？普通。

ＯＯの中身を教えてください

OO=おにぎりって覚えておけ
俺は、クライアントにOO思考ってなんだって
いうDQNいたからおにぎりのことですよって
答えてはーなるほどって納得したのかしらねぇけど
電話切ったぞ

オブジェクト指向プログラミングは非直感的で、不合理で、効率が悪い

>>58
>Java を使うような気がする。
PGの立場でどの言語を使うのか決められるわけ？
今、PGって派遣が多いし、プロジェクトに入ったりしたら言語決まってない？
自分の意志で言語決めてる奴は少ないはずだよ。

>>58
>>57が言ってるオッサンってまさにコイツのことなんだよ

>>66
> PGの立場でどの言語を使うのか決められるわけ？
> 今、PGって派遣が多いし、プロジェクトに入ったりしたら言語決まってない？
派遣の立場では決められない。
請負の立場でも、偽装請負だと決められない。
請負で、仕様書に言語の指定が入っておらず、外部仕様だけが
決められている場合、決められる。

言語の指定がなくても
スキルのない>>58には決められない

「Javaなしで地球は回らない」--サンがJavaOne Tokyo 2005開幕
http://japan.zdnet.com/zdnet/news/software/story/0,2000052520,20090464,00.htm


こんな挑発的なタイトルが付けられてますが
C言語厨のみなさんどう思いますか？

C言語厨：「なんでJavaだけイベントがあるんだ！COne(シィーワン)もやりやがれ！」
聴衆：「それじゃコーンじゃないか」

C++厨：「なんでJavaだけイベントがあるんだ！C++Oneもやりやがれ！」
聴衆：「Ｃ足すPlusPne? なんかニュース番組みたいだな」

Javaは人民元
C++は貴族だからやらない

javaって何？
VBA出来れば一生安泰なんでしょ？
学校の先生が言ってたお

その学校の先生は超ご立派だｗ>>73
尊敬してやれ

>>73
まぁ学校の先生として生きていくには一生安泰かもな（ｗ

「Javaなしで地球は回らない」--サン

ふーん。で、Java VMって何の言語で書かれているの？

朝鮮語

○○？

>>76
Javaだけで、とはゆってないけどな。
まあつっつきたくなる気持ちはわかる。

そろそろサンなしでもJavaは回りそうだけど。

>>78

マジレスか？

ＯＯを言語の一つだと勘違いしてるｵﾔﾁﾞがたまにいるんだよ。

考えてみたら、デザパタ５つくらいしか使ってない……

　○|￣|＿

デザパタのひとつ
SINGLETONパターンの例が以下にある。

ttp://www.hellohiro.com/jspdb.htm
サンプルソース　DBConnectionPool.java

このソースは便利でよく使わせてもらっている
ほんとに便利なのだが、ここで疑問がある

データベースコネクションをプーリングする時は
SINGLETONパターンは確かに有効だが、
それ以外の用途がオレには思いつかない

あるＧｏＦ本には全部で２３パターンあると書いてあるが、
それを全部理解したとしても、果たして有効にバリバリ
使うケースがそんなにあるのか？
デザパタを気にせず
誰かのソースをコピペすればいいのではないか？

>>82
後輩が「設計がダサイ」っていって馬鹿にすんだよヽ(｀Д´)ﾉ ｳﾜｧｧｧﾝ

ステートレスなロジッククラスとかは
シングルトンにしといた方が
リソース節約にはなりますな。

DIコンテナとか使うとデフォでそうなる。
SingletonってよりかFlyWeightになるのか。

>>83
だったらその後輩に設計させればいいじゃん。
それで良いものが上がってきたら採用すればいいし、
糞だったら文句つければいい。
口先だけのｱﾎか、実力があるから言えるのか、判断するいい機会だろ？
実力があるんだったら、そう言う香具師には頑張って貰った方が、
おまえさんも楽になるだろうし。

staticライプラリなクラスをあえてシングルトンにしてみるとか。

ありとあらゆるものをstaticにしてSingletonを装ってみるとか。

>>61
×Object Oriented Development
○Object Oriented Design
気付けよ。

ttp://www.hellohiro.com/jspdb.htm
サンプルソース　DBConnectionPool.java

この場合
SINGLETONパターンを使ったことによる欠点は何だ？

とくにデメリットはないんじゃね？

複数インスタンス作る必要がないものは、singletonにして、
そもそも複数インスタンス作れないようにする。
仕様を実装で明示しているってだけだ。

>>82
デザパタを意識することで、クラス名称にそれが反映され、
その結果クラス名が、より内部の機能の方向性や
実装の思想を示すようになる。
そういう利点もあると思うがどうよ。

コネクションプーリングってシングルトンなの？
アブストラクトファクトリとかじゃなくて？
デザパタむずい

Singletonパターン
　　あるクラスに対してインスタンスが１つしか存在しないことを保証し、それにアクセスするためのグローバルな方法を提供する。

AbstractFactoryパターン
　　互いに関連したり依存し合うオブジェクト群を、その具象クラスを明記せずに生成するためのインターフェースを提供する。


　　　　　　　　　　　　　　　　　　　「オブジェクト指向における再利用のためのデザインパターン」より抜粋

ぜんぜん違うだろ

だからそのプーリングされたコネクションインスタンスってのはシングルトンじゃないっしょ。
入り口がひとつしかなくて受け取れるものが複数で、その振る舞いが共通ならそれはAbstractFactoryでは？

コネクションプールクラス　DBConnectionPool.java　と、
それを利用してる画面 jspdb3_jsp.java がある

それをマッキントッシュで動かそうとしたら
なんとDBConnectionPool.javaと似たような
優れたマッキントッシュ用コネクションプールクラスがすでにあった。
でも似てるんだけどメソッド名が違う。

そんなときこそAbstractFactoryパターン 。
AbstractFactoryパターンの考え方で共通のインターフェースを作れば、
マッキントッシュの優れたソースも自分のソース（jspdb3_jsp.java）も変更しなくてすむ。
それがAbstractFactoryパターン


　　で、ここからが本題なんだけど、、
　　AbstractFactoryは思想が幻想的だと思う
　　他の環境動で動かすのに
　　コピペのソースをまったく変更しなくてすむなんて
　　業界社会ではぜったいありえないと思ってるんだよね
　　オレだったらjspdb3_jsp.javaをマッキントッシュで動くように
　　メソッドを呼ぶ処理をマック用に変えるけどね
　　AbstractFactoryパターンを使ったからって
　　jspdb3_jsp.javaを変えなくてすむ保障にはならないし
　　確かに処理を変えたらテストしないといけないけど
　　それはリスクとして当然でしょ
　　仕事でやってるんだから

　　これはオレ個人の位置づけであって
　　教育人や学校出の考え方は知らないよ

>>94
ラッパそのものはAdapterでは？
特定の何かであることを気にせずに使えるのがAbstractFactoryだしょ

そういやAbstractFactoryパターンを上手に活用している例は見たことないな。

>>94
その例の状況で、対応の為のリファクタリングを行うとしたら・・・・・・

１．DBConnectionPoolからインターフェイスを抽出する。
２．そのインターフェイスとマック用コネクションプールを繋ぐアダプタ
　　ークラスを書く。
３．jspdb3_jsp内のDBConnectionPool生成部分をAbstractFactoryで
　　置き換える。
多分、こういう手順になる。
ところで、コピペなんて出てこないと思うけど？

それはそれとして、これが例ではなく実務だとしたら、俺はDIコンテナ
を引っ張ってくると思うな。
実行時切替の為だけにAbstractFactory書くの面倒なんだもんｗ

おいおい喪前ら
たかがDBConnPool書くのになんでそんなにくどくなるんだｗ

大体他人の書いたConnPoolを使おうとするのがせこいなｗ
自分でもっとシンプルなクラス書けよｗ

http://www.insecure.org/nmap/index.html
強力なスキャン。

>>98-99
いや、待て、そこは単なる例じゃん？
その詳細に触れてどうしようってのよ？

ああごめん
>>94はAdapterパターンだ

>>95の言うとおり
特定の何かであることを気にせずにプログラミングをする
そんなふうになったら確かにいいと思う
それはつまりプログラムすることなくプログラマーとして食べていけるということだ
早くそういう時代が来るといいと思う
そのためにも、もっとをぢさんをいぢめて働かせないとね


で、AbstractFactoryパターンなんだけど
直訳すると「抽象的な製造」って意味で

ﾌｧｲﾅﾙﾌｧﾝﾀｼﾞｰII、III、と続編を製作する前提で�Tを作れ
って言ってるようなもので
やっぱりオレは受け入れられない

だからさ、例としてどんどんくどくするなって事だよ

結局、歳に関係なくついて来れてないと。

>>102
ん〜〜〜？
AbstractFactoryは生成に対するFacadeで、生成する側される側の
両方を実行時切替(抽象化)できるというのが肝。
Factoryでは生成する側が生成対象を知っていなければならない。
AbstractFactoryでは生成する側も切替が可能なんで生成のロジ
ックをコードから分離して抽象化できる。
これが、AbstractFactoryのAbstructたる所以。

ここにAbstractFactoryの例がある
ttp://www.hellohiro.com/pattern/abstractfactory.htm

サンプルソース　AbstractFactory.java　の中に

　　String s = "1"; // ← 環境によって値が変わる変数

っていうコードがあるんだけど、

この"1"の数値は、誰かが環境によって変えてくれるんでしょ？
それは誰がやるの？

やっぱ自分だよね

だったらAbstractFactoryなんてやめて
生成対象クラスからインスタンス生成したほうが
メモリ食わなくて速いし、クラスも減るから読みやすいよ

>>106
Javaでいい例がある。
String myosCharset = System.getProperty("file.encoding");

これで文字化けしなくなる。

>>106
例とはいえ、その実装はあまりにも酷い。

かなり省略してるけど、基本形は以下の様になるのが普通。
public static IFactory getFactory(String classname) throws Exception {
　return (IFactory)Class.forName(classname).newInstance();
}
ここで出てくるclassnameはシステムプロパティで設定してもいいし、独自
にコンフィグレーションを用意してもいい。
とにかく、それを使う側の実装には影響を与えない。

とは言え、>>94の例でその必然性を語るのは相当難しいな。
「生成される側」が単純にインスタンス化できず、「生成する側」が一定量
のコードを含むという前提がないと、複雑さばかりが目について利点が全
然見えてこない。

あとそれから、throws Exceptionは「このコードは例外処理を省略しています」
というマーカーだから、得意気につっこんだりしない様に

>>108

このclassnameの中身はシステムプロパティやコンフィグレーションから取ってくるんでしょ？
その設定は誰がやるの？

やっぱ自分だよね

だったらAbstractFactoryなんてやめて
直接クラス呼んだほうが
メモリ食わなくて速いよ

てかDBドライバそのものがAbstractFactoryしょ

>>88
>>62

>>112
きっと、Designが設計って意味って
知らなかったんだよ。

>>111
いや、DBドライバはSINGLETONパターンだって

ttp://www.hellohiro.com/jspdb.htm　（DBConnectionPool.java）
ttp://www.hellohiro.com/pattern/singleton.htm　（SINGLETONパターン）

まったくいっしょ

>>110
いや、だからさ、環境に応じて切り替えるという前提で話してるんじゃないの？
既存のソースに対する影響を最小限に留めながら、MAC用のパフォーマン
スが良いCPクラスは使いたいって前提は端から存在してなかったのか？
俺はてっきりパターンを利用して依存関係をどう変化させられるか？って話
をしてるんだと思ってたんだが、う〜ん、なんだかなぁ。

て言うかそもそも、>>94の話は例でも何でもなくて、詳細まで含んで文字通
りそのまんまって事で話してた？もしそうなら、>>98-99のレスで話は決着。

>>114
噛み合ってないぞ？>>111が言ってるのはDB＊ドライバ＊

ServletもAbstractFactoryだな。
TomcatだとCoyote〜ってのが実態だったはず

public static synchronized DBConnectionPool getInstance() {
if (instance == null) {
instance = new DBConnectionPool();
}
return instance;
}
JAVAでこの書き方をする人がいまだにいる事が信じられない。

>>118
いい感じのソースじゃん。あんたのいう正解は？

private static DBConnectionPool instance = new DBConnectionPool();
public static synchronized DBConnectionPool getInstance() {
return instance;
}

>>120
JavaDocが面倒。却下。

>>120
synchronized一発でスレッドセーフにしたつもり？

大体にしてSingletonの問題点は、
C++を例に取ってた時代から指摘されてること。
Javaだからと言ってそれが解消したわけではない。

>>122
一発でスレッドセーフにならないなら
何発でもスレッドセーフにはならないと思います。

>>116
ああごめん悪かった
>>93の意味がやっとわかった

それね、おれずっと不思議なんだよ。
独自ＳＱＬ構文使わなければ
ＳＱＬサーバーでもＯｒａｃｌｅでもＭｙｓｑｌでも
全部同じソースが書けるのよ
うん

で
このドライバ作った人たちって会社ちがうんだよね。
よく意識合わせできるよなぁ

そのへんたしかにオレついていけない

>>124
なんで synchronized じゃないといけないの？
マルチスレッドよくわかりません・・・

>>93に質問

コネクションクラスのインターフェースをそろえるには
競合するライバル他企業と連携して
当面、採算は無視して
メソッドの処理の『振る舞い』を共通にしないと実現できないんだけど

それはそれなりに十分なメリットを見込んでの行動であって
GoF本に書いてあったからやったわけじゃないと思う

AbstractFactoryの例としてはすばらしいかもしれないが
何でもかんでも強制的にAbstractFactoryにするのは現実的ではない

AbstractFactoryを採用する以前に
他社に負けない優れた自社ＤＢエンジンを持っていなければ意味がない
それを持っていないオレにはAbstractFactoryを採用する意味がない

と思うがどうよ

>>124
甘い甘い。ダブルブロッキングしらないの？

ダブルブッキングなら得意

>>128
Javaの言語仕様を知らないのか？それはパターン以前のレベルだぞ。
private static DBConnectionPool instance = new DBConnectionPool();
この構文はスレッドセーフである事が言語仕様上保証されてる。
詳しく知りたいならJava言語仕様 12.4.2 Detailed Initialization Procedure
を読め。

・Java的には利点なし難点ありでぶっちゃけ有り得ない。
public static synchronized DBConnectionPool getInstance() {
　if (instance == null) {
　　instance = new DBConnectionPool();
　}
　return instance;
}

・Java的正解
private static DBConnectionPool instance = new DBConnectionPool();
public static DBConnectionPool getInstance() {
　return instance;
}

>>120
synchronizedは要らない。
イディオムを暗記してるだけで、初期化手続きの詳細が理解できてな
い証拠。
最少のリソースで最大の効果を期待するなら、暗記より理解が肝心。

>>128
Double-Checked Lockingは安全性に対するパターンではなく、パフ
ォーマンスに対するパターン。

>>130
何言ってんだか。
参照型を排他制御しない馬鹿が未だに居るのか。
言語仕様を理解するのは良いんだけど、
JVMの仕様は読んでみた？それからJavaコンパイラが
それをどの程度実装できているのか考慮してる？Sun,IBM・・・etc。

参照型と排他制御は関係ないのよ

参照型ではなく、複数から参照される可能性のある変数ではないか。
言葉は正しく使って頂きたい、片言の日本語しかわからない中国人も雇わないで頂きたい。

>>132
Javaのクラスは初期化が開始されるとその終了まで同期化される。
これはJavaVMの定められた動作で実装に依存しない。

Java言語仕様 12.4.2 Detailed Initialization Procedureを読めと詳
細な資料へのポインタを示してるんだから、反論するならそれを読
んでからにしてくれ。

>>132
参照型を排他制御ってなんでしょうか？どうしたらいいのでしょうか？
今まで synchronized を使ったことないけど大丈夫なのでしょうか？

>>131の言うように
「Java的正解」の方のソースかいときゃもんだいないんとちゃうの？

>>133
スタックはスレッド毎にあるんだから、値型は
複数から参照されようが更新されようが排他しなくていいのよ

>>137が何を言いたいのか不明
参照変数は確かにスタックに展開されるが、参照の指し示すオブジェクトは
どっかで生きているヒープだぞ

あふぉばっかｗｗｗｗ

もうちょっとうまく煽ってくれ

んとにJava厨は馬鹿ばかりだなw

>>138
だ　か　ら　ヒープにあるんだから排他は常に必要ってこと。
return instance;だけですべてが解決できるはずない。

ヒープとかスタックとか参照とか理解できてないだろ〜

勘違いしている人多数

>>142
結城のデザパタ入門[マルチスレッド編]を読め。

AbstractFactoryの件といい、このスレってレベル低すぎ。

>>145
模範例題も出せず本を斡旋するだけの低脳より低いレベルってあるの？

>>145
誰かに読んでほしいんだね

>>145
つ作者乙

ここで>>145が「結城」である疑惑が浮上したわけだ。

これだけは言える。

絶対ありえねぇーーーーーー

このスレにいる馬鹿にスレッドプログラムは不可能
間違いない！

で、どうしたらいいの？

なんか理屈はあるみたいだけど、そんなん知らんでも
>>131のJava的正解で問題ない。
ググってみたら「これで問題ない」という話が一杯みつ
かったから、きっとそうなんだろう。

言語仕様とかやっぱり覚えないと駄目なの？
みんなは普通にそういうのにも目を通してるの？
もしかして俺だけレベル低い？＿|￣|○|||

単に末端PGで一生を終えるつもりなら、
別に言語仕様なんて知らなくてもいいんじゃないかな。

誰かに教えなきゃいけなくなった時に、
適当なことを教えて恥をかきたくなければ、
少しずつでも知識を増やす方がいいと思うんだけど？

世の中StringBufferを知らなくても
JavaPGで食っていけるみたいです。
ガベコレ万歳。

言語仕様とStringBufferは関係ねーじゃん

>>155
今はStringBuilder が推奨

馬鹿ばっか >>155 は正論を言っている
ヒープを穴だらけにするStringを使いまくる馬鹿厨
まるでどっかのスレの1みたいだなｗ
つうかここの>>1も有名な馬鹿厨だけどｗ
おっと、メモリ増やせか？
馬鹿だねー

まちげえた >>155 >>157が正論

OOかなんか知らんけど
プリプロセッサでコンパイル制御できないから
制限つき試用版は作成できないJavaって本当にかわいそうだと
思ったよ。だからオープンなんだろうなあ。。

>>151
Java的正解は不正解。
いま、ちょっと見たところだから、なにを議論したいのかよくわからんけど、
これだと、ヒープ上に唯一あるインスタンスを、複数のスレッドが競合して参照する危険があるね。
誰かが言ってるように、複数あるスレッドからくるこのインスタンスへの参照を、排他的に制御しないと、
スレッドセーフとはいえないかも。
（でも、結局みんなこんな感じのコードで客先に納入しちゃってるんだよね。）

↑
ごめん>>153だった。
スマソ

java厨が墓穴掘ってるスレはここですね

>>156
経験年数そんなに短くない人が
ループの中で += で文字列連結しまくる。
何度か現場で見かけました。
それがどういう事になるのかは、言語仕様でしょう？

って反論しようとしたらフォローされててよかった。

>>161
見えてない奴だな。

public class Singleton {
　//*1
　private static instance = new Singleton();
　private Singleton() { }
　public Singleton getInstance() { return this.instance; }
　//*2
　private Foo foo = new Foo();
　public Foo getFoo() { return this.foo; }
　//*3
　private String hoge;
　public getHoge() { return this.hoge; }
　public setHoge(String hoge) { this.hoge = hoge; }
}

*1はSingletonのイディオム。勿論、*2も問題なく動く。
*3は同期化が必要だから、このままで問題がある。
そういう話だ。て言うか、これ初歩の初歩だよ。
マジ、大丈夫かこのスレ？レベル低いにもほどがあるぞ。

>>165

>//*3
>　private String hoge;
>　public getHoge() { return this.hoge; }
>　public setHoge(String hoge) { this.hoge = hoge; }
> *3は同期化が必要だから、このままで問題がある。

何か足りなくないか？
同期化以前の問題。
このスレ、Java厨ヴぁかばかり。

言語仕様までさかのぼらなくても
>>131の言うことが正しいと思っている　俺は

161
俺の考えでは、「書き換えられることが無い値」を返す場合、
排他制御しなくてもいいと思っているんだけど　違うの？

>>166はたぶんprivate String hoge; が初期化されていないとか思っているのかなぁ？何が足りないのか意味わからん

>>168
public String getHoge()のStringが抜けてると言いたいんだろう。
もう揚げ足すぎてどうでもいい。

>>167
private static DBConnectionPool instance = new DBConnectionPool();
>>131はこの構文がスレッドセーフだという点が肝。
C++でスレッドセーフを得る場合、この様な書き方はできない。

http://www.y-adagio.com/public/standards/tr_javalang/12.doc.htm
ここの日本語訳が参考になった。
JVMは初期化や生成時にプログラマがマルチスレッド特有の問題で
苦労しなくて済むよう、いくらかの計らいを提供しなければならないと
されてるみたい。

これ読む限り、Java言語仕様ってJVMとかを書く人が読むものっぽ
いんだけど、やっぱりただのプログラマも読まないと駄目？

>>171
知らないよりは知っている方が良い。
そんなこと自明の事だろう？

てか、おまえアホだろ。

172はいかにも知ってますと言わんばかりだが
どうみても何も知らないね、こいつは

>>173
同意。「知らないより知っているほうが良い」とか「出来ないより出来た方が良い」
なって言う奴はロクな奴じゃない。「反論出来ない意見」そのものが悪いのだ。
業務遂行に必須な知識は知らなければならないのは当然だが、
周辺的知識全てを習得できる人間なんかいない

>周辺的知識全てを習得できる人間なんかいない
そうやって勉強しないことへの言い訳にしているんですね？

全知全能でなければSE/PGは務まらん！
生きて神となれ！それができぬのなら死んで神となれ！

業務遂行のために必要なことで、わからないことを放置して責任転嫁したりする奴は
マジで死んでほしい。死ぬか会社辞めて俺の前から去ってほしい。

あと、わからないことを当たり前のように思ってる奴も死ね。

>>161
なつかしいね

ユーライアヒープ

>>171
読まないとダメとは思わん。

ただ、読んでみた感想からいうと、
興味があるならそれなりにおもしろいし、
まったく無駄な知識というわけではないので、暇なら読んでみるとよい。

>>161
「競合して参照する危険」の意味がわからん。
どういうとき駄目だと思うの？

ダブルチェックロッキングの問題：
http://www-06.ibm.com/jp/developerworks/java/020726/j_j-dcl.html
> double-checked lockingは (いかなる形式のものであっても)、
> どのJVM実装でも動作するとは保証できないため、使用すべきではありません。JSR-133では、メモリー・モデルに関する問題に対処していますが、double-checked lockingはこの新規メモリー・モデルではサポートされません。
> したがって、ユーザーがとりうる選択肢としては、次の2つがあります。
>
> * リスト2に示したような、getInstance() メソッドの同期化を受け入れる。
> * 同期化を行わず、static フィールドを使用する。


C#にも似たような問題があるにもかかわらずMSDNに推奨例として書かれている、
とかなんとかいう記事を読んだような…

>>181そもそも態々答える必要ないぞ
ここはム板の初心者スレよりレベルが低いというか
真面目にソースかけるやつが恐らく1,2名いるかどうか
その程度だぞ。マジレスするだけ恥かしいと思ったほうがいいよ

>>182
カス

えーと。
マルチスレッドプログラミングの難しさは各種言語固有の問題ではない。
つうことでOK？

えーと。
マルチスレッドプログラミングはJava厨には不可能
つうことでOK？

>>82
> デザパタのひとつ
> SINGLETONパターンの例が以下にある。
>
> ttp://www.hellohiro.com/jspdb.htm
> サンプルソース　DBConnectionPool.java
>
> このソースは便利でよく使わせてもらっている
> ほんとに便利なのだが、ここで疑問がある
>
> データベースコネクションをプーリングする時は
> SINGLETONパターンは確かに有効だが、
> それ以外の用途がオレには思いつかない

Hibernate使え馬鹿

>>94
> コネクションプールクラス　DBConnectionPool.java　と、
> それを利用してる画面 jspdb3_jsp.java がある
>
> それをマッキントッシュで動かそうとしたら
> なんとDBConnectionPool.javaと似たような
> 優れたマッキントッシュ用コネクションプールクラスがすでにあった。
> でも似てるんだけどメソッド名が違う。
>
> そんなときこそAbstractFactoryパターン 。
> AbstractFactoryパターンの考え方で共通のインターフェースを作れば、
> マッキントッシュの優れたソースも自分のソース（jspdb3_jsp.java）も変更しなくてすむ。
> それがAbstractFactoryパターン
> 　　で、ここからが本題なんだけど、、
> 　　AbstractFactoryは思想が幻想的だと思う

そりゃ、部品を追加するたびにすべての工場クラスを
修正しないと言う欠点があるパターンだからな。

年寄りがオブジェクト指向を理解できない理由は
こういうのがあるからだと思う。

【SQL】joSQL【java】
http://pc8.2ch.net/test/read.cgi/tech/1132842713/

　 ζ
　●
(^⌒＼＿＿＿＿
＼＼　　＿＿＿.＼
　`ーー´　　＼＼　＼
　　　　 　　　　＼＼　＼
　　　　　　　　　　(（　　 |　　　PG/SEは電脳ドカタ　おまいらの未来はホームレス
　　　　　　　　　　|　　∩
　　　　　　　　　　|　　|　|
　　　　　　　　　　|　　|　|
　　　　　　　　　 /　 /　| 　　　　　　　　　(´´
　　　　　　 ∧＿∧/　 /　　　　　　　(´⌒(´
　　　　　　( ´Д｀　)　 ノ≡≡≡(´⌒;;;≡≡≡
　　　　　　　　￣￣￣(´⌒(´⌒;;
　　　　　　　　ｽﾞｽﾞｽﾞｽﾞｽﾞ

>>178
ユライアヒープの名前が、ここで出るとは！！
「対自核」とかじゃなかったっけ？

お前のつらでも見とれ

>>161が待ちかがったことを言っているのは理解したけれど、
それとその「UriahHeep」との関連は？

>>189
そこでおれはアジャイル開発を学ぶのだ

「複数のスレッドが参照」はだめなのか？
「複数のスレッドが書き込み」はダメだと思うけど

ついていけないんじゃない。

つ　い　て　い　く　気　が　な　い

んだよ。

この業界では怠惰と保守性は悪なんだがな。

>>195
誤爆？
「保守性が悪」って日本語おかしいぞ。

「複数のスレッドが参照」はだめなのか？
「複数のスレッドが書き込み」はダメだと思うけど

>>197
「複数(あるいは単数)のスレッドが書き込み」ながら
「複数(あるいは単数)のスレッドが参照」
は問題あり。

うん、だから
「複数のスレッドが参照」のみの場合は問題ないよね？

ごめん。
そこまで詳しいことは俺にもわからん。

ReadWrite Lock ﾊﾟｰﾀﾝ？

馬鹿どもにはスレッドの扱いは無理よ

ぱーばっか

>>199
参照したクラスが不変クラスでなく、自身のフィールドを書き換える
publicのsetterを持っている場合はダメじゃないの？

>>204
それ参照じゃない。

「Java言語で学ぶデザインパターン入門
マルチスレッド編」

を嫁

おもろいぞ。
java.util.concurrentには対応していないのが残念だが。

Javaって重く寝スレが終わったので
このスレを挙げ

Eclipseの開発に関与しているIBMや日立、富士通のような成功事例を説明してみてはどうだろう。
そこの会社がプログラマというものをどういう人間だと思っているのか
気になるところだが。プログラマを使い捨て程度にしか思っていない

全部反PCの汎用機WS売ってた会社だよね。
プログラマゴミと同じに扱ってるらしいよね。ソフトウエア工場らしいよね。

何が言いたいんだろJava厨は？



その通りらしいけど？

誰かオブジェクト脳の作り方読んだ人いる?

>>208
起承転結を学べ。話はそれからだ。

汎用機やWSが　ソフトウエアメーカーのMSのおかげでPC普及し売れなくなった。
PCあふれかえって実験的なソフトであるLinuxコミュニティが成立した。
MSじゃないからってんで作りかかりのソフトや売れないソフトを流した。
汎用機やWSでLinuxが商売になるか、自社OSへ技術取り込み出来てきてウマー。


オープンだから結局MSとりこんでもっとウマー。





煽られて踊ったおぷそ厨存在自体がマズー（特に客が大迷惑）
これでいいか？ｗ

>>209
あれはキショい

>>208
C言語厨、頭がトチ狂ったか？
何が言いたいんだろうね？それはお前に対していえることだ。

日本語を勉強してから出直してこい

>>211
> 汎用機やWSが　ソフトウエアメーカーのMSのおかげでPC普及し売れなくなった。
> PCあふれかえって実験的なソフトであるLinuxコミュニティが成立した。
> MSじゃないからってんで作りかかりのソフトや売れないソフトを流した。
作りかかり、売れないソフトってどんなもんよ。
オープンソースよりもフリーソフトにそういうのがわんさかとあるんだけど。

> オープンだから結局MSとりこんでもっとウマー。
あまり取り込めてないような。

>オブジェクト脳の作り方

このタイトルでひくものを感じたので読んでないんだけど
「ゲーム脳」と同じ香りがするんでね

>>215
（ ・∀・）人（・∀・ ）ﾅｶｰﾏ

Java厨になっちまいますよ。

オプソとJavaはPCに叩きつぶされた汎用機・ワークステーション屋の最後の砦
彼等はもともとソフトウェアで商売していなかった。ハードと保守とコンサル、ピンハネで食ってた。
コボルのおっさんが近くにいたら聞いてみるといい。
PCの世界でPGがドカタ化したのは最近だが、汎用機の世界では昔からだ。
そもそもPCが生まれたのは、自分専用のコンピュータが欲しかったPGの反抗・革命で、PCの世界ではPGは神だった。

>>1
ＯＯだかなんだかしらんが、机上の空論ばかりのたまっていないで、
まず仕事しろ。
こういう奴に限って、仕事が遅い。

日本にはなぜか専門学校卒のPGがいるけど、あれも汎用機時代の名残だよな。
汎用機メーカーの無い国は、PGと言えば大卒だもの。

昔はリアルでﾄﾞｶﾀだったんだね。

ＣＯＢＯＬの後継言語

つかオブジェクト指向と言うから駄目なんだよ
関数++とか言うと分かりやすいだろ？

>>222
> 関数++とか言うと分かりやすいだろ？
そりゃまあ C++ の場合は「オブジェクト＝関数へのポインタを抱えた
構造体」と割切っちゃえばいいんだろうが、それを言いだすと
「だったら C でええんちゃう？」と思うぞ。(-_-!)
　Java を始めた最初の頃は「static じゃないから静的なコンテクスト
からは呼べない」とか「静的なコンテクストだから this は使えない」
とかいったエラーが出てもちんぷんかんぷんだったが、リソース管理とか
マルチタスクとか参照スコープとかのからくりが見えてきたら、
OOのありがたみが理解できた気がする。

>>222
ぜんぜんわかりにくいし、アホが誤解するだけやで

OOは悪くないんだけどさぁ。
パフォーマンスが上がんないんだよ。
保守性は良い。
でもさぁ、客にとってはそんなのどうでもいいことなんだよ。
某大手会社のフレームワークを採用した。
ダメなんだよ。
全然ダメなんだよ。
遅くて使い物にならんのだよ。
でもね、保守性は良いんだよ。
メリットはそれだけなんだ。

OOはすばらしいんだけど
Java製のプロダクトは全部だめなんだよね

>>225
＞客にとってはそんなのどうでもいいことなんだよ。
お粗末なシステムを開発してるみたいだね。
システムの一生を考えた場合、開発費と保守費用、
どちらが高くつくと思ってる？
実際、保守性を高めるというのは保守費用を抑えることに
繋がるから、長く見ると意味で客にとっても自社にとってもメリットがある。
結果的に費用を抑えられたら、また仕事を頂ける。

この業界の奴って単純なことを分かってないんだよな。
ライブラリ関数の引数覚える暇があったら、そういう社会一般常識的な
ことに時間費やせよ。
だから、いつまで経っても「36歳定年説が恐い」とか言ってんだよ。
学生の頃、義務教育でも何教科同時にやってたと思ってる？
一日のすべての時間を、同じことに費やすな。いろいろヤレ。
そうすると道は開けてくる。

継続的にバージョンアップがあったり、機能追加があるならOOはいけてると思う。
それ以外は時間の無駄。
業務系にはいいかもしれん。

>>228
開発中の仕様変更に対応できる。というメリットもある。
開発中盤で、影響する外部システムが遅れているとき
OOであれば、抽象的に開発を進めることが可能。
まともにやれば納期間近で火を噴くことになるであろう
開発も、うまくOOを適用したら開発終盤での効率が良い。

デメリットな点は、OO初心者が開発中盤で成果に不安を感じること。
進捗してないような気がすること。

気のせいかも？が現実になったりすること。

非OOな手法で開発すると、影響するところの遅れに追随するのは難しい。
共倒れにならないためにもOOをオススメしたい。

パフォーマンスの改善に限定していえばOOだと終盤になればなるほど絶望的。

オブジェクト指向以前のコードが最近多いようなきがする。
同じような処理はルーチンにするという、それこそアセンブラの時代から
あることすら実践出来ずにOOもへったくれもねー。

納期優先とかになると簡単に破綻したり、設計担当者や中核となる
開発メンバーを変更しにくいという、この業界では結構面倒な問題
もある。一度、崩壊した設計の再リファクタリングは作り直しに等
しい。

OOは魅力的だけど難しい。てか効果をあげることができるのはごく限られた領域のみ。
だからOO関連本、セミナーはいつまでも売れつづける。ある意味では夢の技術。

OOを導入する上で重要なのは妥協点。

>236
フン。はなっから負けを認めているようなもの。

OOの、仕様変更への強さってさ、当初のモデリングの範囲内だよね。
クラスの境界をぶち抜くような仕様変更の場合、改修が大変。

>>238
分かってるフリのＳＥが設計して、後から平気で大きな仕様変更する。
練習じゃねーんだぞ。

C言語厨ウザイ。
Javaが5.0にバージョンアップしたというのに
未だに1.4押しつけてきやがる。
Cと違ってJavaには上位互換性があることが
わからずC言語厨は1.4を押しつけて古い環境で
開発しようとする。チームとしては非常に迷惑。
libディレクトリに放り込んだJakartaのライブラリも古くさいものばかり担いでウザ。
Mavenでアップデートしやがれ糞ジジイ。
Subversionの使い方も知らないし超ウザってー
もうC言語厨は死んでください

>>240
そんなこと言うと、Java厨も含めてほとんどのＩＴ関係者が死ぬぞ。

>>233
今はコピペの時代だ。
漏れに「Javaをわかって使っているんですか？」と抜かした
Java厨がexcelマクロで大量にJavaコードを生産してます。
そんなJava厨の評価は高く、「Javaをわかって使っているんですか？」
と言われた漏れは今月末で切られます。orz....

林晴彦てダメなん？

だって、ループしたりメソッドを呼んだりしたらその分遅くなるでしょう？
マクロ展開しようにもJavaにはマクロが無い。

そこで　人　間　プ　リ　プ　ロ　セ　ッ　サですよ。

>>237
若いな。
その若さは美しいが。ｶﾞﾝｶﾞﾚ。

>>236
色んな意味で、結局そこに行き着くのが悲しくもあるなぁ。
モデリングと違って、実装では、抽象化すればいいってもんでもないし。
効くところにちょっとだけ味付けで入れるのが、一番効果的かも。
味付けが濃すぎては、一部の人間しか理解できなくなる。

OOは実際の業務で真面目にやれることって希だよな。
どんなに思想を持って開発しても自分が最後まで面倒見られる訳じゃないし、
結局最後は誰とも知れぬ香具師にぐちゃぐちゃにされちゃうのかなぁとか、
せめてここだけは思想を理解してメンテして欲しいと書いたコメントとか、
でもリリース版では所詮はコメントだから消えているかもしれないという予測とか、
時間が無くて抽象化レベルが甘いままで開発して、力業でなんとかしちゃった部分とか、
etc...

>>240
一行目とそれ以降が見事に関係ないんだが。

>>246
いや、漏れも C++ 関係で似たような思いをしているので、
そこはかとなく雰囲気は分るような気がする。
「古いコンパイラで通らなければダメ」みたいな圧力は、
確かにある。

>>227
大変立派な意見だ。
オレの代わりに客に説明してくれ。ｗ

>>234
そら非OOもいっしょでしょ。
プログラムの基盤になってるデータ構造が腐ってると
目も当てられん…

>>244
マクロ展開すると速くなるの？
詳しく。

>>247
何故そうするかは、周りのみんなは分かってるはずだよ。

>>240
動作している環境をいじるものほど怖いものはないし、いいだろうで
えいやで新しくすると動かなくなったりするんだよなー
そんなに新しい環境でやりたきゃも前がテストサーバ立てて
現在のプロジェクトの動作検証でもしやがれ

>>252
別物を入れるならいざ知らず。
JDKのメジャーバージョンupにしたって、
1.1→1.5とかじゃないし。
1.4からなら、そこまで致命的に動かなくなるとも思えないが。

>>253
甘いな。業務でがんがん稼動しているプロジェクトを一揆にやってみるといいぜ。
後々楽しめるぞ。

オブジェクト指向の本読んでもOOが何かよーわからん。

要するに外部変数使わない関数ってことか？？

オブジェクトとは
いくつかの変数と、いくつかの関数を束に（カプセル化）した物。
要するにプログラムそのもの。
プログラムの中でソース（クラス）をコンパイル（インスタンス化）して利用するのだ。
ＯＯとは
一つのプログラムを万能に作り、全てを処理するより
専門分野に特化した単機能の、しかも独立して動くプログラム（オブジェクト）を複数作り
それらを連動させて一つの処理を行う方法。

この方法だと堅牢なシステムを作りやすい。
何よりも楽だし。

>>256
基本から間違ってる。OOの入門書から読み直せ。

とある会社の業務PKG開発プロジェクトで
ＯＯを理解できない馬鹿ＳＥ＆構造化プログラムレベルしか出来ないＰＧがいる我が社と
日々バリバリＯＯでプロジェクトこなしてると豪語してる某社とでそのプロジェクトを共同開発したんだが
いざ客の評価はと言うと的確に要件分析をしていた我が社の年寄りＳＥの方が評価が高かった。
しかもその豪語してる会社の方は何を考えてるのか一部プログラムをＤＬＬ化しやがったので
後々メンテナンスがかなり困難だと思われ。

その会社がいくらＯＯを理解できる、技術的にウチの会社より上だからって言っても
結局、ＯＯの指向や開発技術にこだわりすぎて前が見れなくなってしまっていたんだから
その時点でアウトだってことだな。

>>258
別に間違って無いじゃん。

間違ってるのは、 >>256

C丼厨ですがこのスレに参加していいですか？

なんでＯＯと客評価を結びつけるんだ？
OOと客評価は別だろ
客は開発手法なんて考えないし、評価もしない
評価するのは出来上がった物だけ

難癖付けるにも無理がありすぎる

だからＯＯって何だよ。
3行以内で述べよ(15点)

年寄りはgoogle先生に聞いてみたりwikiって調べるという概念が無いのかね？

┐(´ｰ｀)┌ ﾔﾚﾔﾚ

2005年4月、ついに最新の64bit CPUをサポートするWindows XP Professional x64 Editionが発売されました。
この最新のWindowsの持つ能力を活かしたソフトウェアを募集します。ソフトウェアのジャンルは問いません。
ぜひ、この機会にソフトウェア作りに挑戦してみてください。
http://win64xp.impress.co.jp/

Windows XP Professional x64 Edition ソフトウェアコンテスト
http://win64xp.impress.co.jp/programming/index.htm

>>256
その理解は、CやってたやつがC++始めて
思った感想レベル。

いくらＯＯの開発技術に長けていても、それが商品価値としてつながるかどうかは別だろ
なんせ客がそんなもの何の徳になっているか理解できないんだし、むしろ無駄じゃないかと疑問にもたれるんじゃないか？
ＯＯの技法を駆使したところでそのシステム全体が要件を満たしていない糞システムならば、所詮それは技術者の自己満足でしかない。
つまり、客の視点から見れば無駄の無いクラス図より熟練したＳＥの要件分析の方がずっと商品価値があるってことだ。
それが現実なんだよ君達。

>>268
そりゃお前がマトモな顧客しか相手にした事が無いから言えるんだ。
よく分かってない顧客はJavaです、オブジェクト指向です、と言っただけで
スゲー、俺の会社もいよいよオブジェクト指向？なんたってJavaだもんな
とかﾜｸﾃｶしちゃうもんなんだよ。

そんなあほ客にはapacheのソースでも見せてやれ

２８６の様な考えだと、どうでも動けばいいということになり、
とんでもない代物を作るんだよな。どうしてこう両極端なのだろうか。

結局、客の客、つまり自分に跳ね返るんだが。

いや、なんちゃってOO信者を集めて、結局低品質なコードを納めるくらいなら、
構造化でもきちんと作りこまれたものの方がましだろ。
10年前はきちんと機能していたわけだし、

なんちゃってオブジェクト指向より、きちんとした構造化の方がましなのは当然だし。

なんちゃってＯＯ　ﾜﾗ
Javaで業務コードをフレームワークの隙間に埋める作業だけなのにね
ﾄﾞｶﾀをいい気分にさせるシステムなんじゃねーのJavaのＯＯ

>>269 ついでにLinuxでオープンソースでGPLだからコミュニティですごいんですよとか抜かして
ソース全部公開すれば？ｗ

Ｃ言語で構造化してプログラムを作るよりも、
Ｊａｖａで作るともっと面白いものができるんだよ。
それは、構造化のひとつ上の概念だ。
Ｃ＋＋ではともかくＣ言語では言語的に無理だ。

このひとつ上の概念がオブジェクト指向というものだと漏れは理解してる。

>>275
それは「比較的楽に」って事だろ？

シングルトン使いまくり最強伝説

Singletonの何が悪いか！

>>275は低脳だと言う事はわかった

シングルトンならＣ言語でも出来るしな。
つか、デザパタが現れる前から良く出来たソースはそうなってる。

グローバルクラスシングルトン至高伝説

スレッドが走りまくるミドルウエアでは
グローバルデータがないと話にならない
そのときはオブジェクト指向なんてしょせん業務アプリのドカタを
コントロールする仕掛けだということが分かる

グローバルデータをモジュール内に隠蔽してグローバル関数で参照するように
しておいたほうがデバッグ時には便利だなぁ。コールスタックで参照を追えるし。
最後にはインライン展開しちゃうけど。

あらゆるクラスが参照する唯一のクラスを作ればいいのでは。
たとえばコード変換をする場合など、コードをあらわすクラスを作ればいい。
そのコードの元ねたがＤＢにあろうが、月の上にあろうが、そのクラスに隠蔽される。

どこかのJava厨が毎回ＤＢにコード変換値を読みに行くコードを書いてＤＢのクエリー数を
無限に上げてたが、このような場合上記のコードをあらわすクラスが一度だけ読み込んで
保持するようにすればいい。グローバルデータと言っても、それらは何か意味を持つもので
あるので、オブジェクトとして抽出すべきだろう。

そのインスタンスはグローバルなの？ださっ

↑マルチスレッドをできない馬鹿

爺はＣ言語脳だからグローバル大好き

フレームワークの隙間のダサいビジネスコード専門

その名を業務アプリドカタ

>>269
そんな顧客いるかな？
普通のユーザは結果が全て
中身は拘らない

>>282
逆では？？
スレッド間の依存を少なくしないと
直ぐにスパゲッティになる

マルチスレッドとグローバル変数って全然関係ないじゃん
ああ、もしかしてメソッドの内部でグローバル変数を作れる言語ってあるんですか？

>>292
＞ああ、もしかしてメソッドの内部でグローバル変数を作れる言語ってあるんですか？

それに限っての話なら
PHP

>>291
なんだ、君のスレッドの仕事は

Hello Java厨

とか表示するだけのスレッドか
それなら君の言うとおりだ

お前らの言ってる事ぜんぜん和漢ねーよ

久しぶりにグローバル君を見たな
つーか未だに生息していたとは驚きだぜ

すべての言語に生きてます

グローバル・シングルトン爺は氏んで欲しい

↓使いまくりな奴↑

>>292
つ static

>>294
今開発してるAPLは、スレッドが数十個走ってる

>>282
スレッド間で共有するオブジェクトの
インスタンスを生成する、くらいの事も考え付かない
君の脳みそに呆れた。

スレッドの扱い自体はJavaの方が楽だよな
簡単な排他処理ならsynchronizedで済んじゃうし
この辺のお手軽さはCには無いね

あたりまえだろなんのためにjavaやねんよ

>>303
ミューテックスをラッピングするクラスを作ればそれなりに

>>305
キーワード一発で排他制御出来てしまうsynchronizedと比べたら
やっぱ見劣りするな

C++もそろそろプロセスやスレッド関係を言語側でサポートする時期に
来てるんじゃないかなぁ

>>306
そんなことしたら、プロセスやスレッドの概念のない環境で
使えなくなっちゃうじゃん。
特に、OS自体の記述が不可能になる。

Javaは環境があらかじめ完備されていることを前提とした言語だから
それはそれで良いんだが、C++の場合はあくまでもCの後継だから
Cで出来ることは全部出来るのが必須の要件だ。

スレッドの排他制御?
クリティカルセクションですぐできるだろう?
Java厨は相変わらず馬鹿ばかりだな

javaはクリティカルセクションなんて関係なんだけどね（笑）

いやC++の話だが
>>390 枝番ミスったなw

おまえはアンカーミスったな

wwww
いかにも　墓穴を掘って枝番ミスった

枝番て何ですか？

427 ：仕様書無しさん ：2006/02/06(月) 22:41:18
eclipse対応だと枝番単位に専用のプラグインがあるんだよね。
これは正直引いたよ。マジかと思った。
ttp://download.eclipse.org/tools/emf/scripts/downloads.php


428 ：69式フリーPG ◆hND3Lufios ：2006/02/06(月) 22:42:24
ﾜﾛﾀ

枝番君は一つ一つ落としてインスコしてるのか
大変だなぁ

そんなもの言語仕様に入れないからシンプルになるんじゃん。

>>314
その部分はEclipseの影の部分だな。
たしかに、verちょっと間違うと、
動くことは動くんだけど挙動が変とか、
結構問題が発生してくれる。

さっさとVS.netがまともになれば良いんだが、
あっちはあっちで糞重いしなぁ。

互換性が高いとか安全とか騒ぐ椰子は
枝番仕様をしらないのかな？

>>308
阿呆にも程がありますよ。

>>316
ちょいまて、流石にネタだよな?
C++の言語仕様がシンプルて…

>>317
EMFやGEFならeclipseからupdateすれば、
細かいバージョンは気にすること無いよ

>>308
クリティカルセクションで制御しすぎるとアッサリ固まるぞ〜。
Ｃでスレッド使ってもポインタで楽せずにちゃんとコピーしましょう
っつー事で個人的ファイナルアンサー。

前から思ってたんだがみんなそんなにスレッドって使うの？
漏れは基本的に一つ作ってそれの使いまわしするんだけど・・・。

スレッド作成はバカしない限り失敗しないけど、制御用のハンドル
作成はバカしなくても発生するのが怖い。

>>322
>クリティカルセクションで制御しすぎるとアッサリ固まるぞ〜。
そりゃバグだ。
つか、いつでもどこでもクリティカルセクションしか使わない奴のコードは
信用ならん。

クリティカルセッションと宣言一発で同期処理が出来るsynchronizedだったら後者の方が圧倒的に簡単だろ？

>>324
つかぬ事聞くけどタイムアウト処理はどーするの？

>>322
>>323
全体クリティカルってか、そりゃJava厨のsynchronizedだぜ
必要最低限をクリィテイカルには当然の基本

μTeXで調停するのもクリティカルも同じ
シンプルな実装ならばよく練った設計とクリティカルがお勧め

>>322
漏れはめちゃくちゃ使うでー
スレッドのチェーンでシステムを作って遊ぼうと思ってる今

Win32の　CreateTimerQueueTimerはお勧め
スレッド時限爆弾がつくれるでー

>>327
相当違います。同期オブジェクトについてもう少し勉強しましょう。
つか、みゅーてふ？

狭フォーでもいいよ

>>225
> OOは悪くないんだけどさぁ。
> パフォーマンスが上がんないんだよ。
> 保守性は良い。
> でもさぁ、客にとってはそんなのどうでもいいことなんだよ。

だがエンジニア同士の引き継ぎではオブジェクト指向に
なっていないコードを管理するのはかなりの死活問題で
その分だけ予算と納期を余分に見積もらないととんでもないことになる。
もしアブナイと思ったら
オブジェクト指向になっていないコードは引き受けるな。
だらしない変なコードは切り捨てた方が良い。顧客も切り捨てよ。
もしくは安く買い取れ。

JAVAの仕事で最初に調べた事はWINAPIを呼べるラッパーを探す事。

CreateFileMapping は無かったので結局、javaから使えるようにDLL作成orz

こういう部分を語らすして、表面の部分だけを誇られてもなぁ＞JAVA

そもそもJAVAのOOが使える部分では、C＋＋でもDelphiでもVBでも使いやすいのを
使えばよい。　

直接呼べちゃうほうが困ると思うのだが。
何の為にJava選んだんだか。

>>333
> javaから使えるようにDLL作成
のどこが
> orz
なのかわからん。

そもそも、Win32APIに依存した設計になっている時点で、
Javaを選択する意味がない希ガス。
素直にC++で組んでおけばいいだけじゃまいか？

WINAPIに依存するようなJavaって俗に言う糞ソースぢゃん

>>333
Java はよく知らんのだが、ファイルにマップされた共有メモリなら
FileChannel ってクラス (当然スレッドセーフ) があるみたいなんだけど。

>>333>>338
メモリマップトファイルのような、大概のOSで提供されている機能(CreateFileMapping/mmap)が
1.4になるまで使えなかったのは問題だった。
ただし、既に過去形ってこったな。

>>333
ラッパーを探したのは認めるが．．．

JAVA　　--->　RAPPER　--->　WINAPI

ってことだろ？


何もRAPPERまで書けとか、WINAPIの中さわれるとか、ゴリゴリなＣプログラマのようなことは言わない。

ただ、RAPPERぐらいで表面から深層に触れたようなことを語られてもな。

Sun的なオレとしては．．．

JAVA　　--->　RAPPER　--->　WINAPI

ていう図式は、「それ、違うだろ？」って感じ。

そもそもＷＩＮＡＰＩを呼ぶだけで、今は事足りるのだから、「楽な時代になったよね」

昔（がすごかったのではない。基地外沙汰だっただけだ）は、ＷＩＮＡＰＩは自分で書いたり、ソケットまで書いたりしたもんだ。


オレは今はＪａｖａの「すごく表面的な部分」で仕事してるよ。楽な時代だ。
本屋に行けば技術書が売ってるし、ネットですぐ調べられる時代なんて夢のようだよ。

そこまでしてJavaをつかう理由ってなに？
漏れにとってはJavaは使わせる言語であって、自分で使う言語じゃないんで。

x rap
o wrap

>>341
マルチプラットフォーム神話が、はびこっているからだろう。

>>342
THX

>>340
WINAPIを書くってどういうこと？

>>344
たとえを出したらキリが無いけど、たとえばゲーム（内容によるが）でキャラクターの細かい表情の変化を提供されているＷＩＮＡＰＩで書こうとするのは無理。

それも、要求されているデティールの部分まですべて満たすことは無理。だから自前で書く。

へたをすると、会社に住んで、ボロボロの服着て、週末は秋葉へＧＯになるので、要注意。

まあ、オレはそんな世界には無関係だが．．．．

>>345
隊員さんが書いたWINAPIはどのバージョンのWindowsに搭載されていますか？

Java遅ってー！　ハナシにならん！

んだんだ

JavaよりLispだな。
Sunにはハッカーは1人しかいない。

javaは今年で終わる言語。

漏れもそう予想している。

来年は？

Ｃ丼

リッチ&スマートクライアント

スタスキー＆ハッチクライアント

ジョン＆パンチクライアント

Ｃ丼は始まりすらしなかったな

リッチー＆カーニハン？
ttp://www6.big.or.jp/~beyond/bbsnews/proxy/ascii2d/1137762953/

C丼
しーどんとねっと

オブジェクト指向主義者はオブジェクト指向の本質を理解できていないから追い求めている気がする。
例えていえば、眼前にぶら下がった幻のニンジン。

煽りじゃなければ具体的に詳しく。
そういう煽りをするってことは、オブジェクト指向のことを理解しているんだよね？
理解もしていないのにそういうことをいって僻んでいるとかじゃないよね。

ドカタコントロール仕様==OO
なにを必死に>>361

>>362
煽りじゃなければ具体的に詳しく。

>>362
お前の方が必死だな。
結局根拠を示せなかったわけだが
妄想しか抱けないC言語厨は

>362に禿同
根拠を示すことに何らかの意味があるとは思えん。
プログラミングの世界にも努力では越えられない壁がある。

OOを理解する程度のことは努力すれば誰にでも出来ると思うがな。
その程度の努力すらしないアフォ>>362>>365

>>365
>根拠を示すことに何らかの意味があるとは思えん。
>>360 が莫迦かどうかの判定材料。

だか根拠を示せる人間のほうが信頼される。
君はそれをわかってないようだね。

天動説を信じている人間に地動説を信じさせる事なぞ出来ない
by トーマス君

つまり、C言語厨は天動説を信じる愚か者なのか。
だから根拠はいらないと主張して逃げる分けか

まさにC言語厨はオカルト集団の宗教団体の連中にそっくりなわけだ。
それて年寄りになってオブジェクト指向についてゆけないわけだ。

宇宙オブジェクトはあるかもしれないが、宇宙の一部オブジェクトは記述できないかもしれない。

cat とdetab をJava で真面目に書いたら、ファイル数とコード行数が
それぞれ四倍とか五倍とかになった。
再利用に適していて、しかも先へいって破綻しない形に設計しようと
すると、立ち上がりがかなり遅くなる上に、ボリュームが増える。
OO に移行しようとすると、思想とか方法論とかじゃダメなので、
一年か二年は試行錯誤しながらスタイルを確立する必要があるが、
仕事しながらだとそれだけの手間をかけるのはツラい。
さりとて、仕事でOO を使いこなしているような先達は周囲に
いないので、人から学んで身につけるのは困難。本で勉強しようと
思っても、資料代が馬鹿にならん。
まあ、これだけのデメリットがあってなおかつOO を選ぶっつーのは、
余程の馬鹿。

　……とはいえそういう馬鹿でないと、三十にもならないうちに
韓国やら中国やらインドやらの、単価が安くて体力があって
コーディングパワーのある技術者に駆逐されるワケだが。

ていうか、
ファイル数やコード行数で比較しようとしている時点で
間違っていることに気付け。

>>373
ていうか、ファイル数やコード行数のような“わかりやすい”基準でしか
物事を判断できない馬鹿には、OO の有難みはわからんということ。
cat なら、
・テキストファイルの「内容」である、順序づけられた文字列に対応した
クラス。
・文字コードや改行コードを含んだ、「テキストファイル」に対応した
クラス（＝String のArrayList）。
・ストレージ上のファイルからテキストファイルのインスタンスを生成する
静的なクラス。（createなんたらかんたらを実装したファクトリークラス）
・cat に類するツールが普遍的に使うメソッドを実装したコンクリート
クラス。（gets と puts を実装したクラス）
・プログラマが各ツールにおいて実装すべきメソッドを記述した
インタフェース。
・cat のような、「ファイルから読んで標準出力に出すツール」を表わす、
コンクリートクラスを継承し、インタフェースをインプリメントした
抽象クラス。（Abstructなんたらかんたら）
・デフォルトの実クラスである cat。
とかいったものを一通り作っておくのが定跡なので、似たようなツールを
何個も作ことをあらかじめ想定しておかないと、効率に結びつかない。

そりゃcatならな、じゃ片付かないの？

>>371
宇宙には母宇宙、子宇宙、孫宇宙というものが存在する。
宇宙は真空の揺らぎからインフレーションが起きて産まれた。
そそてその後に子宇宙などを生み出しビッグバンによって今の宇宙ができあがった。

母宇宙と子宇宙、子宇宙と孫宇宙との間はワームホールやベビーユニバース
と呼ばれるブラックホールの一種によって繋がっている。

それってようするに、人間の認識できている範囲を「宇宙」というか
その範囲外をふくめて「宇宙」というかって話。

全は一、一は全。

って、アニメからの発想ですか？

というかさ、
人間ってのは自分がいる場所を中心にして考える癖があるんだよね。
最初は自分の田舎から始まって、藩や県、首都、国、地球、
地動説が認識されると太陽系、そして銀河系、そしてビッグバン。
何かを中心にして考えていたのが、
より高次から俯瞰された新しい認識で訂正されていく。
いままでビッグバンが宇宙の始まりとされてきたが、
所詮は広大な宇宙の辺境で起こった波紋の一つに過ぎないという
認識が広まりつつあるということだね。
この考えはシステム化にも役に立つかもね。

>>360だがこのスレお気に入りに入れ忘れててフォローできなかった。スマソ。

俺が思ってるのは、オブジェクト指向に本質的に意味があったのはC++が登場した初期の頃だけってこと。
当初はプログラマの現場からのコードの融通性のきかなさが指摘されてある程度ソフトウェアを部品化する手段としてクラスによるカプセル化や継承などの基礎ができた。
ここまでは良かった。

その後、ソフトウェアに部品作りのみをやろうとする企業も現れたが、うまくいかなかった。これは10年以上も前の話なので究極の部品化なるものが本当にどこにもひずみが無く可能であれば10年後の今日にはC++の部品だらけになっていても良いはずだ。

しかし、現状は部品化されたモノといえば、言語ベンダーのクラスライブラリ止まり。これはそれ以上の粒度での普遍的な部品化は旨みがないことの証拠だと捉えられる。

プログラマーの現場から発信されたオブジェクト指向は今では設計屋が自分の仕事の範囲のみで便利な商売になるお題目にすり替わっているように見える。実装まで視野に入っていないのだ。
設計屋に自分が設計したオブジェクト指向の美しい設計図を実装させてみて気づいたことだが、その場合実際に動くモノを作れるやつはいなかった。実装できない設計なのだ。設計図を見た人には要件は理解しやすいが実装に素直に落とし込むことが苦しいのだ。

しかし要件は理解しやすいので実装まで考えなければステークホルダーの受けは良い。苦労するのは実装をする下請け会社だけだ。設計屋と実装屋の分業が始まり、生まれた頃とは経路の違うモノがオブジェクト指向思想として広められているのが今日の状況。

設計だけして実装フェイズ前に逃げる設計屋が多くなった。

部品化なんて今更・・・・なんだが、今更なのにこの程度というのが今のオブジェクト指向の実態だと思う。商売の道具になってしまったらこんなもんなんだろうけど。ビジネス至上主義の弊害だと思う。

>>380
OOPとOODは別物
再利用の神話はとうに崩れている
それでもOOは有効

OOPはだめ
OODが有効ってこと？

>>380
> 設計だけして実装フェイズ前に逃げる設計屋が多くなった。
「請負」という名前の偽装請負が増えたせいだろ。
実装ベースから運用を眺めて、要求と工数と設計がうまく噛み合った
瞬間に、「よし、いける！」と感じる感覚っつーのがわかってない
奴が、「工数×単価でどうこう」とかいって算盤弾いてるから、
そういうことになる。
パッケージソフトの開発とかしてたら、それなりにマーケティング
感覚みたいなのが身につくのだが、派遣ボケした頭では
どもならん。

所で、Win32API使った場合ｱﾌﾟﾘが消費するメモリーってどれ位かしってるか？

知ってる
ﾀｽｸﾏﾈｰｼﾞｬで知ることが出来る

OOPへ素直に落とせないOODが駄目だと思う。実装と保守までが目的だからな。
解りやすい設計は本来の目的ではないだろ？

はいはい深夜までインタプリタ乙。

　　　　⊂⊃
★　 ∧η∧
　＼_(,,・Д・)＜すまそ、ＪＡＶＡ開始５日目ですでに嫌になってるぞ。
　　ヽ　　　 |フ　オブジェクト思考じゃなくて携帯アプリのつくりが嫌になってるぞ。
　　 /＿ ＿|　各社全く違う環境と設定がむかつくぞ。

　 　 　 　　　 　　　　　,,ｨヘ、
　 　 　　　　 　 　 　／　 　｀＼＿＿_ ＿＿___
　　　 　　 　 　 　／　　 　 （￣　＿＿＞＿＿＞
　 　 　 　 　 　　（　　　　 　 ＼　|ヽ/　/
　 　 　　　　 　 　 ＼　　　　　　　０　ヽ_∧
　 　　　 　　 　 　／_)　　 　　（　 　 　 　`ﾉ
　 　 　　　　 　 γ＾＼__∧η∧ ヽ､(⌒ヽノ
　 　 　　　　 ＜/　 　 ｨ (,,・Д・)＿￣フ JAVAだから簡単だろうという事で工数を減らす
　 　 　 　　 ＜/　 , 　 しｲ三ﾉつ　￣　　この事実がむかつくんだぞ。開発言語で優れているなら
　 　 　 　 ┌ノ　 ｲ 　 ｨ三イ＾ヽ、　　もっと色々な場面で活躍してるはずだぞ。
　　 　 　∠＿__／|_ｍ|￣｀L_ｍ|　　さぁさぁ、これから先のゲーム業界で全部ＪＡＶＡにしてみるがいいぞ。
　 　 　 　　 　 　 　￣　 　 　￣　ＪＡＶＡ厨房のパワーを見せてもらうぞｗ

なんやのこのキモいコテ

【IT】米Red Hat、JavaアプリケーションサーバのJBossを3億5000万ドルで買収へ
http://news18.2ch.net/test/read.cgi/bizplus/1144700222/

>>388
携帯電話開発に関わるとはご愁傷様。

　　　　　　　　　　　　　　　　　☆）)
　　　　　　　　　　　 ∧η∧　　/
　　+　｡.　。　"(,⌒ゝ(,,・Д・)つ　＜>>390 ググってしらべるといいぞ。
　｡.*　　゜　　　（_ノｿと　 ﾉJ　>>392 携帯電話＋名古屋という時点で俺は会社を辞めようと思っているぞ。
　　　　　　　〜　　　し'し'　正直、携帯アプリでゲーム開発なんて今更やることじゃないぞ。
　　　　〜　　　　　　　　　　ただ、アルゴリズムだけ考えて作るところだけならマシだが一人で全部というコトになったぞｗｗｗｗｗｗｗ

NGName逝きっと。

あれだな。新年度に入ってJavaのプロジェクトに入ったおまいらご愁傷様。

>>393
巣から出てくるな。

>>395
馬鹿な顧客と営業とマネージャに
囲まれながら携帯Javaのプロジェクトならご愁傷様だが
ちゃんとした奴と予算がたっぷりありかつ納期も大分先で
携帯電話でない開発ならご愁傷様でもないね。

BREW開発になるとさらにご愁傷様だが。

　　　↓冷暖房脳内補完のゴゾハウス
　 ＿＿＿＿＿
　/....LOL：）.../
　||:::　　∧η∧　　
　|￣＼ (,,・Д・)＜>>396 では、巣の中からレスするぞ。
　|　　 |:￣￣￣￣:|　もうJAVAめんどくさくてやってられんぞ。とりあえず動作させてみたが組み方はＣと大佐無しだぞ。

出てくんなと
失せろ

　 ＿＿＿＿＿
　|￣＼ｺﾞｿﾞﾊｳｽ＼
　|　　 |:￣￣￣￣:|＜>>399 出てきてないぞ。巣の中にいるぞ。
　|　　 |:￣￣￣￣:|

Javaの利点ってのが一つだけあるよな。

馬鹿が作るんじゃなければそれなりに構造化されたツリー構成にしないといかんし、
作った奴の所属組織とかも明示できる。

でもいかようにもぐずぐずにすることもできるからどーでもいいのかｗ
OOやりたければどとねと覚えたほうが現実的だとはいえるよな。

>400
書き込むなって意味がわからないのでちゅか？

>>401
バカが書いても「ぐずぐず」にならない言語なんて、
無いような気がする…。

　　 　 　 　 ,.、　,.、
　　　　　　 i,!';　,!i';
　　　　　　 ; lj: ;,ﾘ;'
　　　　　　;'　"´ﾞヽ
　　　　　 ;' ;. ‘,,λ ）
　　　　　;'　 (,,・Д・) ＜>>402 じゃ、余計な事を言わずに無視してほしいぞ。
　　　　,.;ﾞ; （ﾉ　　　';）　レスしたくなっちゃうんだぞｗｗｗｗ
　　　　`'ヾ;,（つ;,;,（つ　オパイベビーだから言葉が理解できんぞ。

まだいたのか屑

>>設計だけして実装フェイズ前に逃げる設計屋が多くなった。
設計がＯＯでないのでまず、実装は無理だからね。
実装してない奴は設計させないほうがいいよ。（漏れもだけど）

>>401
> OOやりたければどとねと覚えたほうが現実的だとはいえるよな。

そこについて具体的に詳しく説明

ﾄﾞﾄﾈﾄﾌﾚｰﾑﾜｰｸはオブジェクト指向に適しているとは言い難い
部分があまりにも多いのだが。

たとえば？

馬鹿も休み休みに言え。
Java厨房はJ#という移行パスにも乗ることのできなかった９０年代の遺物なんだぜ？ｗ

J#がそんなに凄いものだと思っている>>409は脳みそが故障しているようですね

ばー　　　　　　　　　　　　　　かー

J# って明らかに J++ (誰が使ってんだそんなもの) の .NET 対応版なんだが。

 これからはVistaになる。
 Vistaの標準コンパイラはC++/CLIだ。

 いやおうなしにJavaコンパイラもJVMもVistaで動かすならばCLIになる。
 つうことは、２重の仮想マシンで動く劇的に重い時代遅れのものになる。

 糞高いLinux専用サーバ上ででも金持ちが動かす道楽者専用になるな。
 本来、JavaとSolarisとSPARCという閉じた世界があって、その閉鎖性を強引に
 クライアントであるPC側に吸収させようというのがJava啓蒙の理由なんだが理解してるか？
 PCベースで無償のJavaつかってるということは、ただの道化なんだよ。
 パフォーマンスが悪い？ではSolarisをどうぞ。
 まだうまくいかない？それはｘ８６のせいです。SPARCをどうぞ。

 これがSUNの戦略であり実態でもある。
 お先棒担いでるJava厨房はおぷそ厨房にも似て哀れそのもの。
 無償で宣伝の手伝いm9(^Д^)ぷぎゃー

>>413
必死だなドトネト厨w
↓のスレでも同じレスしてコピペしてるだろ。
Javaって重くね？　その６
http://pc8.2ch.net/test/read.cgi/prog/1143032241/831

俺の勘がJavaに関わるなと言っているのだがどうしたものか。
試験受かっちゃったけれど。

お前のレベルじゃ力が足り無すぎてJavaを扱うのは無理だからな

そうそう、Java使うには強運がいるからな。

>>417みたいな問題解決能力や
新技術習得能力も無い山師にはJavaを使いこなすことができないな。
>>417にはせいぜい。PHPやVBのような厨房向け言語がお似合いだな

ほんとJavaってのは強運に恵まれないと使いこなせないよね。
単純でほかの言語使えば問題なく仕上げられる案件をわざわざ劇的に重くして金ジャブジャブぶち込んでくれる
体力のある顧客見つけられるだけの強運が必要だからね・・・。

Ｊａｖａを使えない年寄りか？
天任せにするより勉強すれば。

そんなもの勉強するならどとねと勉強するよ・・・

まあ、マ板で一番人気の言語であることは間違いないよ。＜Java

>>419のようなJava叩きには日頃からヤマカンでしか行動できない
性格がよく現れていますね。

>>419は自分の顔を鏡に写してみたことが有るのでしょうかねえ

>>422
昔はC/C++だったんだけどね・・・・

Javaは多分この先さわらないと思うからどーでもいいや。
C++/CLIでもいじくってみることにして寝るわ。ノシ

残念だな、Ｊａｖａはこれからだよ。
今、いよいよ汎用機からのリプレースがＪａｖａで本格化しようとしている。

>426 に同意。
なんだかんだ言ってもCOBOLの後継になりうるのはJavaしかない。
ビジネス上の判断は技術論とは別の次元にある。
ただ、プログラマにとってそれが幸せなことなのかどうかは...

そりゃプログラミングだけしかやりたく無い者にとっては幸せが
奪われる感覚に襲われるかも知れないさ。


だがJavaに精通してくると幅広い分野に興味を持つようになってくる。
組み込み系から基幹系、宇宙開発まで様々な領域に関心を示すようになる。

すると幸せなことは増えてくるはずさ。

Javaってのは、伝染性の病気みたいなものなんだな。危険きわまりない。冗長病ってやつか。

コボルの後継って、不良債権化するってことですか？

>>431
俺はJava好きだけど、いつかはそうなると思う

>>422
喰い付きがいいのは確かだな。

JAVA教えてください
http://page9.auctions.yahoo.co.jp/jp/auction/k32298577

>>430みたいな奴はGNUのことをどういうものだと
思っているのだろう。
凶悪な伝染病だとでも言いたいのだろうか。

まるで社会へのコンピュータやインターネットの浸透を恐れる老人みたいだ。
一昔前で言えば産業革命を恐れる連中。
さらにもっと昔で言えば本の存在を恐れる連中みたいなもんだ。

>>431
具体的に何が不良債権かするって？
kｗｓｋ

>>435 GNU？

SUNとかIBMとかOracleとか反M$陣営が出資したM$へのFUD運動のことだろ？
フリーライドさせて貰おうかとは思う。安全ならな。

もともと汎用機のシステムをＪａｖａで作り直したのは、
ＣＯＢＯＬチック、Ｃチックだから触りたくないぁ。
おまいら、オブジェクト指向で開発だぁ、っても
言ってる本人がオブジェクト指向じゃないから、
昔のまんまの繰り返しなんだよね。
あと、２０年はかわらないだろうね。

団塊＝こぼらー

団塊の子供たち＝Java好き

親子だからなぁ

JAVAはクラス作りすぎ

オブジェクト指向設計をやると
仕様変更の修正が余計大変だろ

>439
うまいこと言うなぁ。それ、今度どっかで使わせてもらおっと。

>>437
> >>435 GNU？
> SUNとかIBMとかOracleとか反M$陣営が出資したM$へのFUD運動のことだろ？
> フリーライドさせて貰おうかとは思う。安全ならな。

お前また恥ずかしいこと言ってるな。
知ったかぶり乙。GNUとIBMやSunとの違いもわからないとは馬鹿にもほどがあるドトネト厨

>>439,>>441
つまりバブル世代はC言語信者ってことか？
コボル狂信者は団塊だけでなく新人類世代と呼ばれる40代にも集中しているぞ。
むしろ新人類世代のほうがCOBOL厨が多い。
団塊なんてコンピュータなんてほとんどしらない、ろくに使いこなせない
連中ばかりだし。

４０代だけど、Ｊａｖａしか使えないよん。
Ｃ言語は前世紀迄。

２１世紀のコボル＝Javaということでよろしいな？ｗ

良きCOBOLとしてならそれは真であろう

>>442 https://www.fsf.org/donate/patron/ （ ´_ゝ`）´_ゝ`）´_ゝ`）

>>447が花王のマークに見えた

http://www.kao.co.jp/corp/about_kao/a07/mark.html

で、爺さんどのマークに見えたんだ？ｗ

気味悪すぎてﾜﾗﾀ

桜玉吉が描いた絵かと思った

いや、玉吉そのものじゃねえか！

ﾌﾟﾌﾟﾌﾟ C言語厨は情報処理学会にすら入会できない低脳なのですね

情報処理学会＝プログラマの権威
http://pc8.2ch.net/test/read.cgi/prog/1141487104/

構成年齢を考えると情報処理学会は C > Java だと思うのだが...

あと、会費を払うつもりがあるのなら誰でも入れるので>453が何を言いたいのか
良くワカラン。プログラマ的には情報処理学会より日本ソフトウェア科学会の方が
合ってる気がするし。

そのC言語厨が、何か問題起こしたので情報処理学会ですら
入会できなかったということですよ

申請しないから入会しないんだろうなぁ。

いりもせんことにお金を投げ捨てる馬鹿も早々いないだろ。

いや、C言語厨は人格に問題があるし社会的信用も小さいから
入会しても審査で落とされるよw

サラ金みたいな審査するのかよ。くだらね。

・高卒たたきに見せる異常な人格
・法政卒君が見せてくれた程度の社会的信用

これで入会できるんだから基準なんぞやくざとかわらんよなｗｗｗ

情報処理学会って入会審査できたの？

どうせ教授に入れて貰ってずるずる払ってるだけだろ・・・入ってるにしたとこで。

おまえらばっかじゃね？
落伍者が集まって何ナメアッテンダヨ。
けっ、、ｗうんこ野郎ども！

>>459
法政卒も馬鹿高卒もどっちも退会させられるよ。
お前らどっちも大学嫌い、研究機関嫌いな人格障害者だからなw

エンタープライズ系って聞こえは良いけど
要は業務系でしょ？

ビジネスロジックとかなｗ

>>464
ものにもよるがな。
業務系といっても基幹系業務は馬鹿にならない。

>>466
別に、業務系には莫迦にされる要因はない。
業務系に携わる人間が揶揄されているだけだ。

ハードケイとハードゲイって間違えやすいよね。
学生さんもハード系に進むつもりで間違えないようにね。

まあ、ハード系で監禁生活送っても、ハードにはならないと思う。
単なる内向的な同性愛者にはなるかもしれんが。

>>282
なんでそうなるんだか。
スレッド事態がオブジェクトでもいいじゃないか。
どっちがドカタよ。ミドルウェアのほうがドカタ率高そうなんだが。

>>379
> というかさ、
> 人間ってのは自分がいる場所を中心にして考える癖があるんだよね。
> 最初は自分の田舎から始まって、藩や県、首都、国、地球、
> 地動説が認識されると太陽系、そして銀河系、そしてビッグバン。

まて、間に、抜けているものがあるぞ。
銀河系の次は銀河団だ。銀河団の次は超銀河団だ。
そしてグレートウォールやグレートアトラクターなどが存在する。
果てにはクェーサーが存在する。
それからビッグバンよりも前に宇宙ではインフレーションというものが起きていた。
あれこそが宇宙の急激な膨張で、ビッグバンはインフレーションと比べれば
ゆっくりとした膨張だ。インフレーションが起きるまでは原子すらも存在しなかった。

宇宙項は実は存在したと言われているが、
それは本当なのか？

宇宙の膨張はますます促進するというのか？

では我々の世界はこれからどうなる？
数兆年後には我々は・・・・・
どこへゆく？　

数兆年経っても人類は生きているだろうか・・・・
我々はどこの惑星に移住しているのだろう・・・

我々の子孫は太陽系から離れて
どこに言っているのだろう・・・・

>>469
終わった話題に、今頃になって参加したいのなら
もう少し頭を使った内容にしましょう。

>>473
また出てきたな、VMのソースもみてないおじゃば様が。
祭りだ。

jrockitもレビュー頼む

そんなことよりおれは宇宙項に興味がある。
アインシュタインが「今世紀最大の間違いだ！」
と嘆いたあの宇宙項の存在。

しかしアインシュタインの予想に反して、この前の
観測結果によって宇宙の膨張にブレーキがかかるどころか
加速していることがわかった。
だから宇宙項が存在するというらしいのだが・・・・

どうにもならなくなって妄想の世界に逃避したっておちか？
おじゃばさま。

そもそも、C厨の脳では宇宙論や物理学の話をしても
理解できないから

>>474
>>469 の間抜けぶりを指摘したまでです。
ついでに言うなら、
>VMのソースもみてないおじゃば様が。
どんな電波を受信したのか知りませんが、
私は Java などやっていませんし、やる気も (あんまり) ありません。

おじゃば様と言ってる香具師はC言語屋だろ

じゃばじゃばたくさん沸いてくるっと。

つまんねー

トラックバック:http://app.blogs.itmedia.co.jp/t/trackback/4088073

脱オブジェクト指向のススメ
ttp://blogs.itmedia.co.jp/tamaki/2006/06/post_57ab.html


このイーキャッシュの代表取締役玉木の発言がおかしいから
このスレからpinする。

オブジェクト指向のことをまったくわかっていません。
というか、かなり勘違いしています。
そのくせにオブジェクト指向を否定しています。


あまりにも突っ込みどころが満載です。
まさに指向停止している人間というか知った君の典型的発言ですね。

これで代表取締役が務まるのですから
思いっきり叩いてやっちゃってください。

　

ただの釣りだろ。叩くだけ無駄。

よく見ろ。記事のそこかしこに、逃げ口上が書いてあるだろ。
「ときどき、役に立つときもあります」
とか
「そうしているうちに、いつの間にか、オブジェクト指向も身に着く（というか、
その本質が何かに気づく）でしょう。」
とか。

そのうち、
「読者の皆さんが、オブジェクト指向が使いこなしているか知りたかったので、
わざとこんな書き方をしたんです」
とか言うんだよ、きっと。

×オブジェクト指向が使いこなしている
○オブジェクト指向技術を使いこなしている

ヘタな文を読むと、こっちの日本語まで変になるよ・・・orz

指向停止しているのは君らだろ。
オブジェクト指向に対して何の疑問も感じんのか。
誰も反対意見を言わない完全無欠のパラダイムだと思っているか。

> そのうち、
> 「読者の皆さんが、オブジェクト指向が使いこなしているか
> 知りたかったので、わざとこんな書き方をしたんです」
> とか言うんだよ、きっと。
著者の意図がわかるなら絶対こんなことは言わないよ。
釣りでも何でもなく本音ですって。

訂正

指向停止
↓
思考停止

著者の意図がわかるなら絶対こんなことは言わないよ。
↓
著者の意図がわかるなら絶対こんなことは言わないのがわかるよ。

その本買った記憶があるけど忘れてたｗ

この世に完全無欠なものなどない。
その場その場でもっともましなものを使うしか方法はない。
一つの薬で全ての病気は治らない。

>>486
じゃ、そう思うなら読者全員がオブジェクト指向を使いこなしていないという
根拠が一体どこにあるのか説明してみ？

どうせイーキャッシュ代表取締役の玉木君はデザインパターンも
オブジェクト指向の設計原則、　"Design by Contract" も
ろくに知らないんだろうけどね。発言からすぐにそのことがよくわかる。

>>489
そうそう、Brooksの銀の弾丸。

>>486
そこまで言うなら、1つだけ。
デザインパターンとかコントラクトとかを理解してなくてもわかるのを。

件の代表取締役のページで、
オブジェクト指向じゃない例としてあげられていたVB(.NETじゃないやつ)について。
VBで使われていたコントロールは、ActiveXやOCXで実装されているが、
これらはOLE(Object Linking and Embedding)という技術の進化形なわけ。
つまり、VBプログラマは、オブジェクト指向の恩恵にどっぷり浸かっていた人たち。
たとえ自らオブジェクトを設計した経験はなくても。

そんな人が、オブジェクト指向技術を非難していたとして、
わざわざまともに取り合ってあげるだけの必要あるか？

なんか話がズレてるな。>>483のリンク先の文章を読む限り、コードの再利用とかそういうレベルの話じゃ
なくて、オブジェクト指向を理解しても相談に来た若者が本当に必要とするような開発の中での問題解決の
スキルは直接得られないよってことが言いたかったんだと思うんだが。

>>492
1. OO以前の問題で悩む奴がいた
2. OOでは生産性も再利用性も上がらない。だからクソ　　←ここで飛躍
3. 問題解決の為には他のスキルを上げるべき
4. コードを書いていけば、そのうち OO の本質に気付く

で結局、その本質とやらも書かずじまい。
…ってまさか、上記2〜3が本質だなんて言ってるわけじゃないよなぁ…？

まあ、自称 IT 業界の人なんてこんなもん。

1. OO以前の問題で悩む奴がいた
2. 専門学校に行って基礎（？）から学びたいと言った。
既に社会に出てプログラミングを仕事しているのにオブジェクト指向で悩むぐらいのやつが
いまさら専門学校に行っても意味がないと思い
3. （お前のようなやつが）オブジェクト指向など（を学びなおしても）クソの役にも立たないと忠告してあげた
ともとれるよね(^^;

今、オブジェクトとか口走る場合、

次世代開発基盤技術“Software Factories”詳解
http://www.atmarkit.co.jp/fdotnet/softfactory/index/index.html

とかが理解できている必要がある。が、はっきりいって意味不明である。
１０年前のＯＯの本も理解不能だった記憶があるが、この辺の本というのは、数学モデ
ルを使うからわからなくなるというよりも、失敗した巨大プロジェクトのエッセンスだけ抽
出して生成されているが、理解に必要なディテールは社外秘なので全部カットされてい
るのでわかったらおかしい、という世界のような気がする。そこのわかったらおかしい部
分を判別してスルーして読めるかどうかが、バカのリトマス試験紙といえよう。

>>495
意味不明？ただのフィーチャだろ。
すでにオブジェクト指向が理解できてるなら、まずアスペクト指向を勉強しろ。
まだ理解できてないなら、なんだ、例の「クソの役にも立たない」ってやつだ。
やめとけ。今更やっても乗り遅れるだけだ。

>>492
そう言いたかったんならそう書けばいいのにねえ。
彼には、人に解らせようという努力が足りない。
曖昧模糊と暗示させようという考えだから叩かれる。

>>495
解らないなら『アジャイルソフトウェア開発の奥義』でも嫁。
あっちならお前のレベルでも理解できるだろう

なんか世代間闘争みたいなふいんき(略)も出てきたな。
生まれたときから(それなりに使える)クラスライブラリがあった世代とそうでない世代。

ああい黒縁うメガネ野郎ってなんか気に入らないんだよね。
自分が真面目だと勘違いしてるみたいで

真面目でエリートっぽい人間に思われたいからわざと
ああいう黒縁メガネ書けてるんじゃなかろうか。

Javaや他のオブジェクト指向言語でそれなりのレベルに達してる人にとって
OOが万能ではないにせよ役に立つってのは自明の理なのだけど、
自明なだけにそれを言葉で説明するのが難しいんだよね・・・

「１＋１はどうして２なの？」って言われてるようなもんだし。

コミュニケーションの成り立ちようが無いんだから、
お互い接点を持たずに居るのが幸せってもんだ

みんながみんな自分だけわかってて他人に説明できないなら普及はまず無理。
結局社会文化的に見て役に立たない。

みんながわからないわけじゃなくて馬鹿にわからないだけ。
わかる人には説明しなくてもわかるけど、馬鹿には説明してもわからないからね。

なんだかんだいってOOも結構普及してるし、
世の中そんなに馬鹿ばっかりでもないんだな

説明できないのは馬鹿だから
趣味でやってんじゃねーよ

じゃあおまえ説明してみろ。

つ バンパーステッカー文化

ココに来るやつはみんな馬鹿だから無理、ってオチか。

OO使ってればそのうちわかるんじゃね？
わかんないやつって、一体なにがわかんないの？

>>508
> わかんないやつって、一体なにがわかんないの？

それが不思議なんだよね。
そんな難しいことでもないのにねぇ・・・

OO原理主義者みたいなのが居るからOOまで嫌われているというのが真相なのでは？
昔、Macユーザが嫌いだからMacが嫌いって香具師がいっぱい居たみたいに。

坊主憎けりゃ袈裟まで憎いって奴か。解るなそれ。

>>510-511
技術者がそんな感情的な理由で技術を嫌うは、
エンジニアとしてどうかと。

原理主義者といえば、アセンブラ原理主義者やC言語原理主義者、速度狂原理主義者も
似たようなもんだけどね。OOにすると遅くなるから使ってはならないとか
時代に似使わずわけのわからないことを言う香具師とか。

JavaやC#、STL, Rubyを使っていれば
必然的にオブジェクト指向でプログラミングしているんだけどね。

ま、ポインタ演算を一発でわからん奴は、ＯＯは使わせないほうがいいな。
なんでもかんでもフレームワークのようなものをつくった連中の所為にするだけの
ボンクラな予算古事記になるだけだからな。
…ＯＯ用語を使って「人の所為にするのは得意なんです」という自己アピールを
してるだけの連中が多くてね
…「今度、あのＯＯ-onlyバカどもを殴りに行こうか？」って
今の現場の「わかってらっしゃる」方達で相談してたよw

ま、ボクはメタプログラミングや高階関数言語などを
使っているので、「どっちも、どっち。どっちも消えればいいじゃん」
って思ってるんだけどねw

>>512
必然的でもないだろ
それはただの勘違いだ

>>507
・・・糞ガキてめこのやろー・・・。
チマチマチマチマ女みてーにしゃべりやがって。

>>512
感情的っつーかやっぱり押し付けがましい奴はどんな職種だろうと嫌われると思うぞ。
例えば「○○に入信すればどんな辛い事も乗り越えられます！尊い教えです！是非！」とか勧められてみ？
この業界、リアルで宗教入ってる奴結構いるからなあ。しかも本人は善意で言ってるから性質が悪い。
そういう意味では最近のオブジェクト指向信者もそうなりつつある。

まぁ、わからないなら黙ってなさいよw
いちゃもんつけて馬鹿をさらすのはみっともないからやめなさいってこと

大体オブジェクト指向なんか80年代から使われてるのに未だに理解できない奴はもうどうしようも無いな

>>516
> >>512
> 感情的っつーかやっぱり押し付けがましい奴はどんな職種だろうと嫌われると思うぞ。
> 例えば「○○に入信すればどんな辛い事も乗り越えられます！尊い教えです！是非！」とか勧められてみ？
最近そういう変なにも減ったね。

> この業界、リアルで宗教入ってる奴結構いるからなあ。しかも本人は善意で言ってるから性質が悪い。

最近そうゆう宗教入ってるやつみかけなくなったな。
アニヲタとかいう変な宗教に入ってる奴はいるけどw

>>513
ポインタ演算を一発で解ったと逝ってる奴ほど、
実際には何も解ってなかったりと信用できないんだなこれが。

それはかなり極端で僻みが酷いんじゃないかと。


ポインタ演算がわからないでOOを使うととんでもないことに
なることはまず無いけど、
確かに。ポインタがわからないでOOを使うと間違いなくとんでもないことに
なるね。

>>518
それはいえてるね。
イーキャッシュの代表取締役も
もうどうしようもないっつーか。

OO房ってさ、傲慢だよね。
根本的にOOは自分以外わからない、もしくは馬鹿にはわからない
という空気がプンプン。多分、OOが解るのがプライド、アイデンティティ
なんだろうね。だから否定されると感情的になって怒る。

多分、OO房の中ではオブジェクト指向が一番難しい知識なんだろうね。
基本的に勉強が足りない。
(多分、本人は一生懸命勉強しているつもりなんだろうけど)

君らが理解しているレベルのOOは誰でもわかるから安心しなさい。
もうちょっと謙虚になりましょう。

それは一理あるかな。
経験3年目くらいまでだと、あまり知識が成熟されてないというかトンガッテル。
まぁ、誰もが通る道だけどね。

それと某イーキャッシュの人の低レベルな発言は別次元だけどw

>>522
被害妄想が激しい。
ちょっと頑張れば理解できるものを
そうやって毛嫌いしているから
いつまで経ってもオブジェクト指向プログラミングができない。

だから理解できたやつは必ず絶賛するとは限らないのを理解しろ。
これで「絶賛しないのは本当にはわかってないからだ」とか言い始めたらアレだが。

つうか、OOを「新しい知識だから年寄りにはわからんだろう」
と考えてる奴がなんでこんなに多いのだろうか。

新人のころに、SmallTalk や C++ にはまって、
仕事の都合で仕方なくずーっと Cで組んできて、
Java　が使えるようになってやれうれしや、
と思ってたら、なんか、日経の特集記事とかだけ読んで、
「これからはオブジェクト指向だよ」
と説教たれてくる奴がいっぱい出てきてウンザリ。

それはご愁傷様ですなw

俺のまわりの派遣君にもそんな子いたよ。
ことあるごとに「これわかります？」とか言ってJava2の試験問題持ってきたりして。
でも、こちらの知識見せつけたら何でも言うこと聞いてくれるようになった。

まぁ、かわいいもんですよ

だから俺はオブジェクト指向で設計もプログラミングもできるんだって。
俺はプログラミングを始めた直後からOOだった世代だし、ずっとOOで
やってきてるって。

そういう俺から見てOO批判されたからって、感情むき出しで
怒りだすのがケツが青いっていってんの。

「OO房に釘を刺す=オブジェクト指向のできない人」
という傍から見たらすごい頭の悪い先入観はよしなさいって。

このスレみてるとSTLがオブジェクト指向だとか、DbCが
オブジェクト指向の原則だとか、え〜〜〜と思うトンデモ
発言があるし、みんな解ってるとアピールしてるけど
本気で解ってるのか？

DbCはオブジェクト指向とは直交した概念です。
ホーア理論とか解っていってるのか？ちゃんとしたDbCを
やるには論理学の知識が必要だし、DbCを「原則」といえるほど
きっちりやろうと思うと、相当な数学センスが必要でめちゃくちゃ
大変だぞ？口だけじゃなくて本当にやったことがあるのか？

デザインパターンみたいなオブジェクト指向の初歩の初歩を
喜んで連呼するような厨房につかいこなせると思わないが...。

原則というなら(先にも上がってるが)ロバート・C・マーチンだろ。

DbCなんていわれてもワカンネ。assertとか、構造化例外とか、（静的な）型とか言ってくれ。

全く、人が悪いよ。

そもそも、インターフェイスじゃなくてメソッドの定義にしかアサーション書けないような
言語に疑問を感じてない時点で、DbCなんか理解できてないって承知の上で言ってるんでしょ。

まとめ

　・オブジェクト指向には30年ぐらいの歴史がある
　・その後何回かのブームがあった
　・従って、
　　・現在現役のソフトウェアエンジニアの大部分はオブジェクト指向について、知る機会があった。
　　・オブジェクト指向だけをやってきてベテランになっている人も大勢いる。

　　

・何年もやっててオブジェクト指向に触れられなかった人も居る
・それほど複雑な概念ではないのでちょっとセンスがあればすぐに理解できる
・それでも深遠は底なし沼

>>528
>デザインパターンみたいなオブジェクト指向の初歩の初歩を
デザインパターンはソフトウェアパターンの一種であって
OO の初歩というわけではありません。出直しましょう。

>>532
その指摘は正しいですね。
ただGOF本の記述がOOPに限定したものだったので
「オブジェクト指向の初歩の初歩」なんてぇ
勘違いしている輩が多いのは悲しい事でｗ

デザインパターンといっているのは狭義ではGoFのデザインパターン、
もうちょっと広げるとモノステートなんかの一般的に良く知られている
オブジェクト指向の設計、いわゆる「オブジェクト指向用語の」デザイン
パターンのことを言っていると「文脈的に」わからんのか。

オブジェクト指向以外でも設計の類型という考え方はソフトウェアに
限らずなんでもあるけど、それらはここで言うデザインパターンには
含まれない。

OO厨房の思考をトレースすると、

「オブジェクト指向以外のパラダイムは時代遅れであり、
デザインパターンのような設計の類型という洗練された
　考え方は存在しない」と思っていた
↓
ある日「オブジェクト指向以外にもデザインパターンに類する
ものがある」事に気が付く
(ここがOO厨房的には大発見)
↓
「こんなすごいことに気が付くのは俺だけに違いない！無知無明な
他の連中はわかってないに違いない！」

OOしか知らないOO厨房にはすごい大発見かもしれないけど、
普通の人には自明だって。さすがOO厨房、馬鹿の癖して傲慢だ。

age

OOしか知らないOO厨って、あんたはOO以外の
パラダイムに何かひとつでも精通してんの？

まぁ、この業界でデザインパターンって言ったらまずはGoFのパターン思い浮かべるし、
GoFのパターンはわりかしオブジェクト指向のパラダイムの上に成り立ってるものが多いから、
デザインパターンをオブジェクト指向の枠でかたっても間違ってるとはいえんでしょう

まず、保守性の高いソフトが作れること
客の要望を的確に把握できた成果が作れること
可能な限り、成果物はｷﾘﾜｹして会社の資産にできること

これが満たせるなら遅れていようが流行っていようがどうでもいいと思うけどな
ようは会社としてきちんとした方向性と生産性を示すこととその指標があるのが
いいんであってそれがOOじゃなくてもいいんだしさ

>>525
なんでおまいはそんな妄想ができるのか。
何かトラウマでもあるのか？

>>526
いまどきになってこれからはオブジェクト指向なんていう奴はいないよ。
今日経は技術動向についてはAjaxやオブジェクト指向を
大前提としたDependency Injectionに注目しているだろ。

結局オブジェクト指向が無ければ話にならない物ばかりってなわけだ。

>540

> 今日経は技術動向についてはAjaxやオブジェクト指向を
> 大前提としたDependency Injectionに注目しているだろ。

ﾏﾀｷﾀｰ！

Dependency InjectionはAjaxを前提にしてません。
だから本気でわかってるのかってからかってからかわれるんだよ。

Dependency Injectionは、単なるコンポーネント間の
依存関係を減らすための技術。かつ、今までの重量コンテナ
の反省の元に考案されているため、POJO以外の何かに依存してたら
Dependency Injectionの意味がありませんというかそれがウリだ。

Dependency Injectionのコンテナは周辺ライブラリが
用意されることが多いから、それのプレゼンテーション層の
何かをみてそう思っているのかもしれないけど。

Dependency Injectionだか闘魂注入だかしらんけど
まぁそんなことして本当に効率あがるのかよｗ

>>528
PerlやPHPやVB程度の言語しか弄った経験がない
スクリプト厨にはわからないだろうが
Design by Contractがオブジェクト指向と直接関係なくとも、
オブジェクト指向設計をする上で非常に重宝する考え方なんだが。

>>541
「Ajax」や「オブジェクト指向を大前提としたDependency Injection」
としか読めないんだが。

脳から汁が出てるのは判るが
人をくさす前にもうちょっと落ち着こうな。

いまさらDIの解説でもないだろ。
しかもなんかツボを押さえてない感じ。

だからDbCが非常に重宝するのはオブジェクト指向だけじゃありませんがな。
手続き型言語でも使いどころでは超強力です。

それから>>528はその怒りだしたケツが青い
という奴に対して2chで愚痴を零さなければならない状況の
追い込まれているわけか。

2chでそんな愚痴を零してもケツが青い奴はこのスレにすら
気づかないだろう。

>>533
GoFデザインパターンを理解することは実用的なオブジェクト指向
を理解する上で役に立つわけだから初歩の段階でオブジェクト指向教育に
GoFデザインパターンを持ち出しても何も悪くはなかろう。

君は代わりになるもので指導ができるか？

>>534
お前の僻みと被害妄想は一体どこから来るのやら。
必死に弁明しようとしているイーキャッシュ代用取締役玉木本人か？

> 「Ajax」や「オブジェクト指向を大前提としたDependency Injection」
> としか読めないんだが。
ありゃ、これは誤読だ。書いてて今更DIに注目というのも遅れている
気がしたけど、これを言い出したのは540。俺じゃないのでよろしく。

> 脳から汁が出てるのは判るが
確かに色々と楽しすぎて脳汁出ています。
いやー、最近、こういう娯楽がなくて、つまらなかったんだよ。

>>541
> >540
> > 今日経は技術動向についてはAjaxやオブジェクト指向を
> > 大前提としたDependency Injectionに注目しているだろ。
> ﾏﾀｷﾀｰ！
> Dependency InjectionはAjaxを前提にしてません。

半角文字がいかにも釣り臭いな。

んなこといってないだろ。
よく嫁。接続詞の結合力を勝手に脳内変換するな。

しゃあねえから結合度を明確にするために括弧を付加してやるよ。

(Ajax)や(オブジェクト指向を大前提としたDependency Injection)に注目しているだろ。

脳内変換野郎はこうやって勘違いを繰り返して来たわけか。
小学生みたいな「ﾏﾀｷﾀｰ！」みたいな脊髄反射な対応にはまったく呆れる。

>>545
日経は技術者志向じゃないからな。
@ITのほうがまし。
日経の記事をあてにしてる>>522==>>528は
可哀想なやつなんだろうがw

>>546
> だからDbCが非常に重宝するのはオブジェクト指向だけじゃありませんがな。
> 手続き型言語でも使いどころでは超強力です。

こう書いてあるんだがな。


dW : Java technology : AOPを使いコントラクトを実施する
"Design by Contract (DBC) とは、ソフトウェアの品質、信頼性、そして再利用性を確証することを目的とするオブジェクト指向のソフトウェア設計のテクニックです。DBCの重要な鍵を握る概念は、下記の方法でその目的を達成できることです。"
http://www-06.ibm.com/jp/developerworks/java/040820/j_j-ceaop.html


手続き型では本当に補助的な側面でしか役に立たないな。
どうせ構造体と関数ポインタでも使って擬似的なオブジェクト指向プログラミングをして
手続き型言語でもすべてのことを真似できる、とでも言うんだろ。

>>550
> 「Ajax」や「オブジェクト指向を大前提としたDependency Injection」
> > としか読めないんだが。
> ありゃ、これは誤読だ。書いてて今更DIに注目というのも遅れている
> 気がしたけど、これを言い出したのは540。俺じゃないのでよろしく。

だったら、未だにオブジェクト指向が流行っていると言いだすバカ
はどうなんだか。

> > 脳から汁が出てるのは判るが
> 確かに色々と楽しすぎて脳汁出ています。
> いやー、最近、こういう娯楽がなくて、つまらなかったんだよ。

まるで、最後の、しっぽを巻いて逃げる前の負け犬の言い訳だな。

> 手続き型では本当に補助的な側面でしか役に立たないな。
だから、DbCの効果は手続き型言語でもオブジェクト指向言語でも
まったく同じです。
> どうせ構造体と関数ポインタでも使って擬似的なオブジェクト指向プログラミングをして
> 手続き型言語でもすべてのことを真似できる、とでも言うんだろ。
DbCの「どこで」こんなことをする必要があるか教えてください。
AOPなら使うとDbCとメソッドの記述を切り分けられて便利というのはあるけど。

DbCって、dWに書いてあるような、
> * 事前条件: 外部コンポーネントを正しく呼び出すためにクライアントが満たさなくてはならない義務。
> * 事後条件: 外部コンポーネントの実行後に予測される結果。
> * インバリアント: 外部コンポーネントの実行後も不変であり続ける条件。
という理解で終わってるだろｗこれじゃ全然DbCを理解していることにはなりません。

まるでDbCを理解しているかのような口ぶり

理解してても使いこなせてかつ水平展開できなきゃ仕事にはならんのが難しいところ
学問とエンジニアリングの違いというか、その辺

>>557
うむうむ、そのへんがエンジニアの醍醐味だよねぇー♪

DIなんかはむしろ水平展開を「しなくてよくする」技術と位置づけられるのでは。
１人できるやつ＋雑魚大勢みたいなチーム編成で、もっとも生産性をあげるための技術というか。

>>534
>>549 と同じ事を訊きますが、
>OO厨房の思考をトレースすると、
何かの病気ですか？

GoF の事を言っているんだろう (というか、それしか知らないんだろう)
とは思いましたが、それが何を指しているかなど >>532 では問題にしていません。

>>555
お前は、手続き型とオブジェクト指向で
開発効率にどれだけ差が効果として出るのか解ってない。

>>555
アスペクト指向のことも解ってないようだな。

アスペクト指向も、オブジェクト指向と直接的な関わりは無いが、
オブジェクト指向と組み合わせることで効率よく使いこなすことができる。


現に、オブジェクト指向言語は、手続き型言語の機能を包含して
使われているようにな。

> アスペクト指向も、オブジェクト指向と直接的な関わりは無いが、
> オブジェクト指向と組み合わせることで効率よく使いこなすことができる。
>
> 現に、オブジェクト指向言語は、手続き型言語の機能を包含して
> 使われているようにな。
こういう当たり前のことを書いて、根拠もなくわかってないと
断言する。さすがOO厨房。このレベルの内容を相手が理解できない
と思っているその傲慢さ。

「相手が理解できないと思う」⇒「自分にとって難しい」
ということで、自分の知性の限界を相手に見せている。

>>563
お前がそれ言うかｗ

>>564
てへっ☆

理解してるなら是非本の1冊でも出してその
素晴らしいテクニックの数々を広めていただきたいものだよ蛙君

>>563
なにOO厨房って？
お前の脳内で作り上げた造語？

Javaのコンパイル後のクラスファイルのこのプログラムから開くってのが
メディアプレーヤーになったんだけど、デフォに戻すにはどうしゅればいいですか？

それはWindowsのファイル管理オブジェクトに対して、メッセージを送ればよいのです。

　Windows ← フォルダオプション ← ファイルタイプ ← JAR ← open ← javaw

　

多重継承の出来ないJavaなんか嫌いだ・・・・・
菱形継承も出来ないけどｗ

じゃ、お前はD言語もC#言語も嫌いなんだな

>>1
頭が悪いから。頭の柔軟性がないから。
メタファで物を考える脳みそをもっていないから。

ふふ。既存クラスを使うだけのオブジェクト指向か。。
めでてーなw

オブジェクト指向よくわかんね。
クラス使うくらい出来るが、クラスを使ってどんな構造にすればいいかわからん。
組み込み系だと、どうクラスに分けていいのか‥
汎用系ならまだわかりやすいんだがなあ‥

>>575
組み込み系だろうが汎用機系だろうが、ソフトの本質は変わらん。
最近は、デバイスドライバさえC++で書くところもある。

>>574
そういえば、最近そういうの多いよな。
それすら理解できないVB厨がうざい。
つーか、VBだってクラスモジュールってのがあるのに、それを使いこなせないVB厨って・・・

>>574 >>577
＞既存クラスを使うだけのオブジェクト指向

それも真っ当な利用形態のひとつだから仕方あるまい。
クラスを作るだけが能ではあるまいて。

じゃんけんじゃわぐそ
さつまいも
あいこで絵栗糞じゃわぶぃえむ

>>574
もともとそういうもんじゃねーの？
使い回ししないんじゃ意味無いじゃん

日本ＮＯ１プロジェクト
CreateGame〜陸海空オンライン〜
ただ今、プログラマ募集中〜♪

なんか、EclipseとかGUIでJava組んでるような奴等が増えてからJava房
のレベル低いと思われだしてるな。
会社ではC使いどもに不安定なJava(vm)を馬鹿にされつづけている。
Javaプログラマは最近俺の中でVBと同レベル。
やっぱCできなきゃ組み込みむりぽだし。

>>582
でもそこからC++には発展しないわけだ。

開発言語を後発のものに変えることを
「発展」とは呼ばないよ

W-ZERO3用のソフト開発は組み込み向けに分類されるのかな。
WindowsCEって一応組み込み用OSだよね？
これが許されるならVB.NETだって組み込み開発用言語だ。

まぁ、Javaの組込み系って普通にあるし
無理でもなんでも無いんだが

知らないことが幸せってこともあるんだよ
未開の土地に生まれ・育ち、そして幸せな人はたくさんいる

地球温暖化のカナリアがトゥルカナ族なら
コボラとC厨はオブジェクト指向のカナリアだな。

OOで効率が上がるとか信じているバカがまだ居るのか（ｗ

進歩を拒む老人がまだ生きているのか(ww

>>589
ちょっとさがせばどっさりライブラリ落ちてるんだから、そりゃ効率あがるだろ。

javaとC++が分かってれば何でも出来るんです

つーか、OOのアイディアや実装したのって年寄りなんじゃねーの？
たぶん、ここでいきまいている連中がママのおっぱいを吸っている頃にさ。
なんで、ついてゆけないのではなく、引いたレールに乗っかっているだけなんじゃね？

加工済み食材を買い集め
化学調味料を振りかけて
電子レンジで温っためただけの料理で
グルメを気取っているような…

皆さん、初めまして。
Javaを勉強しようとして、
「やさしいJava」を一通りやりましたが、
ハッキリ言って面白くありません。
Javaを勉強をする上で楽しくなってくる良い入門書は
ありませんでしょうか？

ありません。

まず自分で作りたいもの決めて、それを実現するためにはどういう機能が
必要なんだろうと調べていくタイプの勉強法じゃないと、基本的にどの本
読んでもつまらんと思うよ。

>>597
なるほど・・・漠然とした考えではダメなのですね。
ありがとうございました。

当然だろ
お前は何のために勉強するんだ？

いきなり、初対面で「お前呼ばわり」は頂けませんね。

は？
ここは2chだぞ
半年ROMってろ屑

>>601
私は2chといえど暴言や無礼はカキコしない主義なんですよ。
貴方は貴方なりの流儀でカキコしてくださいな。（わらひ）

>602
＞貴方は貴方なりの流儀で

>600
＞は頂けませんね。


なにこの矛盾
死んだら？

>>594
OOはあくまで調理法。
そこに知ったかぶりの厨どもが勝手に化学調味料
かけまくって見た目だけの別物にしてるだけ。
そしてそれを見た年寄りが材料に手を加えず
材料丸かじりしたのが一番って言ってる状態。

正直に言ってもいいか？
ぶっちゃけ俺の業界では若い奴のがOO判ってないんだがｗ
ケイやストラウストラップの論文も、もちろん読んでない。
つうか名前知らないｗどうにかしてｗ

カタカナで書くなハゲ

>>606
判ったよ、箸の上げ下げまで細かいような奴だな。
Alan Kay、Bjarne Stroustrup、William R.Cook
この辺の論文は読んどけってことでいいか？

論文なぞ読まなくても読んだことがなくても
立派な仕事をしている人は沢山いるけどね。

Ｊａｖａ叩きじゃなくてＪａｖａが勝手にＭＳ叩いて孤立したんだろ
朝鮮人にそっくり

MSが強力にサポートしない限りマイナー言語から抜け出せないんだよ
ＭＳに歯向かったJavaは、いまや使えない糞言語になってるしな

はいはいコテ共は死んでね

>>608
論文読まなくたっていい仕事してる人はいるだろうが
OO推進してる立場で読んでない人はいい仕事してないだろ

>>612
おかしくね？なんで OO は別物なわけ？

>>582
> なんか、EclipseとかGUIでJava組んでるような奴等が増えてからJava房
> のレベル低いと思われだしてるな。
> 会社ではC使いどもに不安定なJava(vm)を馬鹿にされつづけている。
> Javaプログラマは最近俺の中でVBと同レベル。
> やっぱCできなきゃ組み込みむりぽだし。

君の脳内は朝鮮人のようなお花畑が広がっているようだね。

君の妄想癖は朝鮮人そっくりだ。

>>593
一部の獄限られた年寄りだけが名な。
大部分の年寄り、しかもOOの発明者よりも若い年寄りは
ろくにOOをわかってないことがよくわかる。

>>607
その人名を知っているからと言って、OO知ってることにはならんけどな。
それ知らなくてもOO知ることはできるんだがw

>>609
その朝鮮人はいまや、C#厨やドトネト厨のほうなんだが。

で、Javaが孤立したという根拠はどこにあるの？

>>610
そんな妄想も堂々と履けるとは、流石マ板は常識のない連中顔甥ですね。

このスレでJava批判している馬鹿どもは、
↓のスレ、前スレも含めて全て最初から読むことをお勧めする。

いかにお前らのレベルが低いかがよくわかる。

JavaやるとC++は有害に感じる　int 2
http://pc10.2ch.net/test/read.cgi/tech/1171173223/

はてさて、これがその前スレだ

前スレ
JavaやったらC++はきもく感じる
http://pc10.2ch.net/test/read.cgi/tech/1168423655/

>>604
駄目だなお前は。鉄則を守れない裏切り者だ。
役立たずは追放だ

DIコンテナのことを知らない馬鹿ほどJavaを批判するw

test