OOスレ6 なぜオブジェクト指向は普及しないのか

はっきり言って、すでに普及しているオブジェクト指向（OO）。
ただ、OOを理解していない人が多いのも事実。ここはOOに関する様々な話題を討論する場所です。

過去の検討結果は以下の通りです。
・オブジェクト指向（OO）とは抽象化である。
・継承、ポリモーフィズム、インタフェースは、OOを実現する為の手段である。
・デザインパターンとは、OOのサンプル集であるが、これを暗記してもOOをマスターしたとは言えない。
・アーキテクチャパターンとは、システム設計のサンプル集だが、OOとは特に関係ない。
・オブジェクト指向プログラミング（OOP）とは、詳細設計の手法で、抽象化を使用して、クラス設計を行うことである。
・オブジェクト指向分析／設計（OOD）とは、機能設計の手法だが、明確に定義されていない。
・OOの利点は変更が容易な事、欠点は冗長になる事である。

推奨ルール
・単にオブジェクト指向と言った場合は、詳細設計分野のオブジェクト指向プログラミング（OOP）と解釈してください。
・機能設計分野を指す場合はオブジェクト指向設計（OOD）と明記してください。
・単にデザインパターンと言った場合は、GoFのデザインパターンと解釈してください。

過去ログ
part 1 http://pc11.2ch.net/test/read.cgi/prog/1183255047/
part 2 http://pc11.2ch.net/test/read.cgi/prog/1184258633/
part 3 http://pc11.2ch.net/test/read.cgi/prog/1185378099/
part 4 http://pc11.2ch.net/test/read.cgi/prog/1188396264/
part 5 http://pc11.2ch.net/test/read.cgi/prog/1189946678

おじゃば、自分のスレは自分で何とかしないとな。偉いぞ。

おお！！　このスレをはじめにおっ立てた者ですがまだ続いてたんですね。
漏れは何回かオブジェクト設計をしている仕事まで近づきましたが
結局、設計グループにはいまだに参画できません。まだ若造と思われて
いるのか、なかなか抜擢されません。技術書を読む日々が続いています。
実践をしないと実力がつかないので最近は焦り始めています。
クラス図やシーケンス図を作成している人がうらやましいです。

>>4
そんなレス....このスレシリーズで見たの何時の事だろう。
嬉し泣きしちゃうよ。

>>1
このルールを追加してくれ。

※NG推奨ワード：おじゃばさま、たかひろ関連
　これらを相手にした場合、荒らしとみなされます。

>>6
お前見たいのがいるから、荒れるんだろ。
ほとんどの奴はとっくに読み飛ばしてるのに。

・オブジェクト指向プログラミング（OOP）とは、詳細設計の手法で、抽象化を使用して、クラス設計を行うことである。

これがダメだな。

>>7=おじゃば
わかったわかった。そんなに暴れるな。
茶でも飲んでこい。

>>9
違うだろ。
相手するなって言ってるんだから。
なんで、そんな馬鹿なの？
いいか？

読み飛ばせ

お前が言ってた事じゃないのか？

>>10
だから分かったつってんのに。
もちつけ。

>>11
ええい！！
女将を呼べ！！

普及しているのはオブジェクト指向言語であって、オブジェクト指向ではない。

smalltalkとかnowい

「メソッド」と「関数」は違うと思ってる奴は
手をあげて。

上げてもいいが、それがお前に見えるかは、また別の問題だ

ノ

状況次第で言葉の本意は変わるが、というのが前置きで。

「関数」とは0個以上の引数を取って処理を行い、0個以上の値を返すモジュールとの認識。
単に「メソッド」と言われるとクラス（かそれに準ずる何か）に属し、オペレートするためのインターフェースで
クラス関数、メンバ関数以外にも、演算子、プロパティへのアクセサみたいなものも含まれる印象。

メソッドのが意味の範囲が広い？

関数って形式のことじゃね？

メソッドはクラスに対するアクセス（という本質）
関数はモジュールまたはクラスに対するアクセス（のひとつの形式）

Eiffelにはクラスに対して「手続き」と「関数」と両方の形式のメソッドがあるよな

ＯＯスレなんだが

>>18
いや。狸と狢みたいなもんで、関数の単なるSmalltalkローカルな呼び名。
それが広まっただけ。

じゃ、一緒ってことじゃん。
メッセージパッシングて一体・・・

>>22
だからメッセージングなんてＯＯ談義では無視していいんだって。
Smalltalkなんて所詮は暫定実装。アラン・ケイはErlangみたいな非同期
メッセージングを実現したくて文法とか雰囲気出したり頑張ったけど、
結局実装面では「とりあえず」が広まって定着しちゃっただけだから。

それに今主流のＯＯはビヨーン・ストラウストラップが再定義した
「“ユーザー定義型”をクラスを使って実現する」という考え方の流れを汲む
（つまり、カプセル化＝ユーザー定義型　＋　継承・多態性＝クラスの機能）から
そもそもメッセージングなんて関係ねぇし。

結論から書くと「関数」と「メソッド」は別物だと思う、俺の考えでは

関数形式には次の３つがある
・関数
・クラスメソッド
・メソッド
このうち、関数とクラスメソッドは機能的に少し似ているが
クラスメソッドとメソッドでは機能的に違うものだ、クラスメソッドを使う場面で
メソッドを使ったり、その逆も出来ない
また、メソッドと関数を比べて場合、メソッドとクラスメソッド以上に違うと思っている
こんな風に、クラスメソッドも入れて考えると、機能的・概念的違いが分りやすくなると思う

クラスメソッドは関数っぽく使いたいときもあるよね
ってことで用意されたもので、関数そのものだろ。

メソッドは個別のデータとくっついてるから、
同じように使えない場合もあるだろうけど、それでも、
やっぱり関数だよね。

クラス変数ってのがあるけど

>>4
シーケンス図は機能設計、クラス図は詳細設計の分野だ。
機能設計の分野、つまりオブジェクト指向設計（OOD）は定義が曖昧なため、修得する必要はない。
詳細設計の分野、つまりオブジェクト指向プログラミング（OOP）は、修得する必要がありますが、
クラス図生成はソースコードからの逆生成が一般的なため、コーディングをすると言う事と同義になる。

つまりシーケンス図を書かせてもらえないなら気にする必要ないが、
コーディングをさせてもらえないなら致命的だ。技術書を読む暇があったらコーディングするべきだ。

>>8
では書き直してみれば？

>>13
今では「なんちゃってC++使い」や「Javaの皮を被ったC使い」は淘汰されつつある。
つまり、言語の普及と同様にOOも普及している。

>>23
>だからメッセージングなんてＯＯ談義では無視していいんだって。
メッセージパッシングはオブジェクト指向では大事な概念だ
この重要性が分っていないなら、まだオブジェクト指向が分っていない事になると思うが

>（つまり、カプセル化＝ユーザー定義型　＋　継承・多態性＝クラスの機能）から
逆にカプセル化を、オブジェクト指向の本質的な概念だと考える人間も多いが、これは間違い
カプセル化は、オブジェクト指向特有の概念ではなく、構造化言語でも実装されていた（modular2など）
つまり、構造化の延長に有る概念（「カプセル化＝クラスの機能」は間違い）
もちろん、オブジェクト指向でもカプセル化は重要だが

メッセージパッシングの重要性を詳しく

>>28
> 「カプセル化＝クラスの機能」は間違い

いや。そりゃ、あんたの読み違いだよ。

カプセル化（＝ユーザー定義型）
　　　　　　　　＋
継承・多態性（＝クラスの機能）

つまり、クラスの機能を活用しつつカプセル化するのがオブジェクト指向だ。
とりあえず、そんな基本中の基本のところで読み違いをしちゃう28には
ストラウストッラプとメイヤーあたりの基礎から勉強しなおすことをお薦めするよ。

-「オブジェクト指向プログラミングとは何か」／ストラウストラップ
http://www.research.att.com/~bs/whatis.pdf

-「オブジェクト指向入門」／メイヤー
http://www.amazon.co.jp/dp/4756100503

クックのオブジェクト指向VS抽象データ型も追加しといて

>>29
メッセージパッシングの意味を本当に分かって使っている奴なんかまずいないから。
重要性を説明できるわけがない。何か言ってきても、俺勝手解釈を聞かされるだけで
はっきり言って時間の無駄。スルーしていいと思うよ。

一億歩譲って仮に28がメッセージパッシングの発案者のアラン・ケイだったとしても、
ここで論ずるべきＯＯとあんたの考え方とは別のものだから。そもそもお呼びでない。
つか、ケイならそこいらへんは痛いほど了解済みのはずなのでこの流れでは出てこない罠。

>>31
いや。ここでそれを出しても混乱を招くだけでしょ？

「抽象データ型」っていっても、元祖リスコフのか、そこから派生したストラウストラップのか
クックのかでも微妙に違うとかあるし…。

クックといったら、それよりも、言語機能としてのインターフェイスの考案者としてのほうが
Javaユーザーとかには重要じゃない？

ふーん。Erlangのメッセージ非同期メッセージングとやらを
ちょっと見てみたい気もする

メッセージパッシング、ってなんだ？
メソッド呼び出しって書いた方が分かるんじゃないか？

オブジェクト指向で問題なのはここらへんだ。
メソッドだろうが関数だろうが呼び方はどっちでもいいし、
意味が通じることが大事なのに、なんかこだわる奴がいる。
その結果、メソッドの呼び出しってことを
いちいちオブジェクトにメッセージを送信する、とか冗長に言いたがる。

言えてる
どうでもいいことにこだわりすぎ

>>35
単なるメソッド呼び出しじゃないんじゃねえの？知らないけど
だから俺>>34でどんなんか見てみたいって書いたの

Erlang
アーラン、ってなんか名前が凄いな。

>>35
> メソッド呼び出しって書いた方が分かるんじゃないか？

だから、「メッセージ」なんて実体を伴わない用語は無視しろと何度言えば…。
そもそも「メソッド」ってそれ自体実質を伴わないSmalltalk界隈発祥の用語を普通に
使っちゃっている時点で目くそ鼻くそだと気付けよ。「メンバ関数呼び出し」でおｋ。

OKわかった

呼び方に拘ろうが拘るまいが、うぜぇことには変わりないってことだよな
要するに好きなように呼べ、と

はぁ？
javaのコーディング標準でも使われてる言葉なのに、実態を伴わないから無視しろとかバカじゃないの？

関数とメソッドの違いなんか考えても
意味がないってことだろ。
同じなんだから。

結論

「メソッド」＝「関数」

それでいいよ
意味通じればいいんだし

ぶっちゃけ、OOで無くてもシステム開発は行えて、保守もできているから。

>>41
これだからJava厨は困るよ。世の中がJava中心でまわっていると信じている。
その「標準」ってのがそもそも実態を伴わないSmalltalkの顰みに倣っただけだってのに。
あんたらの界隈の「標準」で実質関数を指して「メソッド」言うのは勝手だけど、
聞き手は脳内で関数に読み替えるんだから、おかしな意味づけして混乱させるなってぇ話。

>>46
いいんすよ、ジャワポンだから。
言いたい放題言わせておけばｗ

>>46
いや、Cの関数とC++の関数では性質が違うのに、同じ「関数」と言う言葉を使っている方が問題だろう。
C++の関数とJavaのメソッドは同じ物だが、Javaのメソッドを関数と言う人はいないし、C++の関数を
メソッドと言っても大抵は通じるので、メソッドは標準だと言える。
まあ、Javaも勉強した方がいいんじゃね？

メソッドに対応するのはせめてメンバ関数だろう。

>>30
>継承・多態性（＝クラスの機能）
多態性は、オブジェクトの機能だが

今度はメンバ関数かよ
基地外にもいろいろいるんだな

＞＞＞C++の関数とJavaのメソッドは同じ物だが（ｒｙ
＞＞メソッドに対応するのはせめてメンバ関数だろう。
＞今度はメンバ関数かよ

単なるC++の用語だろ。

「C++の関数とJAVAのメソッドが同じ」とかありえねぇよ。
「C++の『メンバ関数』とJAVAのメソッドが同じ」なんだろ。

関数とメソッドは別物
こんなオブジェクト指向の基本的事も分らない人間が多いから
オブジェクト指向は普及しない

以上、結論が出たので終了です。

「関数とメソッドは違う派」は、なぜ違うのかその理由が
全く述べられていないのだが。

本に違うって書いてたから、とか？

>>42
>>43
>>46
functionとmethodを区別している人もそこそこいると思うし
言語には曖昧な表現でもOKな言語とそうじゃないのとが有るんじゃないかな？
特にJavaやC++は色んなコードが書けるから用語は厳密に使ったほうがいいと思う

あと言語仕様書内の用語はその言語が設計された時代の反映だから
設計者に敬意を払いつつ現代的に矛盾のない用語にプロジェクト内で言い換えて使った方がいいじゃないかな？

言語学的な背景が説明されていないので簡潔すぎる説明と思うけど
http://www.webopedia.com/TERM/M/method.html

いや。だから。メンバ関数とメソッドはどう違うかちゃんと説明してみろよ。
できるわけがないんだから。

>>54
>全く述べられていないのだが。
それが、オブジェクト指向の基本を分っていない証拠

逆に聞くが、オブジェクト指向が分っていると思っている人間で
「メソッドとクラスメソッドは同じ」と思っている人間がいるか？

そろそろ次の話しようぜ

>>57
はい。
メソッドとクラスメソッドは同じものです。
メソッドはクラスメソッドの参照です。
そして、OOに関数は存在しない。あるのはクラスメソッドのみです。
これが、真のOOです。

ムダに燃料投下すんなよ
この話題おもしろいか？

>>60
面白くないが、世の中面白いことばかりではない。
実際は面白くないことの方がはるかに多い。われわれはそんな中で活きているんだ。

面白くないと思うなら、自分で話題提供するニダ

仕事ならつまらなくても我慢するが、娯楽のネットでなんでつまんない話を無理して行うのか？
ネットや自由時間ですら、面白い事がないのか？

メソッドとはクラスで定義される型に対して行える操作を定義したものだよ。
関数は一連の手続きをまとめたもので、関数⊇メソッドだよ。

>>59
はっ？バカか？

KYなお前が雰囲気をつまらなくしてるんだろ
責任とって電卓のオブジェクト指向設計でもしてみせろよ

じゃあ次の話題を投下しようか。
「クラスって構造体みたいなもの」
是か非か？
さあ、荒れてくれ。

娯楽のネット？　なら、そんなネットに行け。
ここが楽しくないなら、楽しいところに行けばいい。簡単なことだ。
そして、楽しい話題のときに参加すれば良い。

>>63
関数とメソッドの関係はなんとなく解った
で、一つ質問、ピュアなオブジェクト指向には関数は存在するのか？

ない

どーでもいいし・・・
いつまで俺俺続けるんだよ・・・

>>70
ここはいつも俺俺なんだが....

>>68
その質問に答える前に「ピュアな」という言葉が意味するところをもう一度考えてみて欲しい。
>>68の質問の意図を邪推して勝手な結論を言ってしまえばオブジェクト指向プログラミングにおいても一連の処理をまとめる単位としての関数はありうる。

>>13
> 普及しているのはオブジェクト指向言語であって、オブジェクト指向ではない。

わからんちんはnewすればいい程度でしか考えてないしな

いるな。確かに。
「newしたら動きました（・∀・）」
とか。

結局、Java使いがSmalltalkに日和ったおかしな用語を使って混乱させるから
オブジェクト指向の普及云々はおろか、その本質にすらたどり着けない…でＦＡ？

>>72
こだわりすぎて目的を見失ってる奴の典型

俺はそんな典型、聞いたことが無いけどな

メソッド　＝　しょせん関数　が理解できないなら、もう　メソッド　＝　メンバ関数　でいいだろ。
さすがに、これなら異論があるやつはいないだろうし。

Smalltalkとかほぼ誰も使ったことの無い言語の話題が出てくること自体、違和感がある。
はっきり言えば、どーでもいい。
オブジェクト指向言語はC++、Java、おまけでC#とPHP。Rubyなんか誰も使わん。

オブスレなんで言語を絞る必要があるかないかは微妙だが、
少なくとも普及度ゼロに近い言語の話はいらんだろ。

>>77
だろうな。そうでなければあんなにどーでもいいことにはこだわらないはず。

>>72
質問の仕方が悪かったかも知れんな。
ピュアに深い意味はない。ま、感じとして、オブジェクト指向の教祖本、
あるのか知らんが、それに、関数の用語定義されているのかなという感じだ。

まだやるんか・・・・

>>79
Smalltalkをバリバリに使ったことのあるおっさんのOO論聞いてみたいな。
ここに、そん奴居ないよな。

オブジェクト指向の基本が分かると、
メソッドと関数が別物に見えるようになるんだ？

へぇ〜〜〜〜〜〜。

>オブジェクト指向の教祖本
あるよ。
クラスとは、オブジェクトとはってのをきっちり定義してあるのはもちろん
構造化設計手法の問題点から出発してオブジェクト指向開発の導出までの過程の説明が非常にわかりやすい。
っつーても小学生やど素人が読んでわかるようなもんであるわけが無いし、
もう過去スレで何回も解説したから後は過去スレ読んで探してね。

>>79
そのほぼ誰も使ったことがないSmalltalkなんかの訳の分からん用語をたいした
考えもなくパクってきただけのJavaの用語を標準と称して使うやつがいるんだよ。
まったく迷惑千万。

>>85
どうしてそういう嘘をつくかなー。

>>87
強いて言えば>>30のストラウストラップのほうが教祖本だな。本じゃないが。
カプセル化、継承、ポリモーフィズムについて初めてまとめられた文書だし。

問題は、

すでに「関数呼び出し」という言葉が浸透している中で
あえて「メッセージパッシング」などという、仰々しくかつ、
意味を直感的に汲み取れない言葉を選ぶのであれば、
それなりに意味が違っててほしいのに、
実際は何も変わりがない、

ってことだよね？

まぎらわしいこと言うなよと。

>>86
俺、よくネットからコードパクってきてるから、それ、理解できるよ
自分で作るのだるいから、在るのは使いましょうねだからな。

そうそう。それでおっけ。
だからもうその話題はいいだろ。

んだ
もうお腹いっぱい

フケ防止剤って言えば分かりやすいのに、

ミクロジンクピリチオンって言えば、なんんかスゴそうに
聞こえるのと同じだよね。

おなかいっぱいなら、だまって出て行くか、
自分でネタを振ればいいじゃん。
バカなの？

まあまあ、もちつけや

暇なときに読んで感想頼む
http://iwatam-server.dyndns.org/software/devintro/oo/oo/index.html
http://www.sra.co.jp/people/aoki/IntroductionToOOAOOD/index.htm

懐かしいの持ってきたな
曼荼羅がどうとかいうページ久しぶりに見たいと思ったら
リンク切れだった・・・

>>96
読んだ。
最初のは論外。典型的な勘違いの俺定義。
次のはストラウストラップのの単なる焼き直し。
メッセージとか出てきちゃって分裂症ぎみだけど、Smalltalk使いじゃしょうがないね。

>91
敗北宣言？

これよんで勉強しなおせよ
http://kmaebashi.com/programmer/object/index.html

資格作ればいいのになあ。
オブジェクト指向検定とか。

ほんとだね。
公式認定してくれんと、俺OO多すぎ。
このスレのOO信者の9割はOOの本質わかってないし。

>>102 「OOの本質」とは？

>>52
メンバでない関数は、Cの関数と言う扱いだ。

>>86
メソッドと言う用語は、すでにJavaやC++でも普通に使われているから標準と言える。
Smalltalkなどと言う思い出に浸る暇があったら、JavaやC++を学習すべきだろう。

まず、OOの本質がどうとか言う前に、JavaかC++かC#、それと比較対象としてCをマスターすべきだろう。
ちなみにCとC++のみが出来るという人は、なんちゃってC++使いの可能性が高い。

C++が出来ると言う事をここで定義しておこう。
・クラスが書ける
・テンプレートが書ける
・STL（string、vector、map）及びイテレーターが使える
・stream及びマニピュレーターが使える
最低でもこの4点をクリアしていない人は、C++を使えるとは言えないとする。

>>105 では、「C++でOOPが出来る」という場合の定義は？

>>104
つか、おじゃば。お前、他人には「学習すべき」とかえらそーなこと言いつつ
自身はSmalltalkなんて単純きわまる言語の読み書きもできない状態なんじゃ？

>>105
どれだけできればいいのかというのも書いてほしい。

class Person
{
};

これも一応クラスだけど、これだけじゃクラスが書けるとはいえないでしょ？

クラスとはOO志向では何を表すのだろうか。
おまいらって、こんなことも知らないでクラスとか言ってんだろ。特に>>105

改めて、クラスとは何なんだろう。おまいらの俺俺クラス定義分かり易く示してくれ。
ま、俺的にはクラス、それは、学校の教室のことだけどな。
それがOOのClassにどのように結び付くかって事は気にしないことにしよう。
気にしないことが幸せをもたらすこともある。

instance = new Class()

こういうことが出来る言語はすべてオブジェクト指向言語とみなして良い。
オブジェクト指向言語というのに必須なの最低条件

>>105
> C++が出来ると言う事をここで定義しておこう。
> ・クラスが書ける
> ・テンプレートが書ける
> ・STL（string、vector、map）及びイテレーターが使える
> ・stream及びマニピュレーターが使える
> 最低でもこの4点をクリアしていない人は、C++を使えるとは言えないとする。

その定義はまずいよ。
初期のC++はテンプレートは無かった。
STL、イテレータは無かった。

その定義だと初期のC++がC++であることを否定していることになる。

・テンプレートメタプログラミングができる
・関数型言語に精通している

・boost.preprocessorとboost.mplの独自実装を作ることが出来る

とりあえず、「俺が出来ること」を基準にするのはやめろｗｗｗｗ

もういやだ。
句読点もないひらがなだけで書かれた文章のようなソースコード。

クラスは漢字ってことか

苦羅巣

クラスとは漢字なり。

class (クラス) とは日本の男性デュオグループである。
1996年3月に解散したが、2003年再結成。
デビュー曲の『夏の日の1993』はミリオンヒットを記録した。

正直ってインスタンスが作れれば
あとはどうにでもなるよ。

OOAに関して言うとUMLとか使ってもせいぜい操作くらいで関数なんて概念ないんだけどな。
まあメンバ関数で蒙昧する程度だと下流のドカタがせいぜいだな。

ちなみにクラスはオブジェクト指向のために作られた言語機能じゃないんだよ。
もともと別の目的であったものを型の定義に使えるから流用したってだけで。

「別の目的」がなにであるかの説明が抜けている。うさんくさいなぁｗ

>・クラスが書ける
>・テンプレートが書ける
>・STL（string、vector、map）及びイテレーターが使える
>・stream及びマニピュレーターが使える

おじゃばが、一年くらいにC++の勉強した時の奴だな。

当たり前すぎるが、newとdelete等のメモリ管理をしっかり使える事も。
必要なんじゃないだろうか？

おじゃば、苦手だったの覚えているぞ。

もしかしておじゃばきゅん萌え？

いつまで、「OOはこうあるべし」論が続くんだ？
こんなの聞かされたら誰でも嫌になるわな。

お前だけ嫌になっとれｗ

そーか？俺は一票入れたいけどな〜
C屋/C++屋の見分け方としてはこれいい線行ってると思うけどなー
＋boostがある程度使えてたらすぐウチ来て欲しいよ。
メタプログラミングとかはどーでも良いです。。
あ、あと敢えて足すならC++ならauto_ptr系何か使えて欲しい。
>・クラスが書ける
>・テンプレートが書ける
>・STL（string、vector、map）及びイテレーターが使える
>・stream及びマニピュレーターが使える

>111
昔の事はどーでもよくね？

OO志向いけてる人＝UMLで話が出来る人
言語とかはどうでも良い

# OO志向マスターしつつある辺りの技術者から
# コード書かなくなってしまう現状を何とかして欲しい・・・
# 技術者にちゃんとお金払おうよ＞日本の企業
# そんな額じゃ、みんなマネージメント方面行っちゃうじゃんかー

コード書きのままいるやつなんて俺みたいに人生捨ててる人間ぐらいしかいないし

>>128

>・stream及びマニピュレーターが使える

iomanipなんてログ出力に小細工なんだから、
必要な場面で調べて使えればいいだけ。

C++の本質的能力とは無関係だな。

>・stream及びマニピュレータを自作できる

C++の激烈なところは演算子オーバーロードだろ。
開発対象に合わせて言語そのものを自在に拡張できるのがすげー。
new delete Allocatorをカスタマイズしてメモリ管理まで自在にできるようになりたい。

OOを本当に理解している人っている？

>>132
＞ C++の激烈なところは演算子オーバーロードだろ。

演算も一種のメソッドじゃないの？

オーバーロードは便利だってだけで、普通に関数で代用は出来るよな

あと１０レスはC++の言語仕様が続きます

言語仕様なら定義が明確だから、安心して饒舌に
なれるんだろうね。

その点OOはみんながみんな自分のOO定義を作りあげてるから・・・w

代用できるねで済むなら機械語スパゲティでいいわけだが

実際問題、言語仕様で話をする方が現実的なんだよな。
オブジェクト指向はこうあるべし！
と、いくら唱えても物にならんのなら技術者には関係ないし。

継承つかわずにインターフェース定義できねぇかなぁ・・・

いや、継承とインターフェースを分かってないだろ・・・

じゃあ
継承を使わずに動的多態性を得たい

だから継承じゃねーっつの

じゃあ何？

>130
確かにiomanip自体はC++の能力とは結びつかないね。(知ってても偉くない)
ただinttypes.h辺りのキモマクロとかは(環境依存を吸収する為の奴)
いかにもC的な発想に見えてしまうんだ。

105はprintf()辺りでバグ出して苦労したのかな？と、、、

>135
簡単に書けると言う事はメリットだよ。きっと。
こんなのとかは良く使われるテク
struct Foo{
Foo & operator()(int i){ return *this;}
};
// リスト内容の静的投入とかで便利
Foo foo = Foo()(1)(2)(3)(4)(5);
# あー、OO関係ねーや。。
# C++でOO入門するのはお勧めせんよ。OO以外の要素が多すぎる！
# (他で覚えて戻ってくるとキモキモチイかも)

>142
本筋では無いがー

言語依存で無理やりやるなら。
C => 関数ポインタ
C++ => template(ファンクタ渡しとか) or メンバ関数ポインタ
java => 思いつかない・・・JNIなら可
perl => 普通に出来る
php => 普通に出来る
ruby => 普通に出来る

JavaはAOPでいけるだろ

>>146
その言語はわからんが、普通にインターフェースで
多態性出来ないの？javaとか出来そうだが

ただ>>142の「”動的”多態性」の動的が分らんが
多態性は動的だろう？逆に「静的多態性」は多態性じゃないだろう

俺的には動的=コンパイル時決定ではない、と理解したが。

おまいら、多態性分って書いてる？

>>149
同意

javaで言えば、extends も implements も使わずに
多態性を実現できるか？って話なんで
JNIのロード先を切り替える位しか思いつかんなー
とおもた

まあ、当然そんな無理しなくていい

AOPでいけるっつか、普通に普及しまくってる

>>133
理解してる思ってる中から100人に１人ぐらいじゃないかな。

ぶっちゃけ、OOで無くてもシステム開発は行えて、保守もできているから。

>>154
どっち？
・ぶっちゃけ、C++orJavaで無くてもシステム開発は行えて、保守もできているから。
・ぶっちゃけ、C++orJavaでオブジェクト指向で作らなくてもシステム開発は行えて、保守もできているから。

ぶっちゃけ、C++orJavaで無くても、オブジェクト指向で作らなくても
システム開発は行えて、保守もできているから。

こだわりだろ。大切なのは。

技術>根性>ポリシー(こだわり)＞仕様

才能>技術>根性>ポリシー(こだわり)＞仕様

C++ってこういう書き方でできる？

a->value++;　　



ただしvalueの値が100を超えたら例外発生。

不可能！

>>160
出来るよ。

>>136は神

C++は永遠です
C++ってこういう書き方でできる？
a->::value++;
ただしvalueの値が100を超えたら例外発生。

おい、誰だ？
使えない新人>>164を釣れてきたのは？

a->value++;　　
できない。

a->setValue(a->getValue()+1));
とする必要がある。

>>166
それなんてJava？

世間ではOOPができるってMFCが使えると同義なんですね・・・
あとやたらclass化しすぎ
関数でいいじゃん
というか　やたらライブラリ化しすぎ
コピペでいいじゃん

といわけで私は意地でも structで行きます
グローバル変数をstructで囲むのは私の良心です

マがラクにムするのが目的だからな

多態の実現であれこれ悩むってどんだけ？

悩まず自然なコードで直感的なイメージを
表現できないのであればＯＯ指向としての
言語設計が躓いてるよ。嘆かわしい限り。

>>168
X世間ではOOPができるってMFCが使えると同義なんですね・・・

正しくは
世間ではOOPができるってJavaが使えると同義
補足
MFCはOOPの出来ないC++ドカタ用なんちゃってライブラリ
M$はOO　PGのためのC++用windowsクラスライブラリ作っても良かったのだが、
あまりにもOOの出来ないPGが多かったので仕方なくMFCを作った。
本当は.NETみたいなのを、最初から出したかったんだ。

つまり、世間ではOOPができるって.NETが使えると同義 ということだな。

m9（＾Д＾）ﾌﾟｷﾞｬｰｰｰｯ

>>173
残念ながら、.NET自体が世間ではまだ認められていません。

相変わらずレベル低い議論に終始してるな

高度な事を議論する土台として、基礎的事柄の再確認と整理と再定義(修正)を行うならともかく、
こいつらの場合２０年前の昔話を延々とエンドレスでループしているだけだから、バカとしか言いようがないｗ

>>176 もループの一部だな。

んじゃ OOPの意義は？

オッパッピー

>>106
ここではOOPが出来るかの定義以前に、言語が出来るかの定義を行いたい。

>>107
昔の言語が出来るのを自慢げに話していると、年寄り扱いされるから気をつけた方がいい。

>>108
コンストラクタ、コピーコンストラクタ、デストラクタの意味と使い方が分かって、
publicとprivate、それとstaticの意味と使い方が分かって、継承の使い方が分かる事。

>>109
クラスとはオブジェクトである。
オブジェクトとは物をプログラムで表現し、抽象化したものである。
ここで言う「物」には商品や顧客のように物質的なものから、ルールや規約のように概念的な物まで含む。

学校の教室と言うと、グループ化と言うイメージがつく。
OOに慣れないうちはグループ化の概念から入っていってもいいと思うが、OOの本質ではない。
もし強引に教室に例えるとすると、主役は生徒ではなく教室になり、その教室を運営するために
必要な設備と生徒のみを含む事になる。同じような教室や同じような生徒は必要ない。

口調がひどいのがなあ。
それが無ければ叩かれることも減るのに。

クラスと教室をかけたネタだろ
馬鹿の上に冗談も通じないって最悪すぎる

ホント人付き合いが下手そうなアホコテだな

C#にコピーコンストラクタってないの、
コピーコンストラクタってどんな目的のことするコンストラクタの？
Javaにもあるの？

>>111
初期のC++は、もはやC++とは言わない。

>>112,113
最低限の定義とする。そのためオペレーターとアルゴリズムは外した。

>>124
一年前の俺は、もはや俺ではない。

>>130
iostreamを使うと文字列や数値型を気にしなくて良くなる。
これは入出力の抽象化で、OOの本質の一つである。

>>131
それは中級と言う事で。

>>132
オペレーターは分かりにくくてお勧め出来ないが、個人的にはすごく好きだ。
自作した日付クラスなどは+-で日付演算出来るし、自作した平均化機能付カウンターはintを変更する
だけで動作する。日付やカウンターの抽象化だが、他人にはひどく分かりにくいコードだ。

>>133
俺。

全レスしてる電波が居ついてるが…何事？

ヒント：全レス粘着は２ちゃん名物。

boostを使いまくったC++はもはやC++ではない

mpl辺りは特にね。。。
ありゃシンタックスの悪い関数型言語だ

# シンタックスの良い関数型言語も少ないが・・・

>>188
え〜生STLつかうより楽でいいやん。何で駄目?

うちの場合は他のチームが読めなくなるからってことで駄目とのこと
酷いよねー、どうせ普通に書いても読まない癖にねー

>>コンストラクタ、コピーコンストラクタ、デストラクタの意味と使い方が分かって、
スタティックコンストラクタ とかファイナライザとかも増えましたね

>>190
うちも>>192同様,boost駄目
理由は標準じゃないからだとさ。
ANSIのお墨付きは何時ぐらいになるのかね

えー、じゃー、おじゃばってJavaできないの？
最近のVerのJava使っていないっていったじゃんか・・・。

それとも古いVerのJavaもJavaなの？

アホはスルーしれ
専ブラNGWordにしとけ

>>おじゃばさま
JavaってISOスタンダード言語？

個人的にはboost大好きなのだが、、

自分でプロジェクト廻す時は考えてしまう。。
どーしても、カッティングエッジ感があるよな

# バージョンによって利用可/不可がいっぱいあるんで(結果的に)環境依存になる危険が高い
# gcc2.9xなんかも含める場合は最早regex , shared_ptr 辺りしか許可できないし。。それでも微妙にI/F違うし、、

boost＝wikiで調べたけどよく分からない。ライブラリ？
カッティングエッジ感＝意味が分からない。
以降＝何を言いたいのか分からない。
総括＝スレ違い？

>>169
グローバル変数を多用する人は、なんちゃってC使いである可能性が高い。

>>184
コピーコンストラクタとは領域確保と同時にコピーされる場合に使用されるコンストラクタだ。
コードで説明しよう。
Test b = a;
もしコピーコンストラクタがないとすると、上の例ではTestのコンストラクタが呼ばれ、Testの=に
オーバーロードされた関数が呼ばれる。
普通、=の関数では内部の値を全てコピーするから、コンストラクタで値を初期化していても無意味だ。
コピーコンストラクタは、
Test b = a;
で呼ばれる特別なコンストラクタで、一般的には内部情報をコピーするコードを記述する事により、
無駄なコンストラクタ呼び出しを軽減する。と、ここまでは一般的には言われている説明だ。
ちなみにこの説明で必要性が分かったらすごい。少し考えてみるといい。

あとC#にコピーコンストラクタはない。=を自分で作って代用する。
Javaでは=でオブジェクトのコピーは出来ないため、コピーコンストラクタはない。代わりにcloneを使う。

最近のライブラリだとvcでもテスト通らないからね
でも可搬性の問題だけで導入が躊躇われるわけじゃない
それを言えばmplなんて組み込み用の貧弱なコンパイラでも使えてしまうし

>>199
＞グローバル変数を多用する人は、なんちゃってC使いである可能性が高い。
Cと言えば構造化しか無いと思ってないか？
ファイル単位でモジュール作る時はファイルスコープのグローバル変数は当たり前だし。

それと、>>169はC++の話じゃねぇの？

おじゃばよ
C++勉強するだけではなにも作れんぞ、言語仕様なんて理解できて当たり前じゃねえか
過去のたかが2bit操作するのに、くどくどとしたコードを書いた
おじゃばの基本脳内思考が1年を経たからと言ってスマートになったとも思えんがな

>>199
C#で=のオーバーロードは出来ないよC#もcloneをつかう

>>202
> 過去のたかが2bit操作するのに、くどくどとしたコードを書いた
詳しくｗ　晒してみてｗ

このスレを読むと何で普及しないのかが良く分かる
議論のための議論をしているだけで、物を作ろうとしない

>>199
グローバル変数をstrutで囲むとグローバルでなくなるんだけどね

OOの復旧もなにも
Windowsって一応オブジェクト指向だから
定着はするよね？

>>206
>グローバル変数をstrutで囲むとグローバルでなくなるんだけどね
スコープはどうなるの？

>>194
仕事で最新のバージョンを使っていないと言う話で、最新のバージョンが使えないという話ではない。

>>196
ISO？JavaはISO関係ないんじゃないか？
ISOはレガシーCの方だろう。

>>201
そんな当たり前は知らん。誰が当たり前だって言ってた？先輩か？
それとも職場で普通に使われているから、当たり前だと思ったのか？
あとstructはCの文法だ。

>>202
俺は実践派。本で得た知識より、デバッカを動かして得た知識の方が多い。
スマートな202に質問がある。istringstreamでsetwマニュピレータを使うにはどうすればいいかと、
ifstreamでファイルロック掛ける場合はどうすればいいのか教えてくれ。
ついでにstringをtrimするスマートな方法も教えてくれ。

>>199
マルチスレッドになると部分的にはファイルスコープなグローバルに頼らざるおえなくなる

>>208
structはC#の文法なの。しらないの？
へー、JavaってISOスタンダードじゃないんだ。おれおれ言語レベルなんだね。

>>210 C++だって最近だろｗ

>>211
最近って何時なの？　去年か今年？

>>208
＞ISOはレガシーCの方だろう。
意味分からん。
なぜわざわざ「レガシー」を付ける必要があるんだ？

＞そんな当たり前は知らん。誰が当たり前だって言ってた？先輩か？
＞それとも職場で普通に使われているから、当たり前だと思ったのか？
んなら、お前さんはC言語では情報隠蔽とかやらんのか？
クラスに近い形のモジュールをファイル単位で作るなら、
staticなグローバル変数を使うのは
クラスでメンバ変数を定義するのと同じようなもんだろ。

＞あとstructはCの文法だ。
CのstructとC++のstructは文法違うんだけど。

206 名前： 仕様書無しさん [sage] 投稿日： 2007/10/02(火) 12:21:45
>>199
グローバル変数をstrutで囲むとグローバルでなくなるんだけどね


207 名前： 仕様書無しさん [sage] 投稿日： 2007/10/02(火) 12:57:44
>>206
>グローバル変数をstrutで囲むとグローバルでなくなるんだけどね
スコープはどうなるの？



てんけいてきなじさくじえんを見てしまったｗ

>>213
>CのstructとC++のstructは文法違うんだけど。
知らなかったYOOOOOOOOおおおおおおーっ
どう違うのか教えてください、先生、お願いします。
>>おじゃば、先生の説明を聞こうではないか。

>>208
おじゃば、過去のJava
つまりJavaのようなもので開発していると暗に認めたとみなすぞ。

１：初期のC++は、もはやC++とは言わない。
を否定するか
２：過去のJavaはJavaでは無い
そのことを論理的に否定しろ。

それぞれ断絶があるわけだからな。

>>215
とりあえずC++のstructはメンバ関数作れるよ。
コンストラクタとかデストラクタもあるし、
プライベートメンバの宣言が出来たり。
あとtypedefしなくてもタグ名だけで変数の宣言が出来たりとか。

C++のstructはほとんどclassと一緒のようなもんだ。

つか、>>213をバカにしたいのか、おじゃばをバカにしたいのか、
それが素なのか、ドレだよｗ

C++のCはC89規格とは別物です
サブセットなんて嘘です

>>217
便乗質問、なんでほとんど一緒のclassとstructがある理由は何なの？
で、なんで、structじゃなくclassのほうばかり使われるの?
>>217さんがなんちゃってC++使いじゃないなら簡単でしょ。

>>216
あなた駄目な人なの？　>>207は僕なの。最後が'の'のレスは僕なの。
実は>>207の質問に答え知らないんでしょ、どうなの？

>>136は超神

で、OOの話はどこいった？
アホコテにつられまくりなのはオブスレデフォルトだな。

　　　　解説しよう。


　　　　現在常駐している人物はDDJ連載常連で、


　　　　当時から国内C++言語仕様策定に関与していた


　　　　エピステーメー氏(やはりDDJ連載常連)に


　　　　激しいライバル意識を持っている、


　　　　そう、また彼なんだ。


　　　　俺らからすると、C++薀蓄なんてジジィ趣味もいいとこなんだがｗ

「これって・・・」
「そう、構成要素に違いはあるけどこの発言パターンは基地外に酷似している。面白いでしょ？」

>>219
＞ なんでほとんど一緒のclassとstructがある理由は何なの？
＞ なんで、structじゃなくclassのほうばかり使われるの?

本音じゃstructってCと似たような書き方が出来るようにしただけだろ、と思ってる。
多分建前は「classはカプセル化されたオブジェクト」で、
「structは複数のデータを1つに纏めたもの」って位置づけなんだと思う。
デフォルトのアクセス指定が、classだとprivateで、
structだとpublicな辺りからの想像だけども。

＞ >>217さんがなんちゃってC++使いじゃないなら簡単でしょ。
俺はなんちゃってC++使いだよ。

おじゃばよ
ここはもっと上流工程のレベルを語る所だ。
なのになぜお前は低層コードレベルの頭しかないのだ。
1年前よりも退化しているようだな。

このスレで特定の言語の構文の話をするのはおかしいと思うが、
上流とか低層って分け方はくだらんな。
アジャイルだと、コードこそが設計。
アジャイルが優れているかどうかは別問題だが、今時当然のようにそういう分け方すんのはどうかと思うぞ。

アジャイルはバラックの掘っ立て小屋を建築する手法
その場しのぎの最低レベルを満たすものしか作れない

>俺は実践派。本で得た知識より、デバッカを動かして得た知識の方が多い。
おじゃばよ
おいらに質問するならば、まずデバッガなんて幼稚園の遊具のような物は
使わないようになってからだなっ

>>227
突っ込みたいトコだが、スレ違いだと思うので黙っておく。

>>225
おじゃばって下流担当のコーダーみたいだから、
上流工程なんてやったことがないじゃね。
だから、OOPLしか語れないしデバッガーうんぬんの実践の話になる。
C++に関しては、C++メインのプロジェクトやったことすらないかも

>>230
去年、C++はひまだか新しい業務だかで勉強してその結果を披露していたわけだが。

>>210
CとC++の話をしてたのだから、C#が出てくるのはおかしいだろう。
あと「JavaはISO標準じゃないからマイナーな言語ですよね。」とは他人には言わない方がいいよ。

>>213
CとC++では各社の仕様対応状況が違うからだ。

同じような物でもCではやらん。別の言語の作法を持ち込むのは、「なんちゃって」の特徴の一つだ。
213がクラスのフィールド変数と同じだと思ったから、自分だけ当たり前のように使っているだけだろう？

あれはC++独自のstructじゃなくて、CのstructをC++風にしてあるだけ。だからC++では使うな。

>>216
古いか新しいかの問題ではなく、標準的に使われているかの問題だ。
今はCはISO、C++はSTL、Javaは1.5が標準。ちなみに俺はJava1.6も知っている。

知識自慢のはずが絶妙な雰囲気を醸し出してしまうこの表現力は唯一無二
並のエンジニアにこんな文章は書けない

>>224
なんちゃってを認めたなら、馬鹿にされないように前述のC++使い条件をクリアするんだな。

>>225,230
現役で上流とか下流とか分ける人って、痛い人だよ。マジ、指さして笑われるぞ。
営業や経営者ならそういう人いるが、多くはコーディングも設計も出来ない偽コンサルだよ。
本物の設計者は、提案から設計、製造、試験、保守まで出来る人を言うんだよ。

>>228
な、何！！
じゃ、何を使うと言うのだ？

>>230
根拠のない決めつけは良くな。分析力も全然ない。
俺が設計や提案、C++メインのプロジェクトをやった事がないかは、発言をみれば分かるはずだ。
俺が230より下であって欲しいという、230の願望しか見えないな。現実を見ろよ。

>>234
ログを使ったデバッグ。
マルチスレッドプログラムはデバッガー使ってあれこれするよりも、
スレッド毎にログ吐き出してリアルタイムの状態検証した方が
早い場合がある。

まあ、その辺は古いJavaだと気にしないですむか。


ついでに、216に対するレスで、規格とライブラリーと言語のVerを一緒くたにしてる事に
気がついているか。

無論使えそうな機能が正義でそれを標準であるという気持ちはわかるが。

さようならOO・・・
君の事を理解してくれる人は居ないようだ・・・

まあ、頑張ってどこまでも言語の話をしててくれ諸君

>>234
>俺が設計や提案、C++メインのプロジェクトをやった事が"ないか"は、発言をみれば分かるはずだ。

この文って読んですぐにあれって思ったよYo
おじゃば、世の中おじゃば見たいに頭良い香具師ばかりじゃないんだぞ。
これじゃ、ないということを誘導してるみたいだぞw（きっとないだろうが）
そしてな、誘導したいのならより自分の利益になるな言葉のみ使うんだよ。つまり"あるか"をな。

国語テスト下記の文の感想を述べよ
俺が設計や提案、C++メインのプロジェクトをやった事があるかないかは、発言をみれば分かるはずだ。
俺が設計や提案、C++メインのプロジェクトをやった事があるかは、発言をみれば分かるはずだ。
俺が設計や提案、C++メインのプロジェクトをやった事がないかは、発言をみれば分かるはずだ。

実戦ではログもデバッガも必要だよ。デバッガ「だけ」、ログ「だけ」しか知らない奴は馬鹿
まぁ、OOとは何にも関係ないけどな

>>238
忘れちゃ困るのがあるぞ。つ　研ぎ澄まされた頭脳・勘
実はこれが最も大事だ。
デバッガやログが使えてもね.....だろ
>>238　デバッグがんばれよ

おれはこう思う。
デバッガやログよりも、デバッグという行為そのものが必要だ。と。
スマソ愚痴スレいくわ。

以降OOスレにてデバッグ論がアホコテの釣りにより
１０レスは続けられる。
つかおまぃらいい加減気がつけよ。

完璧な設計で、完璧に実装できたらデバックなんて必要ないよ
問題は、不完全な人間が完璧な設計と完璧な実装ができるかということだが

そんな些細な問題はOOが普及しないことに比べたら取るに足りない問題だね

>>235
高広発見

なんかさ、デバッガ叩きしてる奴って、
典型的に自分で手は動かせねぇコンプで
話題そらすだけのクズに見える。
まぁデバッガの話題出した奴もクズだから、
クズどうし仲良くペロンペロンちゅぱちゅぱ傷を舐めあってて下さいって感じだけど。

>>233 ﾜﾛｽｗ
気軽に文章かいててもスキルは滲み出すもんね。
おー、いろいろ経験つんでんな、ってやつならそういう文になる。

おじゃばよ
オブジェクト指向と関係ない話ばかりすな

>>232
＞今はCはISO、C++はSTL、Javaは1.5が標準。ちなみに俺はJava1.6も知っている。
・・・？

＞　C　+　+　は　S　T　L　
・・・？！

とりあえずおじゃばがC++を知らんことは分かった。

もうJavaとかC++なんてどうでもいいからCLOSの実装について語ってくれよ

>>235
なんだ、「デバックはprintf()とか言いたいのかと思った。」
あと、デバッカを使うと言うのは単体試験の事だぞ。マルチスレッドでも単体試験はデバッカで
チェックした方が早い。結合試験は235の言う通りログでやるのが普通だが。
つーか単体試験、やらない人じゃないだろうか？

>>237
別に誘導なんて関係ない。どう表現しようと”やった事あるか、知ってるか”の事実は変わらないのだから。

貴様らって普段何言語で俺俺OOをしてるんだ？　
ISOスタンダードじゃないJava
ISOスタンダードのC#　
爺用C++
よく解らんが希望の星Haskell
その他の奇怪な言語

smalltalk以外のOOPLは糞

と糞が喧嘩を売って来ました。
さて、糞OOPL使いの貴方はこの事実を認め降参しますか？

降伏しまーす（´；ω；｀）

>>242
いや逆だろう。
OOが分からない人がいると言う事は、試験をしない人がいると言う事に比べたら、
取るに足らない問題だろう。

>>244,246
少し話題がそれても気にするなよ。幅広い知識があれば問題ないだろう。

>>247
規格とライブラリとバージョンを同列で言うなと言いたいのかな。
まあそれが分かると言う事は、247もある程度は知っていると言う事になるな。
しかし本当に詳しいなら、何でそういう表現になったか分かるはずだがな。

>>248
いやどうでもいいのはCLOSで、実装について語るべきなのはC++だろ。

>>250
OOはJavaかC++。
両方か、どちらかを知っていなければならない。(must)

>>254
>>251-253より
下記のように訂正汁
OOはsmalltalk
これを知っていなければならない。(shall)

ここで華麗にrubyが登場

>>254
>少し話がそれても気にするなよ。
話をそらしてしまったことを認めたなら、開き直らずに素直に誤ればよいのでは。。。？

>しかし本当に詳しいなら、何でそういう表現になったか分かるはずだがな。
初心者も見ています（私もそうです）。もったいぶらずにその「何で」を述べて見たらどうですか？

>>257
スルーしろ。

Javaとか(特にC++は)は構造化プログラム言語の影響を受けている打算と妥協の産物
OOPが分からんと言っている人間はこの構造化プログラム言語の特有の「手続き」
が透けて見えてしまうことが原因だと思う

特に「プリミティブ型」はオブジェクト指向とは相容れない
これを許してしまった時点でJavaもC++も本物のOOPLでは無くなった

本当に良いものは普及しない。
庶民に迎合した妥協とマーケティング戦略と偶然でその言語は普及するかしないかが決定される

ま、本当に良いものは普及しないにしろ、生き残るだろうな．．．
C#, Javaは今後10年、生き残るだろうか？
特にJavaは10年生き残って見せたが、それは「バージョンアップ」という
延命措置を施されただけであって、本当はもっと前に死滅していないだろうか？
C#は、Windows以外の環境で動かせるのだろうか？
昔のVBみたいに、ある日絶滅させられないだろうか？

俺は預言者ではないが少なくともsmalltalkは20年以上生き延び、
そして、あと10年以上は生き延びることを予告しよう

>>259
「Smalltalk」のつづりも分かってないやつが何か言ってるが、
Smalltalkを使った開発など、どこで見れるんだ？

>>258　了解です。

中途半端な妥協品が生き残るだけだと思うんだがな。

中途半端な妥協品は生き残らない
別のより良い中途半端な妥協品に食われるだけ
例えば、今はWeb系ではPHPが流行しているが、以前はPerlが流行していた
また、AjaxはJavaScriptが前提条件としてあるが、
何もブラウザがサポートするのがJavaScriptだけである必要性は無い

今のPHPと同様に、JavaScriptより便利な妥協品が流通したら
JavaScriptは死滅するだろう。そもそも、JavaScriptってブラウザやOSで
あまりにも挙動が変化しすぎる

良いものは残り、それ以外のどうでもいいものより良いどうでもいいものに淘汰される
まぁ、お前らはどうでもいいものを作っている、どうでもいい人間であるなら別に構わない
どうにでも好きなようにして、糞言語で作った糞プログラムを思う存分ばら撒くがいい

なんとなくだが、Cが生き残ってるのと同じ理由でC++は生き残りそうな気はする。
ネイティブなコード吐くOOPLで有名なのって、他に何かあったっけ？

>>260
＞Smalltalkを使った開発など、どこで見れるんだ？

http://smalltalk.cincom.jp/scripts/smalltalk.dll/customer/applicationw.ssp
http://squeak.preeminent.org/tut2007/html/index.html

デルファイ

Cが生き残ってる理由が知りたけりゃOS書いてみりゃすぐわかるよ。
最近じゃOSを作る情報はいたるところにあるし、一回やってみなよ。
それがわかればC++がJavaやC#に駆逐されない理由もわかるかもよ。

本家サイトでよけりゃ、Eiffel開発だって見つけられるYO

>>264

でるふぁい。

・・・まあ基本的に無い。

環境の為の環境を作らないネイティブなコードは強い。
それを認めないのはなぜなのか不思議だ。

ランタイムを入れる努力をしてまで新規のフリーソフトを導入するヤシ
は少ないというのは当たり前の現実なのに。

だが、VBは「昔は」流行した
JavaはMSがサポートしなくなったからワカラナイ
そして、今はOSすら仮想化されてしまう世界

偽者は流行することができるだろうが本物は生き残る
まぁ、逆説的に言えば生き残れない言語が偽者だ

凡人には見分けが付かないだろうけどな

本物偽者ってレッテル張りも古いけどね。60〜70年代かよって感じか？
少なくとも優良種が生き残るわけではないってことは歴史を見れば明らか

>>259
> 特に「プリミティブ型」はオブジェクト指向とは相容れない
> これを許してしまった時点でJavaもC++も本物のOOPLでは無くなった

んなこたーない。「オブジェクト指向」が意味するところによるよ。
抽象データ型のＯＯなら、新しい型がクラスを介して定義できればプリミティブ型が
あろーがなかろーが関係なし。
メッセージングのＯＯや、そこから派生したプロトタイプベースＯＯだと
純粋さに欠けるって言われて駄目かもしれんけど。


> 俺は預言者ではないが少なくともsmalltalkは20年以上生き延び、
> そして、あと10年以上は生き延びることを予告しよう

10年って安全すぎ。ここの誰もが死に絶えた後も生き残ってるよ。
つか、Smalltalkに限らずいったんオプソになったら殺す方が難しい。
とくにSqueak SmalltalkなんかVMすらSmalltalk自体で書かれて公開されているわけだしさ。

>>272
> んなこたーない。「オブジェクト指向」が意味するところによるよ。
で？君の定義は？俺の定義は
　「オブジェクトとはデータ型の最小単位」
つまり、生物は細胞の集合体であるように、オブジェクト指向とは
従来の「プログラム＝データ構造＋アルゴリズム」ではなく
「プログラム＝オブジェクトの集合」に他ならない
これは君にとってはあまり重要ではないかもしれないが、
少なくとも私にとっては重要な意味を持つ
# この定義によるとリアルなウィルスは細胞を持たないため、
# ウィルスは生命でないということになる

> ここの誰もが死に絶えた後も生き残ってるよ。
オープンソースだから死に絶えないとでも？
SourceForgeを眺めたことがある人間なら最低限の譲歩でも
「死んでないだけ」の誰も見向きもしない糞プロジェクトなど星の数ほどある
そして、誰にも保守されない言語は思ったよりも多い
例えばalgolとかB言語は既にラテン語やエスペラント語の域に突入しているような気がするぞ

>>273
> で？君の定義は？俺の定義は

あんたの俺定義には興味は無いわけだが、

> 　「オブジェクトとはデータ型の最小単位」
> つまり、生物は細胞の集合体であるように、オブジェクト指向とは
> 従来の「プログラム＝データ構造＋アルゴリズム」ではなく
> 「プログラム＝オブジェクトの集合」に他ならない

これを読む限り、ケイのメッセージングのＯＯの流れだね。
そういうことならプリミティブ型がＯＯと相容れないというのは判る。
でもJavaもC++もその手のＯＯをサポートするようには作られていないから
272は単なる言いがかりってことにもなる。

Smalltalkで抽象データ型のＯＯを完璧にサポートしろったって、無理があるだろう。
それと言っていることは一緒だってったら分かるかな？

>>273
お前は自身の目耳に届かないことは、存在しないのと同じと信じ込むタイプだな。

定義とか原理に傾倒することってホントに意味ある？
まあ、あるのかも知れないけど実利的な側面から一切トピックが
挙がってこないこの現状は異常というほかないよ

抽象データ型のＯＯ、メッセージングのＯＯ、プロトタイプベースのＯＯくらいの区別は
あってしかるべきだろう？　それぞれ互いに共通項こそあれ、相容れない部分も
多々あるわけだし。２０年来延々と繰り返された宗教戦争の類も結局は互いへの無理解
というファクターも無視できない。

抽象データ型のＯＯで「クラスがオブジェクトじゃない」とか言われても困るし、
メーッセージングのＯＯで「型安全じゃない」とか言われてもキョトンとするだけだし、
プロトタイプベースのＯＯで「インターフェイスが定まらない」とか言われても笑うしかない。

おじゃばよ
頼むから「C++やってるぞ」みたいな顔しないでくれ
お前はジャワが似合う

定義を明確にしないから様々な誤解やすれ違いが起きてきているのではないのかね？
政治家じゃあるまいし何故曖昧なままにしておきたがるのがが逆に理解できない

Unicodeという理念にUTF-8やUTF-16というアプローチ方法があるように
オブジェクト指向という理念にも複数のアプローチ方法がある
俺の独断と偏見によるとオブジェクト指向という理念に一番近いと感じるのがSmalltalkだ
異論は認める。

だが、どう考えてもオブジェクト指向に手続き型言語の影が見えるC++/Javaは邪道に見える
なお、俺はオブジェクト指向がプログラムを作る上で常に最高の解だとは思っていない
手続き型言語、オブジェクト指向型言語、関数型言語
それぞれ得意な分野があり、苦手な分野がある

まぁ、それを無分別に何でも１つの言語で解決しようとすると
PerlやJavaやC++みたいな変な言語になるわ
そして、もっと便利な何かの言語に駆逐される

100年の言語
http://practical-scheme.net/trans/hundred-j.html
彼（ポール・グレアム)は重度のLispマニアだが言っていることは正しい

要するに、「オブジェクト指向」っって言葉自体に複数の解釈というか、タイプがあるということかな？
素人の俺には>>277の前2つがイメージされる。

ttp://squab.no-ip.com:8080/mosaren/22
ここではほぼ2つに絞れると言っているが、、、

C++みたいに演算子オーバーロードがあると、演算子もいわゆる「メッセージ」の一種だと解釈してしまうが間違いだろうか？

どうでもいいが、ストラウストラップって人も色々な名前で呼ばれとるな。
上のサイトでは「ビアルネ」だそうだ。ビヨーンだったりビヤーンだったりするのは見たことあるが...
wikipediaだとビャーネ・ストロヴストルップになってる。

オブジェクト指向が理念って、意味わからん
たんなる簡易スキーマだろ

便利に使える環境が無きゃ、全く存在価値がないもの

つまりね。
オブジェト指向を構成する要素は人によって様々だから、
人によって言語を自由に拡張できるLispが最強ってことだよ。

>>259
遅レスだけどC#とCLIはJIS化されたんでそう簡単にはなくならない（というかなくせない）
と思うよ。まぁほんとにC++の次世代規格になるかは別だけど。

>>279
プログラミング言語は、オブジェクト指向他の設計思想を実現することが目的じゃなくて、
問題解決するのが目的だから、
＞まぁ、それを無分別に何でも１つの言語で解決しようとすると

問題なし。

>>280
本人の生の発音聞くとビョーン・スッポスッポにしか聞こえない

>>285 本人の発音を聞いたことあるのが裏山視す

>>284
趣味の世界なら問題ないけど、仕事だとコストっちゅーか生産性っちゅーか
その辺の観点から問題がある場合がある。

うん、プログラミング言語は問題解決をすることが目的だ
そして、その解決方法はできるだけ統一的でシンプルであることが望ましい
最近のハードの性能向上や最適化はかなり性能に問題があるコードでも何とかしてくれる

そして、一つの解として「プログラムとはオブジェクトの集合である」としたSmalltalkがあり、
もう一つの解として「プログラムとはλ計算である」としたLispがあり、
別の解として「プログラムとはデータ構造＋アルゴリズムである」としたCなどの手続き型言語がある

そして、あくまでもC++やJavaはどんなに言いつくろっても「手続き型言語」であり、
# 百歩譲ってもクラス指向言語だな
これらのいわゆる「モジュール」の定義を拡張しただけの言語を指して
「パラダイムシフト」だのと呼んで欲しくない

パラダイムシフトとはSmalltalkやLispなどのプログラムの定義を根底から覆すものであり
昔の構造化プログラムであった「プログラムは順接、分岐、繰り返しで表現可能である」
とし、「gotoを使わなくともプログラムは書ける」としたダイクストラ以上のインパクトが必要だ

納期に追われて今あるツールが最善であるかどうか吟味できない可哀想な人は可哀想な末路を辿る
もちろん先ほども言ったとおり、その問題を解決する最適な手法はもしかしたら手続き的な方が良い場合もあるし
λ算法の方が適切かもしれない状況があることは否定しない

純粋でなければ駄目、なんて難儀な

やっぱSmalltalkerさんがでてこないと締まらないな。
このスレにこういう人がくるの、遅すぎたくらいだ。
煽りでも釣りでも皮肉でもなんでもなく、ワクテカだ。

>>290
いやこのSmalltalk信者はまだなーんも突っ込んだ話してねーぞ。
クラス指向ってバカにしてる時点でクラスを中心にしたボトムアップ設計の利点を理解してるかどうか怪しいし。

まぁ、それはこれから語ってもらいましょ。
OOPを語らせるには一番熱持ってるはずだから。
そういう点で、他の言語の人とは違い、期待を持ってしまう。
Objective-Cの人が来たら、もっともっと嬉しいけど（個人的に）。

>>280
まぁ、アランケイのオブジェクト指向とストラウストラップのオブジェクト指向が有名だな
# 個人的にはストラウストラップのオブジェクト指向は「クラス指向」と呼びたいが
そして、クラス指向では「委譲」をどうするかで揉めているがそんなことはどうでもいい
本論に入る
> C++みたいに演算子オーバーロードがあると、演算子もいわゆる「メッセージ」
> の一種だと解釈してしまうが間違いだろうか？
クラス指向ではメッセージとメソッド呼び出しと等価で
C++だと少なくとも2項演算子はa @ bという演算子は
a.oprator@(b)かoprator@(a,b)のシンタックスシュガーに過ぎない
あくまでメソッドであり、メッセージとは微妙に異なる
あえて言えば「本物の」オブジェクト指向のメッセージも
クラス指向という名で呼ぶべきオブジェクト指向のメソッドも
「何かに情報を伝達すもの」という機能としては変わりないが
その、意味論的な事に関しては昆虫の羽と鳥の翼ほどに構造としては別物だ
例え、それが機能として「空を飛ぶ機能」を持つからと言って
羽と翼を同じとは思って欲しくない
海に存在すれば魚類と鯨は同じだろうか？
その問いに何の意味があるのかと思う人間はプログラミングに向いていないし、
そもそも人間であることに向いていない。
獣のように与えられた仕様を実装して満足していればいいのだ

さて、私は多少酒が入ってるので酔っている。破綻しないうちに結論を言おう

「本物の」オブジェクト指向では演算子など存在しない
演算子もオブジェクトで表現可能なので必要ないのだ
が結論であり、本物でないオブジェクト指向など知ったことではない！

コンピュータにできることって、
・計算
・データの保存／検索
・時計
・並列処理
・表示
・音を鳴らす
・通信
ぐらいのもんだろ。ちょっと計算の早い単純な機械なんだよ。
なのにおまえらときたら、散らかった部屋を片付けもせずに、
掃除機使うかモップにするかでぐだぐだ悩んでる。
どんだけ夢見てんだよwww

部屋が散らかりすぎててデカすぎたら、悩む価値もあるだろｗ
むしろ、そんなときのための掃除機やモップだろｗ

>>293
言いたいことがよくわからんが、とりあえず
>知ったことではない！
で締めちゃったら話がすすまんだろｗ
せめてクラス指向のこれこれこーいうとこがダメで、
メッセージ指向だとこう解決しますよって話にしてくれんと燃料にもならん

>>294
> コンピュータにできることって、
略
> ぐらいのもんだろ。

それぐらいしかできないものを、複雑に組み合わせて
それ以上のものを実現しようとしているから
悩むわけだよ。

>>293
オブジェクト指向を「飛ぶ機能」に例えているなら、
その実現方法が虫の羽だろうとトリの羽だろうとどちらも本物だろう。と思いますよ。

魚と鯨もちがうが、泳ぐ機能はおなじだし、見た目だけなら結構似てる。
そして進化の過程が違うというだけで「どちらが本物の泳ぎ方」と決めつけることはできないよ。

>>294
モップと掃除機、もっというとホウキと雑巾もあるが掃除するという目的はいっしょでも
掃除する場所が違えば選ぶ道具も違う。絨毯をモップや雑巾で拭かないでしょ。


オブジェクト指向と他の指向を比べたときに>>293的な違いなのか>>294的な違いなのか、
もっと他のたとえ方があるのか。この辺の見解からして人それぞれって感じですかな。

OOPとOOP以前で考えると、一次元増えてる。
平面的だった整頓方法に、三次元的なやり方ができるようになった。
三次元的に散らかってしまい不満を言う奴もいれば、
大きくて複雑な散らかりを恐ろしくスカッと整頓してしまう奴もいる。

>・通信

これだけで実装はどれだけあるのやら・・・。

>>280
>要するに、「オブジェクト指向」っって言葉自体に複数の解釈というか、タイプがあるということかな？
解釈というか、「オブジェクト指向」と名の付いた複数の考え方があるということ。

> 素人の俺には>>277の前2つがイメージされる。
最初はそれでいいと思う。
プロトタイプベースのＯＯはJavaScriptとかを使わないなら当面は無視していい。

> ここではほぼ2つに絞れると言っているが、、、
プロトタイプベースのＯＯはメッセージングのＯＯから派生的に生じたものなので。

> C++みたいに演算子オーバーロードがあると、演算子もいわゆる「メッセージ」の一種だと解釈してしまうが間違いだろうか？
ＯＯを抽象データ型のＯＯだと思っているなら（たとえば、カプセル化・継承・多態性がＯＯの
基本…）なら間違い。メッセージングのＯＯが好きで、あえてC++を使ってそれを実践して
いるなら間違いではない。けど、よほどの理由がないかぎり、C++にメッセージングのＯＯを
サポートさせようとすること自体が間違いなので（C++はそれ向きには作られていない）、
C++を使うのをやめたほうが幸せになれると思う。

>>279
> 俺の独断と偏見によるとオブジェクト指向という理念に一番近いと感じるのがSmalltalkだ
それは、279がこれぞＯＯと信じるものがたまたまメッセージングのＯＯで、一方でSmalltalkは
他でもないメッセージングのＯＯをサポートするために（暫定的にではあるけれど）作られた
言語・環境なのだから、当たり前。

だからといって、メッセージングのＯＯをサポートすることを想定していないC++やJavaに
難癖を付けるのはお門違い。C++やJavaは、C++やJavaなりの「抽象データ型のＯＯ」という
「メッセージングのＯＯ」とは別の独立した考え方に従って、それをサポートするように
作られているし、その役割をちゃんと果たしている。すくなくともSmalltalkがこのＯＯにおいて
C++やJavaに勝ることはない。シェアは如実にそれを示している。

これまでメッセージングのＯＯが培った手法や技術の類には優れたものがあるかもしれないけれど、
いかんせん現在の主流が「抽象データ型のＯＯ」である以上、結局は「抽象データ型のＯＯ」に
投影できない手法や技術は、世間には認められないのもまた事実。
メタプログラミングしかり、リフレクションしかり、デザインパターンしかり、ＸＰ・テストケース・
リファクタリング・アジャイルしかり…。

>>298
>>293の「飛ぶ機能」に例えてるのは「オブジェクトに情報を渡す機能」でそ。
メッセージとメソッドはどちらも「情報を渡す機能」だけど、別のものですよ、ということかな？

>>293
結論が一番意味分からん。
＞a.oprator@(b)かoprator@(a,b)のシンタックスシュガーに過ぎない
は、まぁそうだろ。その上で
＞メソッドも「何かに情報を伝達すもの」という機能としては変わりないが
で、この辺りまで言いたいことは分かるんだけど。

その上で結論で出てくるのが
＞演算子もオブジェクトで表現可能なので必要ないのだ
なんでこうなんの？

「『何かに情報を伝達するもの』という機能」はオブジェクトで表現可能ってこと？
SmallTalkでの整数演算"1 + 2"はオブジェクト"1"に"+"というメッセージを送って
その引数は"2"という意味の記述だそうだけど、
「"+ 2"という情報を"1"に伝達する機能」はオブジェクトとして表現出来るのか？

「メッセージとメソッドは違う」というところをそうとして上の2個目の質問はスルーでも良いとして
ちょっとSmallTalkについて聞きたいのだけど、「演算子はオブジェクト」と言うことは
"+"というメッセージがオブジェクトなの？
ていうか、SmallTalkでいうところのメッセージもオブジェクトって扱いなのか？

>>303
ご指摘ありがとう。確かにそうかいてあるね。

>>301
丁寧なレスありがとう。
javascriptは仕事で少々つかってる。(でも使い切れていないのは自覚してる)
そうか、それがプロトタイプベースなのか。
C++もまだ勉強中なんで、メッセージング云々を意識したわけじゃない。
「C++らしい書き方」ができれば良いかなとは思う。(OOを理解したいという欲求はある。多分必要だと思うし。)

いずれにしろその「複数のオブジェクト指向」はそれぞれを使っている人はそれなりに理解して使っているんだろう。
（つまり普及してはいる。）
一方ですべてを理解して使いこなせて(使い分けられて)いる人が少なくて、派閥争いみたいになっちゃってるのかな。
（分かってないヤツが多いと言う発言）

こんなところが、このスレを読んだ今のところの感想。

OOPなどプログラミング・パラダイムは、あくまでコンピュータにやらせたい何かを
コンピュータも人間もなるべく困らないように表現するためのスキームであって、当然
コンピュータ側にも人間側にも妥協点が存在するはず

原理主義者みたいに、それを哲学として捉えてみたり
Cしか知らない爺さんみたいに蔑んでみたりするのは
どちらも正しい態度とは思えない

ああ、メンドクセ、改行が多すぎるだと？
>>298
> オブジェクト指向を「飛ぶ機能」に例えているなら、
> その実現方法が虫の羽だろうとトリの羽だろうとどちらも本物だろう。と思いますよ。
ああ、「飛ぶ」という機能に対して言えばどちらも実装できている以上、
要件を満たしている上では間違いではない。
だが、俺が言いたいのは同じ機能であっても実装方法が違うという意味だ
羽と翼は実装方法が根本的に異なるだろ？
昆虫に翼を実装できないし、鳥に羽を実装できないだろ？
で、じゃあ羽と翼は何が違うのか？
羽に出来て翼に出来ないこと、翼に出来て羽に出来ないこと
という疑問が発生するかも知れないが．．．残念俺の知識不足だ
その疑問に今の俺は答えられん。

>>302
ならば混乱しないように「クラス指向」というべきだ
全く設計思想が異なる言語を一括りに扱わないで頂きたい
モジュール指向を拡張しただけの本質は「手続き型」である言語は
区別されるべきだ
> メタプログラミングしかり、リフレクションしかり、デザインパターンしかり、ＸＰ・テストケース・
> リファクタリング・アジャイルしかり…。
これは全部Smalltalkからのパクリ、特にSmalltalkはデザインパターンの宝庫だ


何というか、初めてPostScriptを見たときの奇妙さは理解しているつもりだ
アレは今でも(多少Lsipが読めるが)違和感がぬぐえない

>>303
> ちょっとSmallTalkについて聞きたいのだけど、「演算子はオブジェクト」と言うことは
> "+"というメッセージがオブジェクトなの？
> ていうか、SmallTalkでいうところのメッセージもオブジェクトって扱いなのか？
ええと、少し説明が悪かったかもしれない
「演算子はメッセージで表現できる」が正しいかもしれない
1 + 2という表現はSmalltalk上では
"1"というオブジェクトに"+ 2"というメッセージを送るということになる
#　もう少し正確に言うと"1"がレシーバ、"+"がメッセージセレクタ、引数が"2"
# 多少の御幣があるかもしれないが「メッセージ＝メッセージセレクタ＋引数」だ

>>305
> コンピュータ側にも人間側にも妥協点が存在するはず
だからその妥協点は
・全てをオブジェクトの集合で表現する
・全てをλ計算で表現する
・全てをデータ構造＋アルゴリズムで表現する
の(俺が知っている中では)３点に絞られていると認識している
そして、それらの用語は正しく使われるべきであり、
JavaやC++という「手続き型言語」は
「オブジェクト指向言語」と呼ばれるべきでないと思う

どちらかというとケイのをメッセージ指向って呼ぶ方向じゃないの？

言語とパラダイムを1:1でバインドするのはいかがなものか
ネマールとかどうなるのよ

人間に蜘蛛の足が生えてたら、そら気持ち悪いわなぁ。

>>303
> SmallTalkでの整数演算"1 + 2"はオブジェクト"1"に"+"というメッセージを送って
> その引数は"2"という意味の記述だそうだけど、

こまかいことですが、1 + 2 は、1 への「+ 2」というメッセージの送信と解釈します
（メッセージは「+」ではなく「+ 2」、ということ）。ちなみにメッセージ「+ 2」のうち、
「+」がセレクタで「2」が引数です。つまり、メッセージはひとつのセレクタと
ゼロ個以上の引数からなる、ということになります。さらに便宜上セレクタは、
メッセージの送信の結果、コールされる（…ことが期待される）メソッド名と一致します。
したがって、1 + 2 では、1 の属する SmallInteger に定義された + という名前の
メソッドが引数として渡された 2 を伴ってコールされます。

> 「"+ 2"という情報を"1"に伝達する機能」はオブジェクトとして表現出来るのか？
Smalltalk はここいらへんがいい加減というか妙なところで現実的というかで、実装上は
たんなるメソッドの動的な呼び出しをしているだけで、実際にはメッセージは送って
いません（ただ例外として、メソッドが見つけられずそのコールに失敗したときに、メッセージに
含まれる前述の情報である「セレクタ」と「引数」をラップしたメッセージっぽいオブジェクトが
自動生成されることがありますが、これはメッセージングが意味するところとはほど遠い
ものなのでここでは無視していいでしょう）。

ではメッセージをちゃんとメッセージ（オブジェクト）として実装している言語はないか
というとそんなこともなくて、古くは、メッセージングのＯＯの影響を受けて作られた
ACTOR という言語（これは、メッセージングのＯＯから派生したアクター理論に基づいて
作られました）では、メッセージもちゃんとオブジェクト（ACTOR ではアクターと呼ぶ）で
表わされていましたし、最近の言語なら Io という言語で、同じくメッセージは
実体のあるオブジェクトとして内部的にも表現されている、という例があります。でも希有です。

繰り返しになりますが、こういうところは Smalltalk は建前ばかりで、中身はいいかげんです。

どれもシミュから発展したものとは全然主旨がズレテるところが笑えるよね

>>303
> ちょっとSmallTalkについて聞きたいのだけど、「演算子はオブジェクト」と言うことは
> "+"というメッセージがオブジェクトなの？
> ていうか、SmallTalkでいうところのメッセージもオブジェクトって扱いなのか？

セレクタの実体はシンボル（インターンされたイミュータブルな文字列）なので
オブジェクトといえばオブジェクトですが、それ（と引数との組み）をメッセージと
呼んでもいいかと問われると、293とは違い、私個人的には甚だ疑問です。

>>306
> > メタプログラミングしかり、リフレクションしかり、デザインパターンしかり、ＸＰ・テストケース・
> > リファクタリング・アジャイルしかり…。
> これは全部Smalltalkからのパクリ、特にSmalltalkはデザインパターンの宝庫だ

もしかして日本語不自由？

これらはSmalltalk（メッセージングのＯＯ）発祥だけれども、C++やJavaのやり方（抽象データ型のＯＯ）で
実現する方法が考案されるまでは、その価値が広く一般に認められることはなかったということ。

>>308
そこはお互い様ってかんじだね。

ケイがゴールドバーグ風に「メッセージ指向」とＯＯを言い直すか、
ストラウストラップやメイヤーがＯＯの再定義のときに「クラス指向」と言い直していさえすれば
こんな混乱はなかったはず。

>>312
ズレているというか、もともとのSIMULAの思想と各ＯＯとは、直接の関係はない。
そもそもクラスやオブジェクトは SIMULA で疑似並列処理のために作られた言語機能で、
後のＯＯとは縁もゆかりもない機能。

「抽象データ型のＯＯ」の発案者であるストラウストラップは二つのうち「クラス」に目を付け、
これを抽象データ型の宣言に使えると気づいて C 言語に取り込ませることで C++ を作った。
（抽象データ型というのは簡単にはユーザー定義型のこと。今はカプセル化と言う場合もある）
前後するけど他方で「メッセージングのＯＯ」の発案者であるケイは、メッセージの媒介者として
「オブジェクト」が利用可能だと気づいてこれを拝借し（紆余曲折あって、結果的には「クラス」も
使うことになったけどこれは副次的）てSmalltalkを作らせたってだけ。

余談だけど、SIMULA自身はその後、「抽象データ型のＯＯ」のほうに傾倒した進化の道を選んでいる。

>>304
> javascriptは仕事で少々つかってる。(でも使い切れていないのは自覚してる)
> そうか、それがプロトタイプベースなのか。

プロトタイプベースのＯＯの本質はスロット（C++風にいうところのメンバ変数やメンバ変数）を
オブジェクト単位で（つまりクラスを介さずに）自由に脱着できることです。参考まで。

> C++もまだ勉強中なんで、メッセージング云々を意識したわけじゃない。

ならば「メッセージ」とかは忘れた方がいいです。動的なメンバ関数の呼び出しは
動的なメンバ関数の呼び出しで、それ以外のものではありません。

> 「C++らしい書き方」ができれば良いかなとは思う。

メッセージングを意識した場合と、抽象データ型を意識した場合とでは、書き方は
がらりと変わることがあります。メッセージングにこだわらないのであれば、まずは
データ型とはなにか、で、そのデータ型というものを言語ユーザーが定義できることの
メリットは何か、クラスはそのためにどんな機能を提供してくれているのかといふうに
調べてゆくと、望むものに近づくことができるはず。

ともあれ、SmalltalkかぶれやメッセージングＯＯシンパ崩れの戯れ言に惑わされないことです。

昔話に花が咲いてるが、
そんなもんは

何　の　役　に　も　た　た　ん

モジュールの内部設計するオブジェクト指向はクラス指向だと思うんだが、
モジュール間の通信はクラス指向じゃないよな。コンポーネント指向と言うべきか。
出来上がったプログラム同士の通信の段階ではメッセージ指向で考えるし。

〜〜指向、〜〜指向、〜〜指向
そりゃ初心者はうんざりするわな

おー。へ理屈屋がなんか頑張って暴れてるな。

ここ５年位の間に、OOスレで語りつくした話を
今更のように連投してくる、スレ初心者っぷりが
なんだか初々しい・・・

＞プロトタイプベースのＯＯの本質はスロット（C++風にいうところのメンバ変数やメンバ変数）を
＞オブジェクト単位で（つまりクラスを介さずに）自由に脱着できることです。参考まで。

この辺の話の出自ってどこ？
読みたい

あと、初心者さんに良いアドバイスをしてあげよう。

ここでいつもグダグダ言ってる奴、こいつは
元豆蔵の社長だよ。(豆蔵ってのは、自称「オブジェクト指向コンサルティング」の会社。)
数年前に豆蔵辞めて、それ以来２ちゃんに住み着いて、
延々と同じ話をする電波状態が続いている。

こいつ結局バカで自分の話しか理解できないから、
結局の所、良い議論をしても荒しをしかけるだけ、
人の時間浪費するだけ。

まあ、バカは一切相手にせず、
知識自慢だけの無駄なレスも一切無視し、
論点が明確な議論に専念するのが一番ってこった。
がんばれよｗ

>>322
実装方法そのものズバリの話を「出自」とか言い出すバカっぷりに萌え萌え

>>322
FireFoxのソースひっくり返したら、JavaScriptエンジンのソースあるだろ？
あれ読んどけ

>>324
それを本質だってする話はどっから来たかって聞いてるんだろ
ハゲ氏ねよ

> 古くは、メッセージングのＯＯの影響を受けて作られた
> ACTOR という言語（これは、メッセージングのＯＯから派生したアクター理論に基づいて
> 作られました）では、メッセージもちゃんとオブジェクト（ACTOR ではアクターと呼ぶ）で
> 表わされていましたし、

へぇ〜へぇ〜へぇ〜
Actorの元ネタがメッセージングOOだなんて話、初めて聞いた。
するとActorの元ネタPlannerはどーゆー扱いになるんだよ！

単に、よく似た発想が同時多発的に各所で生まれ、
独自の発展(今回の話はPlanner→Actor→Scheme。前２chに書いた)をしてる、
それだけの話じゃないかな。

あと、メッセージング指向OOで忘れちゃなんねぇーのは、
　　OMG CORBA
　　SOAP
系統の話だろ、やっぱ

ちなみにSOAPの元ネタは、正確には
　Web＋MOM (Message Oriented Middleware)＋分散オブジェクト指向
くらいの感じかな。

>>326
動的OO言語の一つでも自分で実装してみれば、
それ(プロトタイピングOOの実装方法)は誰でも簡単に思いつく、
一つのOO実装のバリーエーションに過ぎない事がわかるはずだ。

そして優れた言語仕様屋が居れば、
その実装を、首尾一貫して矛盾のない「言語仕様」へと昇華する事ができる。
実際にそれやった最初の言語が、Self。

そんだけの話。

>>321
スレ初心者さんの元ネタが２ちゃん過去スレだったりしたら、
すげぇ哂える

>>327
元レスのOO唯我独尊理論っぷりは、
元豆っつうより、日本三大OO尊氏の誰か
という感触がしないでもない。(あるいはその弟子系統かｗ)

日本三大OO尊師って、誰の事だよｗ

つ　COM
こいつの立場は？

CORBAやSOAPは疎結合なので密結合が前提のOOでじゃないんじゃないの？

疎結合メッセージングOOって事でありだろｗ

密結合メッセージングOOだなんて、
オーバーヘッドでかいだけで意味なしに聞こえるけど、
あんたの中ではそれもアリなのかなｗ

ミッションクリティカルなシステムの一つも実装してみせたら、
Smalltalkを少しは認めても良い気になるんだが…。
それまでは純粋なOOで品質が上がるとか信じられん。

ただの関数呼び出しであっても、
それがSOAPなら、パケット送信しているわけで、
概念的には、関数呼び出し＝メッセージ送信 とみなして良いではないか。

>>333
一応マジレスすると、COM＝MS版コンポーネント指向CORBA。

OMGのリチャードソーリーおじちゃんが、
「CORBA作る時、MSくん誘ったんだけど、途中で抜けて自分勝手なの作り出したからチョーむかついた」
つってたｗ

そこまで行くと、コンポーネント指向になるからな。

>>337
まぁキミの思い込みに基づく同一視など、
瑣末過ぎてどーでもいい話だ。

メモリ非共有並列計算なら、ネットワーク経由のデータ転送＝メッセージングが必須だろうね。
メモリ共有型並列計算なら、データ本体は共有メモリに書き込んで、形式だけメッセージングだろうね。

前者が、あんたの言う疎結合
後者が、あんたの言う密結合

だろ

Smalltalkの話題なんか、なんの意味があるのかさっぱりだ。
ここは歴史の勉強スレか？

>>339=言葉遊びしかできない激烈バカ

>>340
だから、そこで現実の実装を持ち出してくるから、ややこしくなるんだよ。
実装をどうするかは別問題。

概念的にはメッセージ送信で良いんだよ。

>>332
H生田師
A木師
あとはUCBerkeleyの彼かな

>>343
だから、お前の脳内概念だどどーでもいいんだ。
適当な発言して、OO初心者騙すな。
お前が騙すから、世の中にバカが増えて困る

>>322
正直、S/N比が低くて出自といわれると困るんだけど。読み取ることが可能な文書は以下。

まずは、SELF のオリジナルペーパーの「Power of Simplicity」 。
http://www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/self/self.html

「“唯一無二”オブジェクトのサポート」あたり。このころはまだメッセージングのＯＯから
派生したばかりなので、メッセージング臭を取り除きながら読み進めないといけない。
（メッセージングは、プロトタイプベースＯＯでは本質ではないので後に取り除かれることになる）

あと（本質ではないけど便宜的特徴である）「クラスがないこと」、それでどうして
困らないのか、具体的にはメッセージングのＯＯにおける（抽象データ型ＯＯでは違う。為念）
クラスの役割である「メソッドホルダ」と「インスタンス生成器」としての機能をどうやって
代替するかにかなりの紙面が割かれているので、これもスルーしていい。なぜなら、
クラスがあってもプロトタイプべースオブジェクトの本質が失われることはないから。

一気に時代を下って、メッセージング臭を完全に払拭できたあとの文書ならこれ。
http://developer.mozilla.org/ja/docs/Core_JavaScript_1.5_Guide:Class-Based_vs._Prototype-Based_Languages

ご多分に漏れず委譲ベースであることの説明が大部分だけど、「# 1.3 プロパティの追加
と削除」というところに当該記述をみることができる。

あと（ちょっと高価な）書籍になるけど、「A Theory of Objects」。
http://books.google.co.jp/books?id=4xT3LgCPP5UC

プロトタイプベースのオブジェクトについて書かれた「4 Object-Based Language」の章、
p37 に「The dynamic modification of the behavior of individual objects is a unique
property of object-based languages.」というくだりとか。以上、参考になれば。

まぁあれだよな。
ソフトウェア・アーキテクチャみたいな工学分野で、
実装無視の理論構築なんて空理空論もいいとこだよな。

実装無視したいなら、社会科学分野へ移動しろってこったｗ
実際IT業界の半分は、工学屋・理学屋ではなく
実装に関して空理空論しかできねぇ社会科学屋だったりするわけだがｗ

メッセージ送信っていうと、普通は意味通じないわな。
TCPのこと？とか普通思うし。

「オブジェクトにメッセージ送信」
完全に、「はぁ！？」だよな。

こんなこと言ってる限りは普及もへったくれも無いわ。

>>346
Self論文すらこのスレ来るまで知らなかったような素人が
一体何必死になって論文引用してレスしてんだよ？

いみふめ

>　正直、S/N比が低くて出自といわれると困るんだけど。読み取ることが可能な文書は以下。
>
>
> まずは、SELF のオリジナルペーパーの「Power of Simplicity」 。
> http://www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/self/self.html


なんだよ中学生か。
ググって自慢げにコピペしてんじゃねぇーよバーカ。激烈バカだなこいつ。
「オリジナルペーパー」とか言い出す時は、お前自身がペーパー読んで、
その上で議論しろバーカ。

おまえ大学もでてねぇバカだろ

>>345
反論したいのなら、ちゃんと言葉で反論しな。

そうじゃないんだよ。ちがうんだよ。
これ言うだけなら小学生にだってできるし、
だから、お前の言うことは信用されない。

> SELF のオリジナルペーパー
> http://......nagoya-u.ac.jp/.....

ﾜﾛﾀ

そっかぁ〜
Selfの人、最近は名古屋大に来て、日本語でHP作ってるのかぁ〜

勉強になります。ｗ

>>327
> へぇ〜へぇ〜へぇ〜
> Actorの元ネタがメッセージングOOだなんて話、初めて聞いた。
> するとActorの元ネタPlannerはどーゆー扱いになるんだよ！

Planner は Actor を実装するためのプラットフォームで Actor Model それ自体とは
関係ないって Hewitt も言っているんだが…。

そもそも、Acotor Model の論文「Actor Induction and Meta-evaluation」
http://www.cypherpunks.to/erights/history/actors/actor-induction.pdf
のケイや Smalltalk への謝辞の部分とか読んだことあってそれを言っているの？

どうでもいい話してないで
仕事しろよ。

>　あと（ちょっと高価な）書籍になるけど、「A Theory of Objects」。
>　http://books.google.co.jp/books?id=4xT3LgCPP5UC

これまたピンポイント過ぎてﾁｮｰ哂える引用だな。
あんたその本、どこで勉強した？
俺が２ちゃんで紹介して以来、その本何回引用した？

やっぱ　スパ　か。萎え萎えだな

つか、SELFってなんだよ。
実際の業務に関係すんのか？
関係あるなら挙げてくれや。

>>356
お前こそ、俺が書いたのみて、知ったんだろうがｗ

http://www.google.co.jp/search?hl=ja&rlz=1T4GGIH_jaJP223JP223&q=%22A+Theory+of+Objects%22+site%3A2ch.net&lr=

2ch.net での "A Theory of Objects" の検索結果 1 件中 1 - 1 件目 (0.33 秒


をっさん「ついに大学をクビになっちゃいました」お前らな、
「A Theory of Objects」(Abadi & Cardelli共著)やるからｼﾞｶﾞｼﾞｻｰﾝやめろと。
研究所ってのはな、もっと殺伐としてるべきなんだよ。 基礎論専攻の奴といつ喧嘩が始まってもおかしくない、
刺すか刺されるか、そんな雰囲気がいいんじゃねーか。 ...
natto.2ch.net/math/kako/1012/10127/1012798441.html - 37k - キャッシュ - 関連ページ - メモをとる

なんかさぁ、大学でアフォ学生相手にｾﾐﾅｰやってるみたいで
萎える展開だなぁ。

あそこにアレが書いてある、ここではコレを言っている、
それはこっちも承知済なわけで、
じゃぁお前はリンクと要約書く以外に
議論に対してどんな寄与ができんのよ？

そこんとこよく考えて発言頼むわ

なんかさぁ、大学でアフォ学生相手にｾﾐﾅｰやってるみたいで
萎える展開だなぁ。

あそこにアレが書いてある、ここではコレを言っている、
それは俺も知っている。

知っているというだけで、何も発言しない。

うん。俺も知っている。

>>354
ほぉーほぉーほぉー。
このスレで唯一ピンポイントでその話だけ、初めて知らない話出てきたわｗｗｗｗ
Lisp＆Sceme＆数式処理大好きなおいらですら、無視してたそんな謝辞、
よく覚えんなアンタ

尊敬するよｗ

まあ、そんなこと俺も知っているしな。

なんやわからんけど学生ばっかやな

>>359
ちなみにそれ書いたの当然俺だし

知っている話が出てきたら、そんなこと知っている。
知らない話が出てきたら、それはそれで罵倒する。

低脳なやつだなｗ

結局、知っていても知らなくても、
相手を罵倒するだけの終始するんだなｗｗｗ

おまぃら２人、もういいからもちつけ。

いや、>>354みたいに、どーでもいい謝辞を必死になって読み出して心に刻んでるバカは、
なんとなく好きだなぁ。

実際、Actor〜Schemeの流れと、OOなんて、俺の中で分離しちゃってるからなぁ

>>364
> なんやわからんけど学生ばっかやな

論文とか出てきた時点で気づけよｗ

論文がすべての世界で、
実戦経験がないんだからな。

話も論文上のことだけで終始する。
それもどこどこに書いてある。
そんなこと知っている。
これだけの繰り返し。

俺のなかじゃ分離してないけどな

>>370
池沼はすっこんどけｗ

こっちゃ平日はバカ行員相手の仕事で酸欠状態なんだ
休みの日くらい暴れさせろｗ

>>371
そーゆーOOに一途なアンタの行き方、
10年に一回くらいは尊敬に値すると感じるよ、高広

まあ、実際、論文がどうとかいっているやつに限って、
これ↓の自称上級プログラマに当てはまるんだけどなｗ

> ちゃんとしたプログラマであれば、これを実行するプログラムを2分とかからずに紙に書き出せるはずだ。
> 怖い事実を聞きたい? コンピュータサイエンス学科卒業生の過半数にはそれができないのだ。
> 自称上級プログラマが答えを書くのに10-15分もかかっているのを見たこともある。

http://www.aoky.net/articles/jeff_atwood/why_cant_programmers_program.htm

>>374

　　論文の一つもよめねぇ池沼はすっこんどけ

>>373
また高広きゅん萌えかよｗ
ここが荒れる原因はやっぱりこいつだなｗ

>>375

読んだだけで、実力がないだけの池沼はすっこんどけ！

とりあえずバカは完全スルーで
もうちょっと突っ込んだ話頼むわ高広

でもさぁ、よく考えたら
ActorとOOの関係なんて、今更過ぎて俺も忘れてたくらい古い話なわけで、
その話題を事あるごとに２ちゃんで繰り返すコイツも、どーかと思うな。

結局何が言いたいの？メッセージングOOについて

タカヒロってだれ？

>>340
>メモリ非共有並列計算なら、ネットワーク経由のデータ転送＝メッセージングが必須だろうね。
>メモリ共有型並列計算なら、データ本体は共有メモリに書き込んで、形式だけメッセージングだろうね。

>前者が、あんたの言う疎結合
>後者が、あんたの言う密結合

疎結合・密結合ってそんな意味合いだっけ？

>>379
> ActorとOOの関係なんて、今更過ぎて俺も忘れてたくらい古い話なわけで、

だからこいつは論文馬鹿といわれてるんだよね。
実務経験があればもっと現実に即した話をしているはず。

荒れてるなあ

>>380
タカヒロ = 数ヶ月前に他スレで暴れていた人
タカヒロきゅん萌え = 関係ないこのスレで未だに粘着している人
　　　　　　　　　　　　自分の気に食わない発言を見ると「お前タカヒロ？」が口癖
　　　　　　　　　　　　憎さあまって、タカヒロのことが忘れられず常に目の前に浮かぶらしい。

また、タカヒロか！

はいはい、みなさん。
今日いっぱいは荒れますから良識のある方は避難しましょう。

>>381
俺の汁範囲では
「密結合メッセージングOO」「疎結合メッセージングOO」といった類の概念振り回す人間は、
お前が最初だ。ｗ

×また、タカヒロか！
○また、タカヒロきゅん萌えか！

タカヒロなんて幻ですよ。
タカヒロきゅん萌えにはそれがわからないのです。

メッセージングは普通、疎結合だよなぁ

>>387
>>340の間違いだろｗ
密結合、疎結合という言葉を最初に使ったのが誰か検索してみな。

結局、密結合か疎結合かの違いしかないということ？
じゃあ、関数はメッセージと同じようなもんだな。単に結合の度合いが違うだけで。

>>373がタカヒロって言ってしまったため、
タカヒロきゃん萌えだということが露呈してしまったな。

んでさ、ここで「Smalltalk」を「SmallTalk」とかイミフメな表記せずに
昨日長文書きまくってた彼はどこに行ったのさ？

ただの大文字小文字に突っ込むバカ

>>393
ちょっと突っ込んでみたくなるｷｬﾗだよな
10月の土曜日に２ちゃんで真面目に長文書く人なら
真面目な議論をするに値するような予感がしなくもない

長文書いてた彼、この砂漠状態のスレでは
なかなか貴重な人材だ。次に機会があったら議論しよう。
よろしく。

>>395
ありがとう。でもあなたがタカヒロきゃん萌えなら突っ込まなくいい。

>>390
お前は、密結合メッセージングOOなどという
現時点では無用の長物に過ぎないものに固執しているから話がややこしくなる。
もし密結合メッセージングOOという形式に、なんらかの価値があると考えるなら、
それをここで示せ。
密結合メッセージングOO＝通常のメソッド呼び出しOOなどという腐った話は、みな暗黙の了解としているんだよ。

あとこの文脈で密結合、疎結合というのは、
並列計算/分散計算における処理と処理の結合の仕方に関する話だよ。
そしてメッセージングは、疎結合並列計算の一手法。

>>397
いや長文真面目レスに、いみふめ長文レスで絡んでいたお前じゃなくて、
まともな話ができる風の奴の事。

>>346、一見まともな人間ぽく見えるんだけどなぁ。
引用ネタが全部、２ちゃんレベルで既知だから、
判断つかねぇなぁ

>密結合メッセージングOO＝通常のメソッド呼び出しOOなどという腐った話は、みな暗黙の了解としているんだよ。

これくらいは了解しているが。

>あとこの文脈で密結合、疎結合というのは、
>並列計算/分散計算における処理と処理の結合の仕方に関する話だよ。
>そしてメッセージングは、疎結合並列計算の一手法。

なんでここに飛ぶのか不思議だ。

単にリファレンス探して引用するのが早い人、それだけだろ >>346発言の価値は。

>>401
マジレスすると、それはあなたが並列計算/分散計算とオブジェクト指向の関連についてよくご存知ではないからです。

おそらくConnectionMachine〜分散オブジェクトが立ち上がった1980年代後半〜1990年代前半に、
全然別の仕事をしていたから、その間のシーンの盛り上がり具合をご存知ないのでしょうね。

>そしてメッセージングは、疎結合並列計算の一手法。

補足すると、IBM MQシリーズみたいなメッセージングキュー(MOM)は、
並列計算弱め、システム間疎結合が主目的の代物だね。

なんかさ、つりあわない能力の奴が、能力以上の口を利いて古臭い既知の情報を探り出そうとしてる姿が浮かんできて、萎え萎え

>>357
JavaScript の元ネタな言語。
JavaScript 使わないんなら無視していい。

このスレは、既知の情報を掘り返すだけではなくて、
これから実現すべきこと、
誰にとっても既知ではない新しい事柄を皆で暖めて育てていく場
にしてほしいもんだね。

2002に２ちゃんで最初にAJAXネタを振った時、
俺はそれに専念する時間がとれなかったし、
あと誰でも知ってるネタだと思ったから、
あえて２ちゃんでそのネタを振って、
２ちゃん上でそのネタが育つのを楽しみにしていた。

(まぁ実際はその書き込みなんてほとんど影響力を持たなくて、
２年後位にGoogleに移籍した元IE4.0開発者が、その仕事をやっちゃったわけだけど。）

なんかさ、そういう、今世の中には出てなくて、技術者の頭の中、ソースの断片にしかない存在、
そーいったものを共有しながら育てていく、そんな場がここに設定できたら、おもしろいんだけどね。
(他で育てる余地があれば、わざわざ２ちゃんなどでネタ振りしないけど。
それができない物だからこそ、２ちゃんで匿名でネタ振りするわけで)

>>407
学生にむちゃいうなｗ

やつらは、どこどこに論文があった。とかいう
論文発見隊でしかないんだからｗ

>>408
またそこで判った風に見当違いな事言い出す・・・あわれ

おやおや、図星でしたかｗ

いまあるIT企業のいくつか(MS, Google, Yahoo)が、
学生ベンチャーとして始まった点、
実際にベンチャーを起こせる奴は限られている点、
を考慮しても、なお、IT分野の大きな革新における「学生さん年齢層」の果たす役割は
決して無視できない

また的外れな話をする。
論文発見隊にベンチャーなんかできるかよｗ

要するに>>408=410は激烈バカ決定

どーせおまえ、学生が考えた技術で急成長したベンチャーに株投資して
日々の生活の糧を得ている乞食ヒッキーなんだろｗ

すごい妄想家だなｗ

真偽の不明な昔の話なんてしても仕方がないでしょう。
「オブジェクト指向」は90年代で消滅しており、
今では名前だけが残ってます。

たかひろきゅん萌えが来てたのか？

↑減らず口利くだけで頭がバカな奴

たかひろきゅん萌えと言われて反応するのは
たかひろきゅん萌えだけだろうな

最近タメのMBAでおもろい奴に会って
仕事の面倒見てもらってたんだが、
ボロクソな状況になりながらも何か良い手はないか
次々と策を打ち出す様はなかなか壮観だった。

そのガッツを良い方向に生かせないものか？などと思いつつ、
でもいいエネルギー貰えたよ。
「人を信用する」というと言うだけは簡単だけど、
そのためにどれだけの労力をつぎ込まなくては「信用している」状態を継続できないか？
そーんな当たり前の事に気付きつつ・・・。

お前らまずこっから自分のオブジェクト指向にあてはまると思う奴をチョイスしろや
話はそれからだ

1.カプセル化 - 型の実装を構文的に隠蔽できること。
例えばCやPascalでは何かが構造体であるか配列であるか常に意識することになるが、
CLUやJavaではその違いを隠すことができる。

2.保護 - 型の使用者がその実装をのぞくことができないこと。
これによって、ふるまいさえ変えなければ、
実装を変更しても型の使用者に影響を与えないことが保障でき、
またパスワードのような情報が漏れ出さないようにすることもできる。

3.アドホックポリモルフィズム - 関数やパラメータつきデータ構造がたくさんの異なる型の値をとることができる。

4.パラメトリックポリモルフィズム - 関数やデータ構造が任意の値 (例：任意のオブジェクトのリスト)に対してパラメタライズできること。
MLとLispはこれを持つ。Javaは非Objectな型のために、これを完全に持つとは言えない。

5.全てはオブジェクトなり - 全ての値はオブジェクト。Smalltalkでは真だが、 Javaでは (int等のため) 真ではない。

6.メッセージを送ることだけができる (All you can do is send a message, AYCDISAM) = Actorモデル - オブジェクトを直接いじることはできず、それと通信する、もしくはそれを起動することのみができる。
Javaにおけるfieldの存在はこれに反する。

7.仕様継承 = サブタイピング - ふたつの異なる型で、一方の型の値がもう一方の型の値として使われても型の正当性を破らないことを言語が保障できるようなもの。(例: Javaのインタフェース継承)。

8.実装継承, 再利用 - ひとまとまりのコードを書いたら、それと似たコード (そのスーパーセット) が制御された方法で生成できる。
つまりコードをコピーして編集する必要がない。
制限された、特殊な抽象化である。 (例: Javaのクラス継承)。

9.「関数の積和(sum-of-product-of-function)」パターン - オブジェクトは (実質的に)有限の簡単な名前の集合から選ばれるキー引数を第一引数に取り、それによってメソッドを呼び出す関数として動作する。

>>420
まず言いだしっぺの、お前が答えろや。

答えたあとで、それは違う。と根拠なしに罵倒されるのはいやだからねｗ
そういうやつは説明を求めても、ぐぐれで自分の意見を言わないのが落ちだし。

アンケートして、それで何か新しい物が生まれるでもなく、
可も無く不可も無く、どーでもいい

.>>420
誤ったものの考え方：「オブジェクトの本質は何か？」
ちょっと幼い考え方： 「世の中の事象を、オブジェクト指向で表現する上で、何が必要か？」
正しいスキルの考え方：「オブジェクト指向の性質として何を選択したら、今後オブジェクト指向は生き延びる事ができるか？」

>>420
使えるものは何でも使う。
それがオブジェクト指向であるかどうかなんてどうでもいい。

>>420
6かな、これ以上でもこれ以下でもなし、オブジェクト指向においてこれ以外の項目は全て枝葉末節
ただし、どう考えてもこれだけでは不十分なので、強力なコーディングにはジェネリックプログラミングや関数型の考え方の追加の必要あり。

オブジェクト指向かどうかで言えば、
オブジェクト指向に必須なものなんてほぼない。

ただ、それで仕事ができるかといえば、
もっと多くのものが必要。
それだけの話だ。

>>420
1
2
3
4
5
6
7
8
9

ポリモルフィズムとか言ってるやつ。痛いんです。
polymorphism

>>428
Rubyのまつもとさんなんかもポリモルフィズムって言ってるよ。

誰も使わないRubyだからな。
OOとは違うが、ガーベジコレクションをガベージとか言ってるやつも多いし、
英語わかんねーなら無理に使うなと。

>>430
俺もガベージって言ってる（´；ω；｀）
charをチャーって言ってる（´；ω；｀）

ポリモルフィズムは原音に近いよ

発音までも俺俺か

こういう文献の統一感のなさも敷居を高くしてる要因。
多態性や多様性とか、聞いたこともないような言葉でしか表現できない＝とっつきにくい。
どうしてこう、「分かる言葉で表現する」ということがOO関係者は苦手なんだろう。

それでは↓で>>434 が多態性についてわかる言葉で説明します。

ここはキーワードのチラ見せだけウマい人が多いスレですね

>>436
その方が興奮するみたいです

>>430
別に英語じゃなくて、単なる外来語だからな。

メールじゃなくて、メイルな。正式の発音に近いのは。

garbage collection
これのどこが英語でなく外来語なのかがさっぱりだ

>>440
スルーしれ
自分で調べることすらできないアホが数匹紛れてるらしい

多態性＝同一関数名定義

こっちの方がまだわかる。

目的と手段がごっちゃになってる感があるな

そうそう、うまく動けばなんだっていいんだよ。

って発想しかできない人はマジで邪魔だからこの業界から消えてくれないかな。

うまく動かなきゃしょうがないんだよ。

は、パラダイムを評価する態度としては正しいよ

うまく動くのは当たり前

うまく動かないから７割のPJがデスマる

>>440は外来語の意味を知らないらしい
まぁどーでもいいけど

問題になってるのはこういうことだろ。

「クラス・インターフェース・継承の仕様は分かっているが、
それを機能分類にしか使えていない奴が多すぎ。
俺は分かっているけど分からない奴がいるから困る。」

こんな主張なんだろ。
じゃあ底上げをどうやるのがいいんだ？
少なくともうちのボンクラはダメっぽいぞ？

＞使えていない奴が多すぎ。
＞分からない奴がいる

だからなぜオブジェクト指向は普及しないの？

そんなん簡単じゃん。
自分で勉強会を開くとか、会社のメーリングリストでオブジェクト指向の使い方を説明するとか。
いくらでもやりようはあるでしょ。

オブジェクト指向＝ベータ・マックス
その他の開発指向＝ＶＨＳ

業界の９割が偽装請負会社だからなあ。
教育しようにも現場任せになるし。

>>450
優れた教育用の著書がないからだろう。
実用性云々はさておき、普及しない理由はそれだけじゃねーか？

本気で普及させようとするんなら、OO専門のホムペ作ればよいんじゃね。

ホムペ(笑)

とにかく見解を統一しないとダメだろう。
仮にそれが自分の認識と異なっていても、
業界標準として統一されるのなら自分は受け入れるし、歓迎するよ。
お互いに俺俺だと言い合ってるような状況はよくないしな。
やはり資格化かな。

資格化(笑)

●

↑OO資格リンク

クリックできるんだな！

詳しくは明日の朝刊で

>>333
ああ、一つ忘れてたｗ
DCOM以前のCOMとか、GNOMEのCORBAとか、
GUIアプリのローカルなアプリ連携のために、
ローカルなメッセージングをやっている、と言えるのかもしれないなｗ
しかも、その形式のオーバヘッドを取り去るために、
わざわざローカルのDLL参照に近い形に実装を焼きなおした、という倒錯具合。

あれ本来は、リモートデスクトップに必要なインフラを、
ローカルにも実装した程度の話だと思うんだけど。

ただあんたが「密結合メッセージングOO」で何をさしているのか正直わからんから、
COMがそれかどうかは、俺には判別つかねぇけどな（ぷぷぷ

>>そうそう、うまく動けばなんだっていいんだよ。
たまたまうまく動いてるだけで。DBとかのVersionあげたら
動かなくのいっぱいあったよ。
環境依存で書いてたまたま動いたから、そのまま本番コードに注入

うまく動くのは当たり前とか行ってるやつは現役PGなのか？
合性や設定が奇跡的なバランスで調和したときにのみ、プログラムというものはうまく動作する

奇跡に頼るって凄いぜ！

二回に一回くらいはちゃんとうごきます

>>461
すまんが、333だが335じゃないから。
昨日から何度か言おうと思ってたんだが、変な敵意もたれているようで
言えん買った。

大層気にしているようだけど、いまさらだからいうけど。

335じゃないから。
だから漏れ、疎結合メッセージングOOも密結合メッセージングOOもなんじゃらほいだから。

なんでもいいべ

詳しいこと分からないけどさ
OOが普及しないのって、
ODBMSとかORDBMSとかがRDBMSに取って代わられて
普及しないことと、関係あるんじゃないかな
オブジェクトのシリアライズってOOPの一番肝の部分だと思うのよ。

つーかORマッピングとかいう言葉があること自体
なんか気持ち悪くない？

言葉すら統一できない宗教を普及させるのは困難

>>466=333
キミさぁ、このスレほとんど２、３名で回ってるって気付けよ

つまらん言い訳はどーでもいいから、有意義な話をすべし。ツマラン書き込みは例の常駐多重コテだけで充分だっちゅうの

>>470
恥ずかしがるな。誰にでも勘違いはある。

↑爆裂バカにょる典型的にどぃでもぃぃ書き込みのれぃ

　　 ∧＿∧　　／￣￣￣￣￣
　　（　´∀｀）＜　オマエモナー
　　（　　　　） 　＼＿＿＿＿＿
　　｜ ｜　|
　　（_＿）＿）

オブジェクト指向なんて
カプセル化、継承、ポリモーフィズムだけ知ってればＯＫ

知ってるだけかよ

しかし>>466は、他人(俺)の自作自演に乗っかって得意げになるだけで、
ホント芸のない奴だなぁ

>>474
俺はそれ全部ＯＯと関係ないと思う派

↑爆裂バカにょ〜る典型的にどぉ〜でもぃぃ〜書き込みのれ〜ぃ

オブジェクト指向を理解できない馬鹿が
オブジェクト指向言語の機能であるカプセル化、継承、ポリモだけ覚えて
オブジェクト指向を覚えた気になってる一番痛い例だな

それぬきでオブジェクト指向を語れるようになったら理解できたって言ってやってもいいぜｗ

↑爆裂バカの書き込みはとても単調な件

C++やJavaのオブジェクト指向はカプセル化、継承、多態性で構成されてるがね。
お前らこういう要素を簡単だとか言ってるけど、そういう奴ほどこれらの要素をどれほど理解してるか怪しい。
もし仕事をSmalltalkでやってるってんなら別に好きにやってりゃいいが、
もしC/C++,Java,Perl,C#,Ruby,Pythonあたりの言語で適切な設計をしようと思うならカプセル化、継承、多態性はちゃんと把握しとけよ。
特にカプセル化。
あらゆるオブジェクト指向の解説でカプセル化が一番最初に説明されるのは最も重要だからだってことを忘れるなよ。

↑つい２〜３年前に委譲を覚えたばかりで、まだ委譲の果たす役割をよく理解できていない爆裂バカ

横槍だけど。
Wikipediaが正しいかどうかは知らんが、それによると
その3つがOOPの基本的な構成要素らしいよ。

OO設計はオブジェクトを切り出す作業だろ。
OO分析はシラネ。

「オブジェクト指向」って一纏めに言っちまうと、
特徴が良く分からなくなると思うけどな。

↑低学歴引き篭もりの議論の根拠は、権威筋でも学会の意見でも現場の知識でもなく、
　　いっつもウィキペディアな件

>>483
全く嘘だな
継承やポリモは後からできたもんだし
なんで構成要素になるんだよ。おかしいじゃん。

継承と多態性無しでどうやって型の実装を隠蔽すんだよ。
継承と多態性使わないで委譲だけで出来ますってんならやってみろ。

ちなみに型の実装の隠蔽はGoFデザインパターンで実例が出てるし、
原則っつーことでOCPって名前までついてる。

>>484
そらWikipediaが「一般的な認識」に近いと思ってるから。
学問的に間違えてることもあるし、特定の現場とは違う認識のこともあるだろうけど。

はじめて継承を知ったときはなんか感動した。

>>486
隠蔽なんてないよ
そんなの後付けのどっかの馬鹿がいれたもんだし
いいかよく考えろオブジェクト指向ってオブジェクト単位で分けるだけだぞ
そういう付属物に気をとられて、本質から逃げてたらいつになってもオブジェクト指向は覚えられないぞ

オブジェクト指向がオブジェクト指向たる理解をちゃんとしろよ

＞オブジェクト指向がオブジェクト指向たる理解をちゃんとしろよ
イミフ

>>486
まぁOOに本質があると思っている>>486は、
永遠に実務で使い物にならない薀蓄野郎だとバレバレな訳でｗ

相変わらず本質議論したがるOO信者はおもろいねぇ。
10年以上前、嫌々ながらOO始めた当時から、おまえら胡散臭くて、
さっさと滅ぼしてやろうとOO業界に身を潜めてたわけだがｗ
相変わらず信者はレベル低いなぁ

【OO】
ソフトウェア工学上の一形式。
狂信的信者がOO至上主義に基づく見当違いな言辞を吐きまくる事で有名。
賢い皆はバカに騙されず、サクっと形式のみマスターして、次いきまひょ次

継承やらポリモやらテンプレートやら
オブジェクト指向の概念そっちのけで目に見える機能に騙されて
別の方向へ行ってしまうほうが害だと思うんだがな

オブジェクト指向言語の見える機能はほとんどフェイクだと思っていい
重要なのはクラスだけ
それをどういう単位で分けるかを書いてあるのがオブジェクト指向
言語の小さい機能に騙されるな
それが必要になるのは分ける作業が終わった後だろ？

日本人はオタク気質だからね。
本質より、細かい設定や用語に萌える。

「カプセル化・継承・多態性」は、ストラウストラップが“オブジェクト指向”を再定義した際の
「抽象データ型（ユーザー定義型）＋クラスの特徴」を言い換えただけ。

オブジェクト指向の本質があるとか無いとか、
別の方向だとか、小さい機能だとか、中身の無い戯言ばっかだな。

>>496
そんなのオブジェクト指向を使ってクラスを分けた後の話
やりやすいように使ったらいい

>>497
そうやって目に見える機能しか認識できないからいつまでたってもね（ｒｙ
正直、物を作るセンスなさ過ぎｗ
技術者に大事なのは直感とセンス、それと勇気
そんないつまでも自分の知識の殻に閉じこもってるからいつまでも成長できない
見えるものも見えてこない
かりそめの技術に騙される

俺俺応酬中か

オレオレ俺だよ。高広が偽乳つけて踊ってるの見ながら酒飲んでたオレ

でもしゅき

つまり>>498はクラスをどういう風に分けるのかが重要で
実装の細かい話はどーでもいいっていいたいわけだね。
じゃぁ是非聞いてみたいのだが、実際のところどういう基準でクラスを抽出したらいいと思う？

と心にも無い事を言って、その場をフォローしてみるテスト

>>502
クラス分割の単位、それはまず目的語の抽出、次に能動か受動かの判定、そして何よりも重要なのは動詞の型の判定だね。
動詞の型については、Genelative Lexicon あたりの文献を探れば、いろいろ研究成果が出ている
と言語ロジストもどきな戯言を書いてみるテスツ

ん？クラスに動詞を結びつけてんのか？
メソッドのことだよな？

ちょっとだけ酔いをさましてマジレスを試みる。
クラス分割、それは、
分析レベルと実装レベル (あるいは概念レベルと実装レベル)で随分と異なる話だね。

分析レベルのクラス、それは、概念モデルに出てくる概念の事で、
ある種の手法(名前忘れたよ)では、それをインタフェースとして捕らえたり、あるいは
ユースケースとして捕らえたり、更にはアスペクトとしてのまとまりをつけたりする。

実装レベルのクラス、これは、分析レベルのクラスに対して、
それが機能するようにするための仕掛けの部分だね。
この仕掛けの部分は、OMGの古い分類で言うと業種横断共通クラスとか、
フレームワークとして綺麗に区分していく事もできるが、
そっから外れたつなぎの部分は、それこそ構造化時代から連綿としたモジュールに近い、
オブジェクト指向とは余り関係ない代物になる。

オレの流儀を言うと、そういった汚い部分をできるだけなくすよう、
フレームワークなり共通クラスを作り尽くすべきだと思う。
最近、ERPやCRMの分野でオープンソースが出てきた。
そいつらを使って、業務アプリのどーしようもなく汚い部分を置き換えていくのが、
ここ数年の仕事だと思う。。。すると豆蔵ではなくウルやネットワーク応用研究所の選択肢が正しい事になる(爆笑

最近、国内ERP業界の立役者の一人っぽい人物の会社に積を置いていたが、
SAPだi2だBARNだなんて外資ソフト輸入業なんてクダラネェし、そろそろオプソERPの会社に移るかなぁ。
それって、オレが新卒時代からの一つのビジョンだったりしたわけだがｗ

>>504はなぜそれが適切なクラス抽出方法だと思うのかな？
まず最初に目的語を抽出ってあるけど、
どうしてそれがクラス抽出の出発点足りうるのか。クラスとは目的語のことなのかってあたりが疑問だ。
そもそもそうやって目的語を取り出したシステム設計にはどんな利点があるの？
勉強不足で申し訳ない。ぜひ教えて。

>>507
そっちのレスは、単にObject＝目的語っつうダジャレもどきの本質論だ。
意味がわかんねぇようなら、素直にスルーして、>>506を考えろ。

おっと忘れてた、>>507にも結構マジレスが混ざってて、
それはGenelative Lexicon に関する話だ。
主体や対象(名詞)を主とし、動作(動詞)を従とするか、
あるいは動詞を主とし、名詞を従とするか、なんてのは、
ドーナツの穴がドーナツの本質かどうか考えるくらいに野暮な話なわけで、
自然言語処理における意味解析では、ある動詞がどのような品詞を伴って意味を構成するか、
なんて話が90年代初頭から話題になっている。そのあたりを、例のアンタ方が大好きなSemantic Webと絡めるのが、
オレが２年程前に考えていたWeb2.0対応。まぁそんな話はもー飛んでしまって、オレはどこで研究活動したらいいか
路頭に迷いそうな勢いなわけだがｗｗｗ

まぁ、498≠504＝506なのは言わずもがな。
ちょっとはマジレス頼むよ。

>>510
マジレスしていろいろ勉強させてもらいたいところだけども、
正直なところ何が言いたいのかさっぱりわかりません。

>>505,>>507　の頭でも理解できるように話を整理すると。

名詞句抽出に基づくオブジェクト抽出、こいつは多分海外のメソドロジストが大昔に唱えた一手法で、
まぁOO分析の本見ればよく見かける話。例えば応用なんちゃら言う誰かが大好きな分厚い本とか。

で、それが>>505, >>507の直感と異なるなら、その点を議論すればいい。
>>505, >>507の直感が本物なら、どちらが正しいにせよ、その議論は有意義なものとなる。
もし突き詰めた考えなしに、他人に異論を吐きたいだけなら、それは時間の無駄だ。バイバイ

きゅん萌え、またクビになって暴れてんの？

クビっつうより、移籍OfferLetterお断りってな話だな。
どっちかっつうと、こっちが会社をクビにした状態。

42歳引退をマジで考えてるタメのMBA持ちCIOに、
「おまえさぁ、人生長いんだから、マジちゃんとしろよ」
とか諭されたのが、一番応えたｗｗｗｗ

やめとけよ。もうひろってくれるとこねえぞ。

>>516
だいじょうぶだよ、おれ。
世の中、バカがもっともらしいく澄ました顔して
ゴミみたいな仕事の進め方してるのに、絶望したし。
そろそろ別の仕事スタイル考えるわ。似非コンサル業やドカタITとは別のやり方でな。

と、無職引き篭もり人間相手に、しおらしい態度をとるのも馬鹿馬鹿しい話なわけでｗ

で？
>>505,>>507は思いつきか？
それとも突き詰めた考え付きの異論か？
いい加減はっきりせい

イカレのくせに気位ばっかたけえからな
いっそ死ねばいいと思うんだけど・・・マジレスすると

ＯＯ原理主義者の俺のレスは今のところこのレスを除くと>>498までな
ここ数年で原理主義者は俺だけになってしまったのかなｗ
昔はもっといたんだが・・・ま、書籍がないからねぇ・・・ｗ

モデルの抽出に必勝法なんてあるわけねえだろ
どんだけオボコイのよｗ

>>522
オブジェクト指向使えよ

>>520 イカレてるのはお前だと思う。２ちゃんム板マ板で7年も暴れ続けてる元CEOなんてお前くらいなもんだぞ

>>522は工学者として敗残状態にあると認識した

なあ、もしかしてここには、実際の開発現場で、モデルを抽出する方法をずっと議論してて
コーディングに進まないって奴いない？

で？
>>505,>>507は思いつきか？
それとも突き詰めた考え付きの異論か？
いい加減はっきりせい

>>526
オブジェクト指向で一発ですわ
１０分かかりません

>>526
どっちかっつうと、モデリングは頭の中で済ませて、
いきなりコーディングして、最後に提案プレゼンかな、
おいらの流儀は。

そんな奴ゴロゴロしてると思ってたけど、
自分のコーディング能力の優秀さに
現役コンサル兼PMとして恐れおののく今日この頃

>>528
スゴイデスネー（棒読み

>>530
おい志村、うえ、うえ

で？
>>505,>>507は思いつきか？
それとも突き詰めた考え付きの異論か？

ろくな返事もできねぇヘタレの癖に、
一人前に異論書いて話頓挫させんなよ

1発で抽出できるわけねえだろ
うまくいくかどうか、やってみりゃすぐわかるべ

>>527
新参がお前の粘着に引いてんのが見てわかんねえか
だからお前はイカレだっつーのよ

>>533
もっと愉しく！愉快に！オブジェクト指向分析をかたらおうぜ！

別に異論でも反論でもなく論理が飛躍してるように見えた点を質問してたわけだけども、
それに対して全くまともに答えて無いよね。

エンジョイ＆エキサイティング！

>>505は当たり前のことを聞いてるだけじゃないのか？
クラスを動詞化しちゃいかんだろ。

>>535
ホイ来た
じゃそのキミが感じた論理飛躍とやらの箇所を、きちんと示してね。
オレが思うに、単にキミの経験と知識が不足しているから、
論理の筋が見えてないだけだけど。

>>538
だから>>507で疑問文で書いてますけど

>>537
ホゥホゥなるほど、そんな低レベルな質問だったのか。
おっしゃる通り、名詞句＝オブジェクト候補＝たぶんクラス候補、
動詞の類＝メソッドだね。それが何か？

オレが言ってるのは、クラスやオブジェクトを抽出する上で、
動詞も重要だよ、何故なら自然言語解析には動詞を中心に意味解析する流派があって、
そこの成果物(例えばGenelative Lexiconあたり)を導入することが、OOの生きる道だと思うから、
ってな話。ちょっと先端すぎたかな？

× そこの成果物(例えばGenelative Lexiconあたり)を導入することが、OOの生きる道だと思うから、
○ そこの成果物(例えばGenelative Lexiconあたり)を導入し、動詞にまつわりつく名詞の類型化から、
　　　クラスの類型化を図る事こそ、クラス分析においてホットで面白い話題だと思うから、

> >>504はなぜそれが適切なクラス抽出方法だと思うのかな？

適切な方法だとは考えていない。
>>504はあくまでもジョーク、>>506がオレの意見だ。
人の書き込みをちゃんと読め。

> まず最初に目的語を抽出ってあるけど、
> どうしてそれがクラス抽出の出発点足りうるのか。クラスとは目的語のことなのかってあたりが疑問だ。

それは単に、Object＝名詞句　を捉える事こそがOOの起源だ、
っつうOO本質論をさらっと流しただけ。
理由を聞きたければ、OO論者に聞け。オレはかなり粗雑な話だと考えている。


> そもそもそうやって目的語を取り出したシステム設計にはどんな利点があるの？
> 勉強不足で申し訳ない。ぜひ教えて。

しらねぇ〜よ。
オレ自身、Object＝目的語なんて、OOのキャッチフレーズ程度にしか考えてないから。

× それは単に、Object＝名詞句　を捉える事こそがOOの起源だ、
○ それは単に、Object＝目的語　つまり動作対象を抽出する事がOOの起源だ、

なんつーか、長すぎてだるい文章だな

どの文の事か、端的に述べよ。
結局小学生だって言えるような議論
(お前はそれが本質だと思うのか？それは本当に役立つのか？)
しかしてねぇよな、お前

それがだるいつーの
うざい

議論で負けると逆ｷﾞﾚか。
だから無職引き篭もりは議論にならねぇ

わかったわかった
妄想がんばれや

なんつうか、この程度の文でダルイとか言っちゃってるお前って、
実際人様に役立つ仕事なんてした事もねぇんだろ？

最近痛感する事があって、それは人を信用し、人に役立つ事をし、人に信頼されるには
とてつもない労力がかかるって事。まあ新卒時代から、そのあたり苦労してきたけどな。

その辺りをいい加減に済ましたままのうのうと生きてる中高年は、一発で判るし、
そいつらはさっさと死ねばいいと思っている。

この手の話って、結局実務経験の有無が如実に現れるな。

哀れ

>>549
いいから落ち着けよ。
何をそんなにムキになる必要があるんだ？

お前がバカで議論にならねぇからからかってるだけだよ。ムキになりなさんなｗ

>>545
横槍の上に横道だが、
個人的には「本質」ってのは役に立たないと思う。特に仕事の役にはな。
ソコから派生した(?)具体的なモノが役に立つ。

>551
放置するのがよさげ
かなりイタイ子のようだし
誰彼かまわず噛みつくきゅん萌えはこんなもんだ

>>505,>>507
さっきは「質問はもう出したのに答えてねぇ」とかずいぶん威勢のいい事言ってた奴が、
答えだした途端にずいぶん静かになったなぁ、

反応したらどーでつか？

なんつうかさぁ、結局議論放り投げるなら、
最初っから異論なんて唱えなくてええんじゃねぇ？

その程度てキレるようじゃ、実際仕事でも下っ端仕事しか回してもらえないんだろ、お前さん

2chなのに　お前　と断定して書くあたりはイラナイ子＠きゅん萌えしかいない

↑実務ができない哀れな子が、論点をずらそうと必死だな。
だから頭悪い奴は書き込みすんなとあれだけ（ｒｙ

きゅん萌え警報発令中！！！！！

議論を元に戻すと。
クラス抽出には二段階あって、
分析クラスは、分析モデル、概念モデルから抽出→インタフェースやユースケースやアスペクトと対応
実装クラスは、分析クラスの影響を受け、一部分析クラスをそのまま引継ぎつつも、
分析モデルを動かすための「仕掛け」の部分を抽出する必要がある、と。
そして実装クラスを適切に構成するには、実装に必要なドメイン毎にフレームワークを設計するのが定番。

これでやっと１０年前程度のレベルまで来た。
そいで、次の話はなんだよ？

またきゅん萌えかよ・・・こいつどーしよーもねーな・・・

>>560
世の中には分析モデル作りなどさせてもらえず、
構造化モデルや、COBOLリバース仕様書をいきなりポンと渡される
悲惨な現場がある。その名も「新業務システム構築プロジェクト」ｗｗｗ

>>560
そういうことをできる奴が極端に少ないから、
OO言語は普及しても理論は普及してないってことじゃね？

>>562
NとHはそれがデフォ

そんな悲惨な業務システム予算を、
パッケージ売り込みで食いつぶそうというのが、
俺が新卒時代から某SIer役員連中に吹き込んでたERP。

第一次ERPブーム時は、ジャワポン勢に付かざるを得なかったオイラだが、
オプソERPブームが来そうな今日このごろ、
オイラもRuby松本さんとこみたくいっちょ勝負するかな？

>>564
Nに関して、それは外注仕事の話な。
NTTデータほどではないにせよ、Nは業務パッケージ仕事に力入れてるだろ？
一からジャワポンで構築なんてのは、外注向けゴミプロジェクト限定だよ。

Hは・・・あそこならやりかねんｗｗｗ

>>565
きゅん萌え、お前はもういいから

あと、メーカ/SIerでMSの味方なんてマヌケな会社も世の中多いが(例えばユニ○○)
MSの本領はユーザサイド・コンピューティング。
MSの開発環境が開発しやすく整ってるのは、アレSIerに開発させるだけじゃなく、
ユーザ側システム部門が主導権を握ってシステム構築を進めるためだよ。
実際、アメリカでMSなんちゃらコンファレンスなんて、SIじゃなくユーザ企業の人が出席するための会だってｗｗｗ

言語仕様だけで止まってる奴にOOの概念を理解させるには
結局どーすりゃいいんだ？
このままだと失敗プロジェクトへらねーだろ？

ジャワポンの元々の狙いも、実はユーザサイド・コンピューティングだった。
あれ、最近はCOBOL出身者が必死に覚えてやってるみたいだけど、
COBOLer程度の頭でも10年かければ理解できる内容っつう事は、
実はユーザ側システム部門でもできるくらい、見通しよくシステムが構成できるって事なんだよね。

もっともSunとM$には大きな差があって、
SunはDBベンダーにプラットフォームを提供したり、M$相手にデスクトップ争いする程度の商売しかできなかったけど、
M$はERP分野に果敢に進出しているって点、これが今後すごく効いてくる。
M$がSAPを倒すかどうか、はシラネェけど、そしてM$の影響力は今後どんどん弱まっていくだろうけど、
まあそれでも、メーカー系と同じ程度にはやるべき事ちゃんとやってる、それがM$の偉い所。腐ってもM$だね。

>>563
この業界に20年近くいて、未だにその問題にアクション起こせてないOO業界人ってのも、
相当なマヌケだと思う。

某社でOOコンサルなんて、所詮真似事として分析図を描く、コーディングなんて無理っぽい程度人材だからなぁ。。。先が思いやられるぜ。

問題なのは統一見解が無いってことじゃん。
OOを覚えろ、と言われても、何が正解ですか？って聞かれたら
これ読んどけって言える本が無いってのは凄すぎだろ。

もともとOOなんて民間療法程度にしか思っていなかった俺が、
10年程前に現実への対応としての暫定案としてOOをマスターし始めた俺が、
1〜2年で会得したクラス抽出方法が>>560。
未だに、そのレベルでちゃんと会話のできる人材には会った事がない。

なんでかねえ。
結局この土方業界に来るような奴は、根本から頭の出来が悪いのかなあ

>>572
おまぃの大好きなセクースにも、統一見解も正解もヘッタクレもないが、
それでも子供は生まれ続ける。この差はなんだろうね？
（もっとも最近は出生率低下してるけど

何が未だにｗだよ、全部俺が教えてやったことじゃねぇか
どうやったらそんな風に記憶改ざんできるのやら

↑池沼が戯言言ってるけど、
　実際問題として国内のOO論者から影響受けた事なんてほとんどねぇ俺がいる

>>560のような風土で生まれたジャワポン

そんなジャワポンを生み出す能力もなく、
金科玉条のようにOOをありがたがる極東ニッポン。

Rubyちゃん頑張ってね。あんただけが頼りだから。。。

半可通が下見ていい気になってる図そのものだわな、きゅん萌えって
クビなるのも当然
コード書きだって出来るか怪しいもんだ
わけのわからん、うんこ見たいなモデル披露して悦に入ってるのは見たこと
あるがなｗ
無職の間、ここ来るの禁止な。まあ、二度と戻ってこれないと思うけどｗ

ちなみに、10年前にフレームワークが定番つって俺に教えてくれたのは、
東大物性研出身の研究者(上司)の影響受けて、OO研究で英国留学した髭髭男。噂では奥さんは日銀エリート。
10年前は隣町に住んでたけど、今どこで何やってるやら。

>>574
生みだされるものを捨てたり腐ってたりすることは通常ないだろ。

ちなみに名詞句抽出法について最初に読んだのも、その髭髭男の論文。

おまいら怠け者な国内OO論者の世話になった覚えはねぇ。これが俺の立場っつう奴だ

>>578
また低学歴のヒステリーか。
「２ちゃんねるに出入りしてて、高級な事言ってる奴は全部嘘だ、俺が一番頭がいいんだキーィーィーィーーーーー」
ってか。

現実見ろよ現実。

権威ある者を、見たことある、一言二言話したことがある、隣町に住んでた
おまえそんなのばっかだな
もっと自分を客観的に見ろよ、ムショクがｗ

> 俺が一番頭がいいんだキーィーィーィーーーー

端々に現れるよな
おまえのイカレ価値観がよｗ

権威ある者を見た事ある、話した事ある？はぁ？笑わせるな。
髭髭男って、単なる俺の元上司だよ。
俺が当時所属してたSI会社で、サイエンス部門から飛び出た俺の受け皿として
俺の上司になった男。

なんでOOってこう敷居が高いんだろうな。
このスレ見てても喧嘩ばかりでどうしてこうまとまらないのか不思議。
お前は違うと言い合うばかりで、結局なんなんって感じ。

>>586
それについては、ちゃんとビジネスの現場に身を置いてたら、簡単に理解できるはずだ。
まあお前さんはどうせ、おこぼれ仕事を日陰でついばむ程度の仕事しかしてねぇんだろうけど。

笑わせてんのはお・ま・えｗ

>>585
だから何なの？

「普通の」人はそう考える

お前にはそれもわからない

韓国人のあおりのようでなんとも

ん？>>579がフレームワークを教えてもらった髭髭男が、>>585には単なる元上司だったって言ってんのか？
でなければ、髭髭男なんて名詞出すはずはなし…

>>579と>>585が別人なら、ガキの張り合いやってんのかよｗ

>>589
だねぇ。なんでその程度で権威ある(ｗとか思っちゃうのかよくわかんね。
大学教授なんて、プロジェクトの同僚だろ？サイエンス分野に居たら。
権威もﾍｯﾀｸﾚもねぇんだよ。ただ、唯一大切なのは、そいつがいくばくかの真実を語れる人間かどうか。
それだけ。

恒例の自演

まあ大学教授とか国立研究所研究者とか、はたまた業界管轄省庁関連者が、
(ﾉ∀`) ｱﾁｬｰ
と思っちゃうような言動をする事は毎度毎度なわけで、
そいつらバカどもを正しい方向に導いていくのは俺ら産業人の仕事だと思っている。

たかひろ居るんだろ？

>>586
ビジネスから見れば実装のための一手段でしかなく、声高に主張することは
なくて、もっと便利な手法が現れれば置き換えられるものだが、
OOが何か斬新な物のように錯覚して、使っていると声高に主張することが
目的化してる奴がいるんだろう。

長文書くとウゼェーーーダルイーーー言い出す池沼向けに、
レスを分割投稿すると、途端に「自作自演」呼ばわりするバカさ加減について。

権威があろうがなかろうが、んなとこに書き込む意味がわかんねっていってんだけど
頭おかしすぎてわかんないんだろうなあ・・

はぁ？頭弱い子って、議論に負けると相手の人格攻撃始めるからやってらんねぇ〜なｗｗｗ

また目を真っ赤にして、キーボード叩いてるのか？

いい加減眠ったらどうよ？

ひょっとして、いま、
たかひろきゅん萌えもいるの？

なんでも髭髭男は、豆社長と間違われた事があるんだそうな。本人はいたって得意げだったよｗ

今夜の議論の結論として、
>>560を実践してコーディングまで落とせない詐欺師(たとえば内田みたいなレベルの奴)は、
１０年間山にこもって、クラス抽出の勉強しなおしてこい
という事で終了。

さんざ偉そうなこといっときながら、やっと就職できたところが零細Javaドカタ屋だってんだから話になんないわな
しかも3ヶ月でクビ。生き恥もいいとこ

低レベルな喧嘩が以後１００レスは続く

Javaはやってねぇな。
あと、クビにはなってねぇな。
明日もリリース作業だよ。朝8:30開始、9:00リリース。
まったく雇われってのは夜更かしもできなくてダルいよな

>>601
次は関数言語についての講釈頼むよ

風呂入って、酔い醒ましてきた。
この10年間のクラス抽出手法の進歩を見ようかと思ったら、、、相変わらず議論が幼いな

クラス抽出手法なんかまやかしに決まってるだろ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
この10年の進捗なんかよ

ここのスレ主は精神年齢が幼いからな。
議論に負けるとすぐにスレを荒し出す。

こいつと２ちゃん上で足掛け７年、実業務で約１年顔あわせて、
もう慣れっこになっちゃったけど、な。

>>607
バカ丸出し

なあ。
誰かどっかOOのコミュあったら教えてくんない？

>>608
>２ちゃん上で足掛け７年
7年もキチガイやってるのか

また、タカヒロきゅん萌えがあらしてんのか

>>560
鬱堕って一体誰だ？
そんな名前、聞いた事ないよ。

>>602
じゃわぽんはすっこんどけ

とりあえず、wikipediaに反論するやつは、
wikipediaを


　　　　　　　　か・き・か・え・ろ

>>601
欝堕って一体誰だ？
そんな名前、聞いた事ないよ。

>>602
じゃわぽんはすっこんどけ

> アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ

アスペクトなんて後付で作られたもんだろ？

>>601
＞ >>560を実践してコーディングまで落とせない詐欺師(たとえば内田みたいなレベルの奴)は、

内田ってだれ？ｗ

内田きゅん萌え？ｗ

>>614
どっかの役所のバカが、ガンダムの項目職場から200回も書き換えて、懲戒くらってたな。
２ちゃん並に低レベルっぽいよな、wikipediaなんて。
ふつーム板で志のある学生さんが居たら、wikipediaなんて相手にせず、世界各地の公開授業やら研究室のページ見るだろ。
wikipediaに拘る奴の大半は、ちょっと負け犬入ってるような気がする。２ちゃんの大半の住人と同様に。

精神異常の人が、アスペクトという単語に反応しはじめた様子です。。。

クラス抽出手法なんかまやかしに決まってるだろ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
この10年の進捗なんかよ
クラス抽出手法なんかまやかしに決まってるだろ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
この10年の進捗なんかよ
クラス抽出手法なんかまやかしに決まってるだろ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
この10年の進捗なんかよ
クラス抽出手法なんかまやかしに決まってるだろ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
この10年の進捗なんかよ
クラス抽出手法なんかまやかしに決まってるだろ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
この10年の進捗なんかよ
クラス抽出手法なんかまやかしに決まってるだろ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
この10年の進捗なんかよ
クラス抽出手法なんかまやかしに決まってるだろ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
この10年の進捗なんかよ
クラス抽出手法なんかまやかしに決まってるだろ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
この10年の進捗なんかよ
クラス抽出手法なんかまやかしに決まってるだろ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
この10年の進捗なんかよ

まあ…なんだ。みんな熱いんだな。
その情熱を、コーディングや実装でOOを有効に生かすことに結びつけようぜ。

>>618
ま、2chで激しく議論してる時点で底辺ITドカタ確定だぞ
お前や俺を含めて、われらは底辺ITドカタなんだからよ

アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ
アスペクトをどうする、くらいのことがちょっとだけ情報出てきたくらいだ

お前は、な。

俺はコンサル会社勤務。

>>622は底辺ドカタ、な。

俺は外資コンサルでウハウハだけど。

やっぱり、タカヒロきゅん萌え = ウチダきゅん萌え なのだろうか

俺も外資コンサルでトップなんだが

>>624-625
ドカタ君！　素敵

金猿なんて技術いらないじゃん
何無駄なことしてんの？ｗ

コンサルって、コード書けないくせに
口ばっかりなやつのことだから
普通の技術者はなろうとは思わないな。
なれないんじゃなくて、なろうとは思わないなｗ

多くのオブジェクト指向言語は、中の人をクラスとして定義する。
まず「男キャラ」「女キャラ」のようにして中の人を宣言し、
「女キャラ」を実体化して「香織」「素子」などを作る
(実体化したものをインスタンスと呼ぶ)。
実体には、パラメータなどを格納することができる
(これをメンバ変数と呼ぶ)。
「香織」「素子」は、パラメータは異なっているが、中の人は同じである。

実体へのアクセスは、かならず中の人を通しておこなう。
これには「会う」「話す」などのメソッド
(メンバ関数とも呼ぶ)と呼ばれる関数を定義しておこなう。

>>623
こいつって、典型的２ちゃん脳だと思う。
２ちゃんのこの分野の情報提供源が俺しか居ないって気付かず、
俺が書いた情報範囲しか理解しないまま、いっぱしの議論をしようとしている
キチガイだ

>>631
やっぱだめだな。
俺俺OOによると
それは間違い。
間違いなんだよ。

自称外資コンサルの俺に聞きたいことある？

おい、ちょっとまて。俺も今日からコンサルだ

>>632
ニュー即でも一、二を争うバカコテハン「スパ」が、
俺が昔教えた参考書籍リストを後生大事に抱え込んで、
「自分はこれを全部読破した天才だ」と豪語してるのを見て、眩暈がしたっけ。
本物の引き篭もりなんだろうな。こいつ

コンサルってITハスラーだろ
かっこいいな

クラスは、設計書段階。
インスタンス化して初めて設計書の実体ができる。

メンバ変数って、フィールドとかプロパティって言うんじゃないの？？
パラメータって引数とかじゃないの？

キチガイが沸きはじめたな

スパ ってだれ？

スパきゅん萌え？ｗ


どうも、スレで見かけた気に食わないやつを
誰かであることにしたがっているやつがいるみたいだな。

俺が昔教えたって、お前２ちゃんねるでそいつが誰かわかるのかよｗ

異常者って怖いね〜

きゅん萌え、いっぱしの議論って言葉好きだな
議論なんてしないくせにｗ

こわいこわい

こわいねぇ

クラス抽出の話題にもついて来れず、
異常者呼ばわりされてもしつこく粘着するキチガイって、
だーれだ？（ヒント：俺はクラス抽出の話題できるから、俺ではないよ）

われわれは　OOきゅん萌え　なんだからね

>>630
横で話聞いてるだけで５回は殺そうと思う場面があるところがすばらしい話術だと思った

俺もコンサルだから違う。

>>645
　たぶん >>646が異常者だ

さすが隔離スレだ

自分でこのスレ2〜3人しかいないっていっときながら、
>>560とかコテつけちゃう感覚が怖い

>>649

こういう、わざとらしいレスってどう思います？ｗ

ITハスラーのコンサルが多いのはわかったが
SEやアーキテクト様はいないのか？

さて、以下にコンサル会社における奇行の例を挙げます。
どれが正解でしょうか？

1. 客先の宴会で裸踊りをして、パンツを脱いだ事がある
2. 上司と家族ぐるみの付き合いをしていて、上司の子供をボートから池に突き落とした事がある。
3. 宴会の隠し芸は産卵（♀社員)

>>654
全て

> 651 名前：仕様書無しさん[sage] 投稿日：2007/10/09(火) 00:09:36
> 自分でこのスレ2〜3人しかいないっていっときながら、
> >>560とかコテつけちゃう感覚が怖い


560が「自分でこのスレ2〜3人しかいない」といった人と同一人物ってわかるのか？
すごいな。ある意味でｗ

>>655
おまえさぁ、やっぱ外資コンサルとかしらねぇだろｗ

>>654
>3. 宴会の隠し芸は産卵（♀社員)
これが見たい

>>656
そのくらい誰でもわかるっつの

>>659
すごいねｗｗｗｗｗ

>>657
選択肢にスカないよスカ

>>657
え、僕ですか？>>655より前のレス全く読んでませんが。。。

ITハスラーのコンサルにITドカタの俺から質問
ここのITハスラーはプロジェクト要員としてコーディングをよくするのか？

3. は、某有名広告代理店の伝説。
2. は、元俺の上司で「北海道の手負い熊」の異名をとった部長。(まだ役員になれてねぇ〜の、あんだけ無茶してｗ
1. これがコンサルですね。なんて心優しい、品行方正な生き物なんでしょ、ｺﾝｻﾙって。(もちろん、パンツは２枚はいて、脱いだのは一枚だけだよ)

>>664
えーと、まあ、どうでもいい。

仕事とるならお触りないのは嘘でしょう

>>664
0. 行きつけの酒場に、自分専用の偽乳をキープしている

これも追加な

相変わらずコイツレベルひくいなぁ。
産卵で大喜びって、ガキかよ

>>631
こいつも素人丸出しバカ丸出しだな。

もう寝ろよ
リリース作業ｗ遅刻すんぞ？ｗ

>>669
で、お前の意見は？

自分が馬鹿にされるのが怖くていえないのかｗ

＞＞６７１
お前は、底知れないバカだ。
いっぺん頚動脈スパッと切断して、頭の中の血を入れ替えて来い

素人が、ど素人丸出しの妄想(>>631)を書いて、
プロに立て付く悲惨なスレ

このスレに足りないもの
それは思いやり

２ちゃんの底辺は、底なしだからなぁ。
駅の近くの路上で段ボールに包まってる奴が
人恋しくて一晩中携帯でレスしてたりする、そんな世界だからなぁ

いやー反論できないところを指摘すると
逆上しますねｗ

精神異常でホームレスで、話相手が２ちゃんだけってｗｗｗｗどんだけ底辺やｗ

知り合いの話だけどってやつ？

とりあえず>>631を読んで、
このひとはコーディングなどした事もない素人だと
私も確信しました。

>>672
>いっぺん頚動脈スパッと切断して、頭の中の血を入れ替えて来い
こんな言葉って異常者しか使わないと思うぞ

>>674　思いやりがゼロだから異常者と思う

>>675
新宿駅近辺なら、デフォだろ。
携帯持ちホームレスの娯楽＝２ちゃんって

パソコン持っていても娯楽が２ちゃんｗｗｗｗ

>>679
俺もそう思う。まともな文章書いたつもりになってるのは、きっと本人だけだろ。

IT業界人として、>>682発言に激烈な違和感を覚えた。
やっぱこいつネットカフェ常連のホームレスなんだろうな。PCすら自前ではないという・・・

OOスレに粘着している低脳の実態が、段々と明らかになってきたな

ここはITハスラー、ドカタ、素人、新宿家なし人がおれおれOOを述べるところだろ
だから、>>631でもOK。プロはプロのおれおれOOを語ればそれでいい。

↑そろそろホームレスはきつい季節だろ？
ちゃんと仕事したらどーだ？
赤羽近辺のいい口入屋紹介してやろか？
高学歴専門のこのスレで反吐はかれても迷惑だし。

なんだ。自称コンサルは
実はただのホームレスかｗ

>>684
頭悪い奴って、発言に一貫性がないからすぐバレるんだよな。
そして、自分が場違いな人間だとバレても、>>686みたく開き直るから
ますます周囲に嫌われまくるという悲惨スパイラル。

>>688
おめぇの事だよバーカ。さっさと段ボールの家に帰って、マスでも掻いて寝てろっつんだ乞食が

スレタイを見てガンダムを連想してしまった

はやく帰れ乞食が

>>690
その必死さが哀れｗ

>>603がもうすぐ神になる件について

議論を通じて相手に何も与える事のできない、
コミュニケーション乞食は嫌だねぇ〜

はやく死んじゃえばいいのに

>>695
50代間近の企業家が行う、慈善活動じみたビジネスについて
語る機会があったのだが。
この手の悲惨な人間を救うために、２ちゃんは全然役に立たない、
という点、くやしいけど認めざるを得ない。

文句言うなら２ちゃんにくるなよｗ

俺が２ちゃん前夜に考えていた、インターネット時代の掲示板システム、
それはサーバを分散化し、NNTPに代わる新たな情報伝達プロトコル(今でいうRSS）
でゆるく結びついた掲示板システムだった。
今でいう、P2P掲示板よりも、Google Readerに近いイメージのもの。
そこでは、各人が各人の立場で議論をし、興味のある人間がそれにレスを付け、
各人がサーバ管理する事によって悪質な議論妨害をシャットアウトする事のできるシステムだった。

まぁパッケージ化まではなんとかたどりついたけど、
同時期に開発されたサイボーズ程の影響力も持てず、
またblogやSNSといった構想まで生き延びる事もできず、
未だに某企業周辺でのみ細々と運用されている。

そして、その企業を離れた今となっては、その掲示板に掲載された企業内情報を
２ちゃん経由でしか読む事ができない。なんて不思議。

そんな２ちゃんに巣食う救いようのない低能ども。子供達。学生さん。
そんな奴らと折り合いをつけようとしてきた約４年間（途中数年間の空白あり）。
いい加減、なんとかならないものかなぁ、と思いつつ、どーしよーもなく時が過ぎる。
かなしいねぇ

で？

　　　　　　　　　　　　　　　　　　　　　　　 ∩＿＿＿∩　　　長々と書いたのに「で？」で終わらせられた。
　　　　　__ _,, -ー ,, 　　　　　　　　　　　 / ⌒　　⌒ 丶| 　 　 今、どんな気持ち？
　 　 　 (／　　　"つ`..,：　　　　　　　　　(●)　　(●) 　丶 　　　　 　 ねぇ、どんな気持ち？
　　　：/　　　　　　　:::::i：.　　　　　　　 ミ 　(_●_ )　　　　|
　　　：i　　 　　　 　─::!,, 　　　　ﾊｯ　　ミ ､ 　|∪|　　　　､彡＿＿__
　 　 　ヽ.....::::::::: 　::::ij(_::●　　　　ﾊｯ 　　　/ ヽノ　 　 　　＿＿＿/
　 　 r "　　　 　.r　ミノ~.　　　　　　ﾊｯ　　　〉 ／＼　　　　丶
　　：|::|　　　　::::|　:::i ﾟ。　　　　　　　　　　　￣　　　＼ 　　　丶
　　：|::|　　　　::::|　:::|：　　　　　　　　　　　　　　　　　　＼ 　　丶
　　：`.|　　　　::::|　:::|_：　　　　　 　　　　　　　　　　　　　　/⌒＿）
　 　：.,'　　　　::（　　:::}：　　　 　　　　　　　　　　　　　　　　}　ﾍ　/
　　 ：i　　　　　　`.-‐"　　　　　　　　　　　　　　　　　　　　J´ （（

要するに、お前はバカだから、このスレから立ち去れっつうこと

この時間帯はホント馬鹿しかいねぇな

ねぇねぇ、立ち去れといったのに、効果ないよ。
今どんな気持ち？
　　　　　　　　∩＿＿＿∩　　　　　　　　　　　　　　　　　　 　　∩＿＿＿∩
　　　　♪ 　　| ノ　⌒　 ⌒ヽﾊｯ　　　　__ _,, -ー ,, 　　　ﾊｯ　　 / ⌒　　⌒ 丶|
　　　　　　　 /　 (●)　　(●) 　ﾊｯ 　 (／　　　"つ`..,：　　ﾊｯ　(●)　　(●)　丶 　 　 今、どんな気持ち？
　　　　　　　| 　 　　( _●_)　ミ 　　　：/　　　　　　　:::::i：.　　 ミ　(_●_ )　　　　| 　　　　 　 ねぇ、どんな気持ち？
　＿＿＿ 彡　　　　　|∪|　ミ　　　　：i　　 　　　 　─::!,, 　　　ミ､ |∪|　　　　､彡＿＿__
　ヽ＿＿＿　　　 　 　ヽノ､｀＼ 　　 　ヽ.....::::::::: 　::::ij(_::●　　　/　ヽノ　 　　　＿＿＿/　　　　　　結局自分が立ち去るしかないんだよ
　　　　 　 /　　　　　　　／ヽ　<　　 r "　　　 　.r　ミノ~.　　　　〉 ／＼　　　　丶
　　　　　 /　　　　　　／　　 ￣ 　 ：|::|　　　　::::|　:::i ﾟ。　　　　￣♪ 　 ＼ 　　 丶
　　　　　/　　　　 ／ 　　 ♪　 　　：|::|　　　　::::|　:::|：　　　　　　　　　　　 ＼ 　 丶
　　　　　（＿ ⌒丶...　　　　　　　　：` |　　　　::::|　:::|_：　　　　　　　　　　　/⌒＿）
　　　　　　|　/ヽ　}.　 　　　　　　 　：.,'　　　　::（　　:::}　　 　　　　　　　　　}　ﾍ　/
　　 　 　　 し　　））.　 　　　　　　 ：:i　　　　　　`.-‐"　　　　　　　　　 　 　J´（（
　　　　　　　　　 ｿ　 ﾄﾝﾄﾝ　　　　　　　　　　　　　　　　　　　　　　　　　　　　　ｿ　 ﾄﾝﾄﾝ

なんでもいいけどAAウケル

>>700を見てると、頭が悪過ぎてこれまで発言権すらなかった低脳が、
そのやり場の無い煮えたぎるルサンチマンを晒す事ができた最初のメディア＝インターネット
という事に気付く。
そう、そしてきっとそれは、世界規模の衆愚政治のはじまりなんだろうなっと。メデタシメデタシ

悔しさを議論にできず、ただAAを貼り付けるだけのコイツ、
結局のところ民主主義にも寄与できないゴミクズなんだと思う。

ルサンチマンとは、特撮番組「抑圧戦士ルサンチマン」の主人公である。
通常特撮番組の主人公はヒーローなのだが、
この番組においてはそのネガティブな性格設定により、
アンチヒーローと呼ぶのがふさわしいと思われ、事実そのように呼ばれている。

主人公である彼は、ヒーローに憧れる、どこにでもいる本当に普通の少年だった。
しかし成長するにつれ、彼は少しずつねじれていった。
彼は人よりも少しばかりプライドが高く、また並外れて嫉妬心が強かった。
そしてそのプライドの高さは、自分が他人に嫉妬しているということを認めることができなかったのだ。

そんな彼は、そのプライドの高さゆえに、
他人の美点や長所を認めることができず、
従って自分が劣っていることを受け入れることができなかった。
そんな彼でも、さすがに普段はそれほどの嫉妬心を見せるわけではない。
しかし、彼の目の前に、自分が到底かなわない程の優れた人間が現れたときに、
彼はルサンチマンに変身するのだ。

誰がそんなウマイこと言えとｗｗ

ルサンチマン=>706に変身した彼は、敵と戦う。
しかし、その敵は常に、彼にとっては到底かなわない相手なのだ。
ルサンチマンは結局のところ、
負け惜しみたっぷりの捨て台詞を吐いてその場から逃げることになる。

敵に対する憎しみが、
到底かなわない相手に対する嫉妬や羨みであることに気付くまで、
ルサンチマンの戦いは続く。

知能の差って、残酷だねｗ

ここにクソレスつけてる基地外も、こんど生まれてくる時には多少頭が良くなってればいいのにねｗ
心の底から、ほんと不幸な人生ご苦労様、って思うよ。

知能の差の残酷さ

それは、知能の高い者にとっては滑稽な対象でしかなく、
そして、知能の低い者にとっては自分の生まれを呪い、社会を呪い、他人にどす黒い感情を抱くようになる源泉。

この悲喜劇的なコントラストは、とても残酷だと思う。

あんまおもんないなあ
>>710は出来すぎｗｗ

物理屋、数学屋の世界では、知能の差による優劣の差なんて
学生レベルですら当たり前の事だから、
ここで騒いでる池沼のように見苦しい態度を取る奴は滅多にいねぇ。
もしこんな程度で騒ぐ奴が居たら、それこそ「変人」扱いされる。

だけど情報分野はまだ未熟だから、詐欺師もどきの研究者や妄想家が跳梁跋扈していて、
一般人には優劣の差が見えにくい。だから見当違いの嫉妬心を振り回すキチガイが多い。

結局のところ、そんなバックグラウンドの違いもあるのかもな。

それ以前に、コイツは単なる寂しがり屋の素人だろｗ

IT系、特にプログラマーには、心がカタワになってる奴が多過ぎる。
そんなだから、ここみたく本当の精神異常者がIT業界人のフリして居つくような事態になる。
プログラマーの精神衛生をなんとか改善してやらないと、
将来的には引き篭もり予備軍の業界への大量流入を食い止める事ができなくなるんじゃないかな。もう手遅れかｗ

× 引き篭もり予備軍
○ メンヘル/精神異常者

そういえば俺って、他人に本当に憎しみを抱いた事って少ないなぁ。
鈴木バカヒロ相手にするときも、いつもからかい半分だし。

それはお前の方が知能が高いから？

当然だろ。
>>560レベルの話が通じない自称OOコンサル（元某社CEO)と仕事で接してた頃、
ホントこいつどこまでハッタリが通じると妄想するバカ野郎なんだ、って呆れ返ってたよ、いつも。

つうか、実際の所、こっちが相手の知能レベル気にする事って、滅多にないね。
ああコミュニケーションの上手い人だなぁとか、強引なだけで中身が判断できてないタイプだなぁとか、
あるいは知識量や聞きなれない専門用語が多くて判りにくいタイプだなぁとか、
スケジュール無茶過ぎｗこいつ俺に対する指示を自分でもできねぇ癖になに無茶押し付けてくるんだｗ
とか感じる事は多々あっても、知能がおっつかねぇや退散退散ってのは滅多にない。

もっとも、相手に知能レベルで引け目を感じさせる事は、無意識でも、意識的でも多いけど。

なに独り言書いてるんだよナルシスト

誰かさんの得意技が炸裂中だなｗ

洞察力に優れた端的な解説を、間違った相手に晒しちまった後で、
そいつに思いっきりネガティブな罵倒を投げて
そいつの長期記憶に記憶が定着するのを阻止する技ｗｗｗ

もし相手がマゾだったら、罵倒の甘い思い出として記憶にしっかり焼き付けちまうだろうよ

価値のない奴は価値のないところであらそうね

俺的には、10年前レベルの話すら理解できていない「自称オブジェクト指向コンサル」など
最も価値のない存在だと考えるけどね。

20年OO分野に居続けてその程度のお前とは違って、
俺の場合はお前と違って、この10年の間、他にもいくつもの専門分野をこなしてきているわけで。

もはやOOなどからかいの対象でしかない

いや、どっちも価値がないんだよ。
価値があるなら、ビジネスでやりゃいいんだよ。
こんな時間にくだまいているなんて無職ですか？
俺は風邪で休みますが。

OOビジネスなど無理だろｗ
だいたい数百億かけてERP導入しても、カスタマイズに数十億かけて挙句に導入に失敗しちまうような、
土方仕事大好きな国民性だぜ？

理屈が通るわきゃねぇじゃん。開発効率向上なんてもっての他。ちゃんとCOBOLerがJavaできるまで教育投資して、
こいつらが定年退職するまでまたぞろ旧式なJavaシステムを保守し続ける、そんなバカな国だぜ、ここは

>>728
病欠で許してもらえるとは、生ぬるい仕事っぷりだね。
もしかしてあんたずぅーっと休んでも、多勢に影響はないんじゃねぇの？

ああ、孤独なおじさんね。

>>728
明日朝8:10、客先玄関前集合だ。
病欠は認めねぇ。這ってでも出て来い。
以上、業務連絡終了だ

いずれにせよ、このスレで本当に価値のある事を書くと、
その度に彼が半ｷﾞﾚしながらスレを荒すパターンは、
毎度毎度の事ながら困ったもんだｗ

匿名掲示板で恥ずかし毛もなく商売のネタを得ておきながら、
挙句の捨て台詞が「価値のない奴は価値のないところであらそうね」
だもんね。Bizmoの講演活動なんて、ほとんどこっちのネタのパクリに過ぎない癖にｗ

バカ石碑

http://sekihi.net/writer/2046/proverb_abc/1.htm

結局このアホは一体なんだったんだ？
自分の言いたいことだけ喚き散らして
他の奴がなんか言ったらレッテル張りして「アーアー聞こえねーバーカバーカ」って子供かよ
なんか価値があることを言ってればいいがクラス抽出法とかなんて現場じゃとっくに廃れたもん持ち出してるし

高弘の現場では、それはオーバーツ扱い

普通の現場(真っ当な知性を持つメンバーのみで構成されたプロジェクト、たとえば比嘉さんとことか)では、それは日常茶飯事、

廃れたとか言ってるのは脳内妄想大爆発の無職ヒッキー

高弘の現場って何なんだ？
口だけ達者で、動くアプリは一つも作れたことがない現場か？ﾌﾟ

おじゃばよ
大学芋でも食え、なっ

>>738
糞ﾜﾛﾀｗ

祭りは終わりか、いつも出遅れるな。
とりあえず、初心者が本気にするといけないから、間違いだけは指摘しておくか。
オブジェクト指向の動詞だの目的語だのというのは、ほとんどジョークだから本気にしないように。
次に大学教授と大手ベンダーの技術者では、例外もあるが、大手ベンダーの技術者の方がレベルが高いから
間違えないように。
次に、オブジェクト指向で「抽象化してから実装レベルに落とす」のは大間違いだから騙されないように。
普通の人は同じような案件をやった事があるなら別として、未経験の案件でこれが出来る訳はない。
女を設計して香織、素子を作るのは普通は無理だし、失敗して当然だ。
本当のやり方は、香織を設計して、素子を設計する必要が出た時に、女の要素を抽出して分離する。
これが正しい設計だ。

初心者のこといいだしたら、2ch見るなってことになっちまう

わー、てんぺんちいだ＾。
おじゃばがいっぱんろんいってる。
つっこめないよー。

義務のようなものを感じたのであえていうが、
あんたは大抵、土日にはでなくて月曜にの朝か夕
に出るんだから祭に間に合うもの糞もないわけだが。

女の要素......ハァハァ、OOってエロイな
で、女の要素って何かな、やっぱあれ？

ＯＯ原理主義者はもういないみたいだな

・オブジェクト指向プログラミングによるクラス設計を統括する者をスーパーバイザー（OOPS）と呼称する。

> 次に、オブジェクト指向で「抽象化してから実装レベルに落とす」のは大間違いだから騙されないように。
> 普通の人は同じような案件をやった事があるなら別として、未経験の案件でこれが出来る訳はない。

なんつうかさ、趣味で自分の時間で自分のスキルも磨いてねぇクソが、
客から金もらって「初体験」ってどっか間違ってると思う。
普通の技術者は、普段から研鑽して実装技術はとっくに学んでる所が出発点、
だから、いきなり抽象議論から始められるのさ。
規格や標準動向、最新技術に詳しいヲタなんて、その典型だろ？

おじゃばはドメインの方の知識のこと言ってんだろ
って、いちおう釣られとくか

>>740
>次に大学教授と大手ベンダーの技術者では、例外もあるが、大手ベンダーの技術者の方がレベルが高いから
大学教授は、そんなにレベルが低いのか、知らなかった
大手ベンダーの技術者なんて、この業界じゃ技術者と言えないレベルなのに、それより下と言う事は素人並みか？

>>746
お前の程度の低さが伺えるな。
どんだけ井の中の蛙なのかも。

>>748
どっちもどっちもと思いますがやっぱ大きい声では言えませんが
医者も患者３人くらい殺して＊＊＊とか言いませんか

>>740
ちょっと気になったのでコメントします

ジョークではなくて
大規模ビジネスの場合はＲＳ（要求仕様）やＲＦＰから
ともかく基本設計する必要がありそれらの文章は
主語動詞目的語なんちゃらしかないとは言えますね

違うよ。
クリリンの気円斬だよ。

>>749
相変わらず必死だなぁ。
ドメインドメインつったって、
業務ドメインにもピンからキリまであるし、
ましてやドメインは業務だけではない。
COBOLをJavaで書き直すのに必死になってる奴に
COBOLロジック以上の業務ドメイン知識があるとは考えにくいしなぁｗｗｗ

馬鹿は馬鹿なりにちっちゃくなってろってこった

>>752
キチガイが多いからつって、あんまみくびんなよ？
この知ったか野郎

キチガイは多くない。

1：知識と知性がバランスが取れていない椰子と
2：知識が足りていない奴。
3：知性が無い奴。

基本その3種類で、キチガイは多くない。

ちなみに、

長文を流すのは1。
短文で返すのは2。
おじゃばが3。

となる。

おじゃばは気取った物言いが鼻に付くだけで、十分賢い
ジジイ共とキチガイは、その辺わかった上でたたいてんのよ
ザコに尻馬に乗られても、痛えだけ

>>755
ああ、むろんおじゃばの本領は、
暴投気味の言葉のキャッチボールだってわかってるよ。

だが断る（AA略

>>753
判ったから、お前の専門ドメイン言ってみろｗ
まずは２ちゃんかぁ？次は引きこもりドメイン？そして最後は人間失格ドメインか。
なさけねぇラインナップだなｗ

スルーしてやんよ
おらおめえと違って、ミスには寛容だ

ガンダムOO

意味不明な所で相手のミスを突いた気になってる痛い奴発見

ドメインってOOを語る上で重要なのか？
初心者の俺が読んできた本にはドメインなんて言葉は記憶にない

ドメイン オブジェクト指向 に一致する日本語のページ 約 1,980,000 件中 1 - 50 件目 (0.16 秒)

どんだけ〜

ドメインって境界がなけりゃ世界そのものを記述することになるんだが。

世界そのものを記述すると勘違いしてた輩も多かったけどな
「人間」クラスには、こういうメソッドがあるべきだ
なんつってアホなこと言ってた

ドメインってのはPofEAAのドメインモデル、ドメインレイヤー、ドメインオブジェクトのドメインだろ。

>>746
勉強不足だからそうなるのではなく、OOとは元々、そういう設計のために作られた物だ。
ただ573のように勘違いして認識している人は多い。
しかし573の書き込みを見ると、10年前に1年ぐらいやっただけの我流で、そういう設計出来る人物を見た
ことがないと自ら言っている。客観的に考えればそれが間違いだと気が付くだろう。

>>748
もちろん例外はあるが、全体的に判断すればそうなる。
ただ大学教授が馬鹿ということではなく、大学教授の目的はあくまでも人に教える事だからだ。
そのため第一線にいる人達に比べれば、技術の面で劣るのは当然の事だ。
また、748は大手ベンダーをよく知らないようだ。
日本におけるサーバー系、通信系の大手ベンダーと言うと、N、N、F、Oとなる。また外資系だとI、Uだ。
各社、大量の人員を抱えているから、技術の低い人間もたくさんいるが、トップレベルの方では
とんでもなく優秀な人間がいる。
難しくて重要なプロジェクトには、これらの人が関わることが多い。
それを知らないと言う事は、それなりの仕事しかやってないと言う事になる。

ギガデイン
ライデイン
ミナデイン
ドメイン

>>766
なんというかだな。
教授の本業は人に教えることじゃなくて「研究」なんでな。
まぁOO関係ないけどな。

>>766
でも、おじゃばは電卓すら作れないんでしょ

>>766
某ベンダーでかなりでかいプロジェクトやったけど、
Yahooニュースや午後６時にニュースに出るレベルのじゅうような奴。

とてつもなく優秀な奴はいなかったけど。

あ、一個下の同じ名前を関するとこにはいたけど。
２日で全ソース解析した人。

所で、おじゃば漏れも、某ベンダーの名刺２つや３つ
持ってるんだが・・・。
(つーか、自社の名刺使ったことねーな)

もしかして、騙されていないか？

ココの人たちってマトモなコード書けるん？
なんか口だけにしか見えないんだが・・・

好きな言語で良いからソース晒してみ？

読む価値ない奴に限って長文なんだよな。
リアルで話し相手がいないからはけ口にしているんだろうが邪魔だなぁ。

ああ、後だな
1年やって出来ない奴は10年やっても出来ないと思う件について・・・

ドカタを10年やるのもどうかと思う件について・・・

>>773
いや、なんとななるYO。

一番最初にこれだけは覚えろと教えた事を、
半年にわたって、数十度間違えて、
その度に、３０分位説教したら、さすがに一年後間違えなくなった。

まあ、いまだに頭ではなくて反射でプログラム作ってる感じに育ったが。

>>775
その程度の仕事だからでしょ。
コンビニ店員は99%の人間が出来ると思うが、優秀なプロマネになれるのは
10%もいないだろう。
素質、教育、環境とか考えて。

優秀なやつは現場なんかにこねえよ
方式レビューのとき、ちょろっと顔出すくらいで

>>776
そんなもんになれたからどうだっつーのよ
だいたい、優秀なプロマネなんかになれるやつが
この業界を選択してる時点でミスってるだろ

>>778
なんで？
かなり稼いでるし人望あるし、成果も評価もデカイから楽しそうだよ。

優秀なPGは優秀なSEになれる可能性はあるが、優秀なPMとは関係ない。
あとPGとSEはOOに関係あるけど、PMはOOと関係ない。

で？

つまりスレ違いってこった

>>779
稼ぎたいんだったら商売でもやれや
状況の奴隷っつうんだ、お前みたいに俯瞰できないやつのことを

俯瞰

なんてよむの？

>>783
俯瞰出来るお前は何やってんの？ｗ

ふかん

おじゃばのいってるN、N、F、Oのうち、Oってどこ？

プログラマーの上級職がSEって終わってるな。
あんな小間使いのどこがいいんだ？

いちいちあげんな、うぜえ

お前の方が、うざくないか？

>>766
>それを知らないと言う事は、それなりの仕事しかやってないと言う事になる。
結構凄いシステムやったけどな（その会社が日本初のプロジェクトとか、言語系とか）
いなかったな、どこにいるんだ？
まっ、優秀かどうかは自分基準になるからな、おじゃばと俺では違ってもしょうがないのか

>>788
なんで日本ってそういう変な上級職しかないんだろうな
プログラマのままのがいいだろうが
ＳＥなんてなにもできる立場にねーじゃん
なんもスキルもってなくてもなれるぜ。マジで

喧嘩しないで平和にやろうよ

OOネタだと住人が罵倒しあう原因は一体なんだろう？
１．OO自体の完成度が低いため何が正解なのかはっきりしないため。
２．学習不足による知識格差のため。
３．ただ反論したいだけ。
４．2chだから。

１〜４全部っぽいんだよなあ。

http://pc11.2ch.net/test/read.cgi/win/1169994853/

面白いスレ発見

とりあえず、オブジェクト指向、ってネーミングに問題ありすぎ

ねぇパパ、おじゃばがなんか焦ってるよ？
例えば>>573＝>>560の分析/設計手順に問題があるなら、
それを指摘して正しい解を示せばいいのに、
おじゃばったら頭ごなしに否定してかかってるよ。。。

きっと長年勉強しても会得できなかった境地を
すらすらと簡単に説明されて、よっぽど悔しかったんだろうね。

ねぇ、パパ、おじゃばみたいな振る舞いを「負け犬」って呼ぶんでしょ。
ボク知ってるよ

>>740
> > > 次に、オブジェクト指向で「抽象化してから実装レベルに落とす」のは大間違いだから騙されないように。
> > > 普通の人は同じような案件をやった事があるなら別として、未経験の案件でこれが出来る訳はない。

>>746
> > なんつうかさ、趣味で自分の時間で自分のスキルも磨いてねぇクソが、
> > 客から金もらって「初体験」ってどっか間違ってると思う。

>>766
> 勉強不足だからそうなるのではなく、OOとは元々、そういう設計のために作られた物だ。
> ただ573のように勘違いして認識している人は多い。

おじゃばが業界標準手法を否定して、自己正当化しはじめたｗｗｗｗ

バカの国ではおじゃばは王様なんだろうな、一番の大バカ野郎って意味で

結論：　鈴木高広＝おじゃば＝負け犬

>>768
そう思っているなら、優秀な教授にはなれないよ。
でも768の考えを持った勘違いした教授がいる事も確かだ。

>>769
電卓は作れるぞ。つーか作れない訳ないだろう？

>>770
2日で全ソース解析した人がいたんだろ？何で現実を否定する？
もっと知りたかったら、手っ取り早くベテラン社員に聞いてみな。

>>771
本当に優秀な人間は偉くなっても多少のコードは書く。勘が鈍るからな。
ソースは晒せないが、IBMのHP見ればサンプルが見られるだろう。

>>775
775が773より優秀だと言う事は分かった。

おじゃばよ
サンプルコードで学習か、それでは100年かかっても大学芋の飴の
とろみがでないぞ

>>800
>2日で全ソース解析した人がいたんだろ？何で現実を否定する？
>もっと知りたかったら、手っ取り早くベテラン社員に聞いてみな。

緊急時に、ベンダーの人が別会社の人に頭さげてソースレビュー
したから。ちなみに場所はベンダーの社屋だよ。

それに、大手ベンダーの一部の優秀な奴って研究所にいて、
下界の仕事には、手出さないんっつー話、この板とかで聞くけど。

オレオレ

>>776
優秀な人は多くは必要ない。
少数の優秀な人間と、多数の命令通り動くそれなりの人間がいればいい。

>>777
いるのは確認できたって事だな。

>>778,783
プログラマが単純作業だと言う人がいるが、そんな事はない。
最初はテスターや簡単な仕事をこなす日々が続くだろうが、それはどの業界でも同じ事だ。
技術革新のスピードを考えれば、先生や医者、弁護士より難しい職業だろう。
土方だとか言っている人は、新人か、向上心を失ってサボっている人間だ。

>>787
日本の通信御三家と言うのがあり、NTTに交換機を納入していた会社を言う。
それがNEC、富士通、沖電気。今はHPやシスコなどの外資も参入してきて、御三家は過去の物だが、
3社とサーバや通信系に関してはそれなりの人材と技術を持っている。

>>788,792
SEの上がPL。なれたら威張っていいよ。ただし10人以上のプロジェクトでな。
PG能力のないSEは偽物。

３年前には存在すらしなかった技術を
使う仕事ってほかに無いよな・・・

しかもその技術をほぼ独学するのが当たり前で知らないやつは必然的に淘汰されていくと言う異常な世界

しかもその量と難易度が半端じゃない。

ほかの仕事では自分の担当部署の仕事ができればそれでいいが、
システムを開発するときには、関係している複数の部署の仕事を
詳細に理解しなければならない。

>>804
>サーバや通信系
あれ沖電気ってサーバ系強かったっけ？
交換機なら話は別だけど。
基本的にコールセンター向けがメインだろ。

話、別だが、おじゃばって大手ベンダーの
優秀な奴ってあった事あるの？

　　　　　　　　　　　 ＿
　　　　　　　 r-､' ´　　 ｀ヽr-､
　　　　　　　ｨ7　/l: ハヽﾊ ﾄヾ 　　 駄スレを隠すことは、この俺が許さん！
　　　　　　　 '|l |'´_`　´_ ｀| || 　　　信念に基づいて行動する。
　　　　　　　 |　|´ﾋ} 　 ﾋ}｀! l|　　　それを人は正義と言う。
　　　__ノﾞ).　从 l,　　_'_. 　|从　　　今俺が行ってることは、上げ荒らしではない。
　,_'（＿ ﾉ_ヽ　ヾl.＞ - ,イ;ﾘ　　　　正義という名の粛清だぁ！
　{ f:ﾃ} {'f:ﾃ}',／＼ヽ--/／ヽ 　　　
　ヽ,r─‐ ､ｨ .､､ i l＞Y＜! i　'､ 　　　バーニング！
　/ iゝ＿ﾉ iヽ　/l　　 |l　　l 　 ',
　lﾝヽ/ムノじ

あえて言おう
「メタプログラミングは生産性を下げる」と

とっくに動くコードが出来上がってるのに
ああでもないこうでもないと
コードをいじくりまわすためだけに存在する
開発者のオナニーグッズである、と

いやメタプログラミングこそがプログラマーの魔法の源だよ。
Lispのマクロとかはちゃんと勉強した？C++のテンプレートは使いこなせてる？

テンプレートはともかく、Lispのマクロなど…

>>797
正しい方法は740で解説済み。
負け犬は798。痛々しいのは573。

573は、自分の考案した設計が出来る人間に、10年間会った事がないと言っている。
普通は自分が間違っていると考えると思うが、自分を除く全員が馬鹿だと言う思考になっている。
だから俺が何を言っても馬鹿扱いされて終わりだと思うが、純粋に質問がある。
573が正しいと考えると基準って何だ？

>>798
一言だけ言わせてもらえば、560の言っているのは業界標準手法ではない。

>>801
一般人が参照出来る例を示したまでだ。

>>802
前半の文章は意味が分からない。普段はベテラン社員に聞けないと言う事か？
後半は嘘。研究者に対する妄想だ。研究というのは大半が地味な調査だし、研究者には問題があれば
こき使われる存在だ。

おじゃばよ
お前はPLなのか、PG能力がないお前がよく言うよ

おじゃばおまえバカだろ。
まずプロトタイプ作って、次にライブラリ抽出するだなんて、
プログラミング初めて１年目の人間が覚えるべきスキルだぜ？
そんなもんを「正しいクラス設計法」だなんていいだすから、
お前はバカ扱いされるんだ。

お前はいい加減、お前自身のバカさ加減をわきまえろ。

おじゃばが新川で「設計？」していた証券アプリを見た事があるが、
おじゃば本人はコードなど書けるはずもなく、
どっかから拾ってきた20代コーダーにコード書かせて、
「これがサンプルでござい」ってパワポにコード貼り付けるような有様だったぜ。

そのコード内容見れば、コーダー本人もおじゃばも、
ろくなコードセンスを持っていない、自分自身でフレームワークなど
構築する能力もない底辺レベルの人間だという事がよく判る。

そんなレベルの奴が、匿名掲示板に来ると、何故か自信満々になるんだよな。

もまぃら見事に釣られすぎ

鈴木高弘、朝から涙目

おじゃばよ
相変わらず人気あるな

高弘って誰だよ？ｗ

LL塊で、CLOSについて講演する！とか立派な事抜かしておきながら、
当然ロクなプレゼンも作れず、イベントスケジュールが押してたのをこれ幸い
グダグダな講演を「時間が限られているので・・・」と誤魔化した人。

彼が、一定レベルの知的階層を満足させる講演をしている姿など、
これまで一度も見た事ない

朝鮮民族のアホコテはスルーしれ。

>>808
沖電気は少し弱いな。
大昔に交換機の技術を応用して汎用機を作ろうとした時に、NECと富士通はやったが、
沖電気はやらなかったらしい。

大手ベンダーの優秀な人には何人か会った事がある。
ただ高いレベルになると専門色が強くなるため、全ての分野ですごいと言う訳ではなく、
ある分野ではすごいという感じになる。
あまり詳しくは言えないが、通信の規格に関するRFCを全部知っている人や、分散技術の事になると
話が止まらない人。ベテランSEが匙を投げたボロボロなシステムを土日でほぼ完璧に修正してしまう人。
はっきり言って変人が多い。

おじゃばよ
DNSのRFCすら読み下せなかったお前が言っても説得力はないぞ

おじゃば氏は確かに詳しいけど、まさにまとめ役って感じで専門スキルは弱い気がする・・

>>825
プロのソフト技術者はソフトウェア技術（周辺技術含む）は当然として、さらに専門分野の知識
が要求される。キャリアを積めば積むほど専門分野(および関連分野）の深い知識が必要。
でも、ドカタは専門分野の知識はあまり要求されない。コーディングできればOK
おそらく、おじゃばは、ドカタのまとめ役じゃないのかな。ある程度のことは広くこなせるが、
自分の専門分野を持たないPG、つまり何でも屋じゃないのか。

おじゃばよ
鋭い指摘>>826が入っているぞ

>>814
C++使える人が俺の書き込みを見れば、コーディング出来ると言う事は分かるはず。
それが分からないと言う事は、814はC++を使えないということが分かる。

>>815
確かに構造化プログラミングではその設計が常識だ。
しかしOOでは違う。つまり815は構造化は分かっていても、OOは分かっていないと言う事が分かる。

>>816
妄想乙としか言えんな。
ところで新川ってどこの企業？

>>822
この朝鮮人がどうとか言うのの意味が分からない。
俺は民族主義とか差別に疎いので、朝鮮人と言ってもアメリカ人や中国人などの国籍を表す言葉にしか
思えない。つまり朝鮮人と言われて本当に朝鮮人だったとしても、それが何か？って事だし、
日本人だったら、妄想乙って事だろう。

>>824-827
俺の専門分野は昔から言っているように、通信とサービス。
ここで話しているのは一般的な技術。
前に俺の専門分野の話をしたら、全く反応がなかったので自粛している。
ちなみにWEBサービスの話ですら、途中までついて来れたのが1名。添付ファイルの話で全滅。
SIPや分散ハッシュ技術の話などは、ほとんどスルー。
さらにサービスの方はWEB2の話は知っていたとしても、マッシュアップと言う言葉を知っている人すらなし。
携帯電話を利用し、○○○○○○○○○○を使った○○○○○サービスの話など通じるはずもなし。
（○は企業秘密に関わるので伏せ字）

本当は俺もサービスの話をしたいんだよ。

>>828
朝鮮人はどこの国籍の人？　
ちなみに>>822は朝鮮民族と言ってるんだが、それが、なぜ朝鮮人になるるんだ？
高能おじゃばの朝鮮民族-＞朝鮮人になる思考って、俺みたいな低能な香具師は？？？？？？？？だぞ。

女が欲しいスレからの転載だけど
http://pc11.2ch.net/test/read.cgi/prog/1160275819/

以下の実装がオブジェクト指向わかってないという指摘があって、
どこが悪いのかがよくわからないです。
個人的には、getGalをOsuクラスのメソッドにすべきってことかな
と勝手に解釈したけど合ってます？

getGal(Osu osu){
if(!osu.isIkemen()){
System.exit(0);
}

}

>>831
getGalメソッド・・・？
随分特殊な場所ですね。そのメソッドの定義されているクラスが表す場所は。
しかも、その場所は雄がイケメンじゃなかったら世界を崩壊させるのですか。

>>832
exitさせたらまずいっすね（汗）
すいません。Java知らんつうか、スライム倒すのに数ターンかかる
雑魚ＰＧです。
C++で言うと以下のように記述せいってことだと思ってましたが
間違ってそうですね。。。
じゃあ何がダメなんだろう？
わかる人います？

bool Osu::getGal(void) const
{
if (! isIkemen()) return false;
// 処理
}

C++は知らんが、
getGalメソッドの戻り値がboolじゃおかしいだろ
そこは女返すか例外投げるトコ

>>834

>そこは女返すか例外投げるトコ

おおっ！
その通りだｗ
あかん。憂鬱読み直してくる。

いや、イケメンってのはクラスなんだよ。
イケメンの役割を果たせるのは極一部の
美形家系の血を継承したクラスのインスタンスのみ。
isIkemen はインスタンス毎に異なるのではなく、
イケメンとブサは別世界の生き物ってこと。

class Osu {
// -----------------------
// this is pure virtual class.
// -----------------------
private:
　virtual bool isIkemen() const = 0;

pubic:
　Gal *getGal() {
　　//-------------------------------------
　　// 内部でisIkemen()をよび、trueなら生成成功
　　//-------------------------------------
　　return new(this) Gal();
　}
　//-------------------------------
　// Galのoperator newとfriend接続する
　// →isIkemenをコールさせるため
　//-------------------------------
　friend static Gal *Gal::operator new(Osu *);
};

>>829
おじゃばさまが得意になって自分の分野の事話しているので
調べてみた。

WEBサービス http://e-words.jp/w/WebE382B5E383BCE38393E382B9.html
添付ファイル 　http://e-words.jp/w/E6B7BBE4BB98E38395E382A1E382A4E383AB.html
SIP http://e-words.jp/w/SIP.html
分散ハッシュ技術 http://ja.wikipedia.org/wiki/%E5%88%86%E6%95%A3%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB
WEB2 http://e-words.jp/w/Web2022E0.html
マッシュアップ http://www.sophia-it.com/content/%E3%83%9E%E3%83%83%E3%82%B7%E3%83%A5%E3%82%A2%E3%83%83%E3%83%97

Webは専門外だが、
情報を効率よく垂れ流す仕事である事は良くわかった。

>>836
やら。そんないやリアルな世界観。

>>837
よ、読めん。（汗）
直感だけど何かが違うような。。。

・Shapeクラスのdraw()を純粋仮想関数にして
　Circle,Triangle・・各派生クラスにオーバーライドするって感じで
　使用するのが常道と習ったので、IkemenというOsu独自の
　メンバ関数をオーバーライドするのは違和感があります。

・friend使ったことないのでよくわかんないですけど、Osuクラスで
　Galを生成するっておかしくないっすか？脳内ならともかく。

こんな感じ？833訂正版。

bool getGal(Gal* gal)
{
m_girlFriend = INVALID_VALUE;
if (! isIkemen) return false;

// 金、身長等がゲットしようとするGalのレベルより上か
if ( gal->CheckManStatus() ) {
m_girlFriend = gal;
return true;
}
return false;
}

bool返さなくでもいいかな。

訂正
×
if ( gal->CheckManStatus() ) {
○
if ( gal->CheckManStatus(m_money, m_gakureki) ) {

ん〜でもこれだとisIkemenも含めて、galで判定すべきか？
混乱してきたｗ

イメージとしては、OsuもGalもインスタンス持っていて
osuがgetGalを試みて、galがosuを判定してその結果を返すってのが
一番現実に沿っていると思うのだけども。。。

バカばっか…

SIPなんて腐れプロトコルはさっさと死滅しろ。
電話は電話らしく電話だけやってろ。
誰だ呼制御でネットのセッション管理しようなんて提案したヤツは。
電話で多対多通信やろうなんて言い出した奴マジ氏ね。
変な拡張し過ぎてゴテゴテしてるし、
大人しくP2Pセッションだけ見てろよカスプロトコルめ。

> ちなみにWEBサービスの話ですら、途中までついて来れたのが1名。添付ファイルの話で全滅。
> SIPや分散ハッシュ技術の話などは、ほとんどスルー。
> さらにサービスの方はWEB2の話は知っていたとしても、マッシュアップと言う言葉を知っている人すらなし。
> 携帯電話を利用し、○○○○○○○○○○を使った○○○○○サービスの話など通じるはずもなし。
>（○は企業秘密に関わるので伏せ字）

なんだｗ自慢する割に俺の職歴書の1/3程度にしか満たない、しょぼい自慢だな。
俺の職歴書の残り1/3は最近のGoogleサービスと被ってたりもするがｗ

自慢あるなら早く自慢しろ。ボロボロの火達磨にしてやるからさぁ

>>840
> イメージとしては、OsuもGalもインスタンス持っていて
> osuがgetGalを試みて、galがosuを判定してその結果を返すってのが
> 一番現実に沿っていると思うのだけども。。。

これは837の設計ポリシーの輪郭なんだが。

friendをろくに理解もせず、腫れ物扱いしているようだな。
そのレベルでは、基本的に直感で判断してたら大概しくじるよ。

最初から公開すりゃいいだろ。
friendはヘタクソのための仕様。

だな。
riendを使用せざるを得ない局面が生じること自体、
既にアプリケー ション作成者の設計ミス・能力不足

Webサービス自慢、まだぁ？
SIP自慢まだぁ〜?
分散ハッシュ自慢、まだか？
Web2 (おいおい.0忘れるなよ)とマッシュアップって、もう死語だと思ったがｗｗｗ

あと携帯電話で伏字しまくりの恥ずかしい自慢まだぁ？
ヒルズの携帯系ベンチャーのPMオファー断ったオイラとしては、
素人の考える先端携帯サービスの妄想具合というのは、なかなか興味がある。
いやまじで

どこまで行っても言語仕様。

class man{

　　function nanpaFromWoman(woman woman){

　　　　　　　return self;
　　}
}


class woman{

　　function nanpaFromMan(man man){

　　　if(man.isGoodLooking()){
　　　　if(man.isRichMan()){
　　　　　if(man.isCelebrity()){
　　　　　　if(man.isSingle()){

　　　　　　　return self;
　　　　　　}
　　　　　}
　　　　}
　　　}
　　}
}

man man850;
man gay;
man* gay850;

gay850 = man850.nanpaFromWoman((woman)gay);

おじゃばよ
wsdl異環境結合試験もできないお前がWebサービスを語るな

>>844

>これは837の設計ポリシーの輪郭なんだが。

そうなんすか。すいません。
読めるようになってから意見します。。。

まてまて。
無節操にfriendを使うと弊害が起きることをわかっていない。
というかオブジェクト指向の基本理念をわかっていない。

また理念か（ｗ

なにげに>>849は神
おじゃばよ
すこし見習え

そんなエッセンスだけで理解できるおじゃばかよ

今週もおもしろかったな


ガンダム

>>843
> 自慢あるなら早く自慢しろ。ボロボロの火達磨にしてやるからさぁ
うはｗ　楽しくなってきました。
おじゃばに大恥かかせてやってくださいまし。
そんで、もうアイツがここにこないようにしてほしい。

>>859
おじゃばはどんなに叩いてもすこしオフセットしてそれらを捕らえるんだな
だから結構打たれ強い。それとオフセットした自分の解釈をこちらの仕様出し
が悪いと開き直ってくるのが特徴だな。

おじゃば血達磨ｗ
ちーん！

自演待ちか

長いこと張り付いてやがるけど、結局オブジェクト指向理解できてねぇんだなｗ＞おじゃば

言語仕様を承知でレスるが、、
>>845 >>846
friend はコンストラクタを制限する場合に良く使う
例えば、俺は、ファクトリー (あえてGOFを意識してない) を簡単に実現する為に使う。
--- some_library.h ---
class target {
 friend target * target_factory( );
 target(); // private
};
// target_factory()は使う側が実装
------
ケースとしては、GOFのAdapterがAdapteeを実体化する際に使ったり。。
(Adaptee候補が複数あって、コンパイルの際に決めてしまえる場合とか、、->log関係とかな)

厳密にGOFのファクトリー(両方)を実装する場合もfriend使った方が安全じゃないか？

なるほど。確かにfriendを使った方が安全そう。
クラス間の依存関係が強くなりすぎるからどこでも使えばいいってもんじゃないだろうけど、
こういうイディオムもあるってことで覚えておこう。

ぶ
あからさまな自演とはこのことか！

>>864みたいな良識をもって低脳どもが書き捨ててく暴論を訂正してくれる人が
未だ見守ってくれていることに呆れ^h^h感動した

>>864
それだけの理由だったら「使わない」とルールを決めた方がいい。
個人でやるならOKだが、チームプレーの場合は玉石混交で、
あんたは分かってても周りはわからんちんだろ。

>>868
なんでそっちへはなしをもっていくの

自分を有利にするためですが？

オブジェクト指向を言語仕様以外で語っても意味ないな

>>869
正直ここを無視したら設計なんてやめちまったっていいと思うんだけど・・・

>>864
C++はよく分らんが、普通に Strategyを使えば良いんじゃないか？

>>872
コーディング規約と設計にどういう関係が？

あぁーあ、今日が一番つらいわ。
例のMBA役員には先週末に説教電話して、コミュニケーション断絶状態、
よっぽど辞めてもらいたいと思ってたけど仕事の受け皿として残さざるを得ないと判断したボンクラどもは、
相変わらず新業務引き継ぎそっちのけでちゃっちいFLEX案件(クライアント側onlyｗｗｗ)ばっかやってるしw

こんなバカども放置して、
9末で辞めちまえばよかったよ

あ、これスレ違いな誤爆ではなく、
FLEXでOOやってるつもりになってる連中(実態はクライアント側onlyのWebコンテンツ屋)に対する嫌味な。


FLEX RIA連中のアイデアは、
俺に言わせりゃ10年は遅れてる。
1996 JavaApplet(東京三菱銀行案件における実用化)
1997 JavaServer(プレJ2EE,プレXML,プレWebサービス)
199X XMLベースのリモートSWING(IBM alphaworks) ← いまここ

なんで奴らこんなに古臭いことに熱中できるのか謎だ。一体この10年間何してたんだｗｗｗ