オブジェクト指向は戦場では必要無し　その２

構造化ジジイのぼやきはいらない。
同じアンチでも、もっと最新の技術をもった人の
「まだ OO で満足してるの？」という意見を聞きたいと思った。

(最新の技術だから必ずいいという意味じゃない、未知の技術の利点と OO の欠点を比べて欲しい。こう書いておかないと、「新しければいいと思ってる OO 信者アフォ」とか書く奴がいるからな、今これを読んでいる君のような奴が)

>>615
同意。
構造化がOOのサブセットである事すら気づかんアフォは
逝ってよし。

＞今これを読んでいる君のような奴が

（どきっ！）

>>615=616
同意。

>>613
信じる初心者がいたら、いくらなんでも可哀想だよ…と書こうと思った瞬間 >>612 が目に入った…。

>>612
基本だから実行して結果を確かめておけ。

>>615=616=618
同意。

６１６は俺だけど、
６１５は違うぞー。

ちなみに６１３の元ネタを書いたのは
俺だよ。
コンパイラスレはほとんど俺だったりして・・・
スレ立てたのは俺じゃないけど。
コピペされるとちょっとうれしい。

= で結ぶのは同一人物という意味だったか…。
俺は自作自演はしたことないっつーの!!
(そのかわり、俺の発言で止まるスレがよくある…ある意味 本当の真・スレッドストッパーな俺だ、よろしく。)

（´-｀）。o ○　（自慢か・・・）

（´-｀）。o ○　（本当に止まったりして・・・）

>>624
それを書いてる時点で >>622 が終わりじゃないという罠。



にしたい俺…………………………。

悲惨な >>615 がいるスレはここですか………マジ鬱。

ﾊｧ(ﾟДﾟ)??　　氏ねよｳﾞｫｹ
Ruby!!!!!!!!!!!!!!!!!!

>>627
Ruby 荒らしがこんなに嬉しかった事はない…。
僕には帰れる所あるんだ……

　　　　　　　　　／⌒彡
　　 　　／　冫､ ）)
　 　　/ ~ヽ ` , （(((　　ﾃｨﾓﾃ
　　　　　 　　|　＼ y　 ))))　　　ﾃｨﾓﾃ〜
　 　　|　　 ニつ))つ
　　　　　 　　|､ー‐　< ((
　 　 /　　　ヾ　＼、
　　　　　 ／/　しヽ＿＿）〜

このスレに居た人は >>613 のを実行して、みんな PC が使えなくなってるんだな。
ってそんなにみんな UN*X 使いばかりいたのかよ！

>>615
> 構造化ジジイのぼやきはいらない。
っつか、このスレのアンチ OO は構造化さえ怪しいと思われ。

いーよなアプリ屋は設計手法が洗練されてて・・・
インフラ屋はそんなのねーから毎回毎回起こしなおしだぜ（号泣

ウィルス送ってみろよ。最強のウィルスバスター君が跳ね返すぜ!！

[email protected]

>>633
送ったけど届いた？
実行してみてよ。
どんどんファイルを消してくよ。

>>630
cygwin

まあ、オブジェクト指向ってのは技術の無いハッタリ一発屋が起こした
革命みたいなもんだったな。
結局、変な造語振りまわして信者以外を排除する程度の
技術とは関係無い利権確立行動でしかなかった。
この業界にまた詐欺師が増えただけ。
くだらん。

構造化すら怪しいアンチが無関係ネタ攻撃中ですね。

>>635
でも、それじゃ cygwin 環境がすっ飛ぶだけじゃん？

>>636
ちなみにあなたの書き込みには気付かなかったので >637 はあなたは含んでませんので。
でも、内容の無さはさすがアンチですね。

>633
捕まらないようにな。

>634
わざわざ、作ったのかなぁ。
ワイルドカードでガリガリやればできちゃうし。

>>637
たしかいまのcygwinって上のディレクトリをmountできるんでなかったっけ。

>>640
そうだったね…デフォルトで /cygdrive/ドライブレター にマップされてた…。
って事は cygwin 入ってる人はマジで注意しなきゃ……って
cygwin 使ってる奴で rm 知らない奴はいないか。

>>641
>構造化すら怪しいアンチが無関係ネタ攻撃中ですね。
無関係ネタ攻撃中ですね(w

>>638
ワケ判らん用語を振り回せば「内容が有る」と思ってる厨房発見！

>>641
でも /cygdrive は明示的に名前を指定しないと見えないから /* では
引っかからないぞ。

mount コマンドを使って明示的に mount してるやつは rm -rf で消えるけど。

>>643
637, 638 のどこかに分からん用語があるの？

しかし OO に対して技術的な批判はアンチからは一つも出てこんな。俺が書いた
474 とかは、ある意味で OO 信者に対する批判なんだが。

あーあー、今日は（昨日か）せっかくこのスレが正常化したと思ったのに

お前ら、unixエミュレータごときで普段来てない戦場スレに（以下略）

粘着だなあ

理念や構造論なんてどうでもいい。

俺はオブジェクト指向とかどうとかじゃなく
単に生産と保守、コードの簡素化をする為にｃ++（ＯＯＰ）を
使ってるだけだ。
使いたいやつは使え。使いたくねーやつは別に否定するな。
つかってて満足なやつだっているんだ。

論なんてどうでもいい。
俺は仕事の為に戦ってるだけだ。
お前らプログラマーだろ？？
もっと頭やわらかくしろよ。
プログラマーじゃねー設計しかやらんやろうはひっこめよ。
俺はプログラマーだ。
設計もやるしコードもばりばりかく。

> しかし OO に対して技術的な批判はアンチからは一つも出てこんな。俺が書いた
一つも？
あんたこのスレの何を読んでたの。

アンチの技術的 OO 批判は出た瞬間に抹殺されるので気付きにくいんでしょう。多分。

すぐに何も言えなくなるアンチ達。
口癖は「難しい言葉を並べてわかったような気になってる」
OO を知らないから OO 用語を知らないだけ、
そう、アンチは OO を理解してないで叩いてる。

技術的批判が瞬殺されるはずだよね、敵についてほとんど何もしらないんだもん。

>>649
ひとつでもあったと思うなら、挙げてもらえませんか?

>>648
分析はやらんのか？

分析があまりいらないシステムも多いけど、ビジネスの意思決定支援システム
とか言い出すと

　そもそも、おたくの会社が考えてるビジネスって何だよ

ってあたりから理解しないとシステムの作りようがないから、クライアントとプロ
グラマ側の人間と共同で、時間をかけて分析しないと設計まで辿り着かんぞ。

>>649
リダイレクタ使ってリンク張っとけ。じゃないと Kusakabe って呼んじゃうよ。

OOってクラスライブラリ変わると、まったく別の言語ひとつ
覚えることに匹敵するほど手間かかる。。。

>>654
それはそうかもしれんけど、それって別にOOの責任じゃないんでは?

関数ベースのライブラリでも、Javaとかのクラスライブラリに
匹敵するだけの機能を揃えたら、やっぱり同じだけの手間がかかると思われ。

>>654
安心しろ.NETは全部一緒だ。

>>650
ＯＯ派がデタラメ並べた長文載せるんで呆れてるのさ。
デタラメには反論できないからね。
本で読んだ事そのまま吐き出してるのかもしれないが。

Rubyこそ最高の言語！

>関数ベースのライブラリでも、Javaとかのクラスライブラリに
>匹敵するだけの機能を揃えたら、やっぱり同じだけの手間がか
>かると思われ。

いや関数のほうがフラットにアクセスできるからどれを使えば
よいのか探すだけ。構造体があっても中身見ればわかるし。
クラスだとそうはいかないことは分かるよね？

>>659
いやクラスのほうがフラットにアクセスできるからどれを使えば
よいのか探すだけ。

ん？

>>659
いまさら MFC (これはこれで糞) 使わずに Windows API を直で
呼び出す気はさらさら起きないんだが。

>>657
> ＯＯ派がデタラメ並べた長文載せるんで呆れてるのさ。
> デタラメには反論できないからね。
> 本で読んだ事そのまま吐き出してるのかもしれないが。
長文ねえ…
2chのレスすら「長文」なんていうようじゃ、まともな技術書読んだことないんだろ。　（藁
今まで読んだ中で一番長かったのは、何ページの絵本でちたか？

Ruby >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>1
お前が（もうすぐ）世の中に必要でなくなるよ。

>>1
お前が（もうすぐ）世の中に必要でなくなるよ。

>>1
お前が（もうすぐ）世の中に必要でなくなるよ。

>>657
>デタラメには反論できないからね。
たしかにデタラメには反論できないでしょう。
しかし、あなたはデタラメであることは分かっているわけです。
デタラメであることを示しましょう。

>>659
>クラスだとそうはいかないことは分かるよね？
だれもが分かるとは限りません。
あなたには分かっているのですから、比較をするなら片方の特徴だけを
出すのではなく、両方だしたうえで比較しましょう。

戦場では必要なしっていう意味は、
例えどんなに高度な機能を有していようと
生身の凡庸な人間が使いこなせるシロモノじゃないのなら
それは無いのと同じことだ。こういうことだったよね。
OOの場合、設計で労力を食うからね。
組みながら完成度を高めていくってやり方の人に不評なのも
なんとなく理解出来る。

組みながら完成度を高めていく方には、リファクタリングは不評なのでしょうか？

>>668
はあ？それ、どんなOO設計の話なんだ？
っつーか、ウォーターフォール的な構造化分析・設計よりも
iterativeなOO分析・設計のほうがはるかに
> 組みながら完成度を高めていくってやり方
を支援するのだがな。

もちろん、間違った組み方をして辻褄合わせに設計を直す、なーんて厨房的なのは
どのみち救われないがな（W

>>659
>いや関数のほうがフラットにアクセスできるからどれを使えば
>よいのか探すだけ。構造体があっても中身見ればわかるし。

「フラット」と言われても何の事だかわからんなあ…

ただ、

　関数なら、関数名さえわかればいつでもどこでも呼び出せるが、
　OOの場合、対象とするオブジェクトを取得できないとメソッドを
　呼ぶことができない。

という意味ならわかるんだが。

実際、OOでは、各オブジェクトについて、どのオブジェクトへの
参照を持たせるか、という話は割と重要な設計ポイントになるし、
(だからクラス図なんか書いたりするわけだが)そこでしくじると
後でえらい目に遭うことになる。

しかし、ライブラリにある程度複雑なことをやってもらおうと思ったら、
ライブラリの側が何らかの状態を持つことは避けられないし、
その状態を「ひとつしか保持できない」と困ることもある。

汎用的なライブラリなら、Cでも

「第1引数として構造体へのポインタを渡す」

なんてことをやってるが、これは表記が違うだけで十分OO的では
ないかな?

…こういう意味じゃないというなら、解説してくれ。659よ。

>>671
> ライブラリの側が何らかの状態を持つことは避けられないし、
手続き型でも、状態が絡んでくると

　関数を、いつでも好きなタイミングで呼んで OK

という世界ではなくなるよね。Win32 でウィンドウを開くような場合

　1. ウィンドウクラスを RegisterClassEx() して
　2. 登録したウィンドウクラスに対して CreateWindow でウィンドウを作り
　3. ウィンドウプロシージャで WM_CREATE を捕まえて初期設定を行い
　4. ShowWindow でウィンドウを表示して
　5. UpdateWindow を呼び出して WM_PAINT メッセージをキューに入れ
　6. WM_PAINT を捕まえて表示内容を初期化する

となる。HWND やウィンドウクラス名は、実質的に「オブジェクト」へのポ
インタだよ。

まあMFCがOOって呼ばれてた時代もあったわけだし、
時代は変わったよね。
MSもMFCはクソでしたをやっと？認めたみたい。

>>673
> まあMFCがOOって呼ばれてた時代
あったのか？　MFC は OO 的なクラスライブラリというより Win32 API の薄い
ラッパとして出発して、その後も機能が肥大化はしてきたが、基本的に Win32
API のラッパという指向は変わってないと思うんだが。

OOを推進するよりも、原点であるCに立ち返って、
Cの欠点を埋める新しい言語、コンパイラを作るってのは？
マジな話で

>>675
Java

>>676
いや、C#

MFCってこれからは完全に死亡なんでしょうか？
今からそれをやるぐらいなら、.NETやる方が
いいんでしょうかね？

WindowsプログラミングはCでしかやったことがないので。

>>678
このスレで聞くより VS.net スレで聞いた方がいいと思うが。

ちなみに VC++.net でも MFC はサポートされてる。

>>675
じゃ、Cのどこが気に入らないのかを具体的に挙げてみれば?

てか、Cで、構造体とmalloc()の使い方がわかってりゃ、クラスと
インスタンスなんてわかったも同然だし、共用体の使い方がわかってりゃ
継承もわかるだろうし、それでswitch caseがうざいと思えば、
ポリモフィズムもわかるだろう。

…てことは、このスレのアンチは、Cもろくに使えてないんだろうね。

オブジェクト指向の信者ってなんつーかウザイ。
ブーチがどうとか、ハンバーグがどうとか、
見てて痛すぎるのがおおいです。
よくGNU信者がウザイ言われたりしてますが、
そんなOO信者のレベルには程遠いな（ｗ

痛さとアホさの点では彼らは群を抜いてます。
OOが胡散臭く感じられる原因はあなたの周りの
ｷｼｮｲ信者でしょう。

Ｃの欠点・・・。
ＯＮ−ＧＯＴＯが排除された。

signal & raise で充分でそ

みなさん！始まりました!!アンチの難癖攻撃ですよ〜〜！

>>681
相変わらず技術的な問題点の指摘はないのな…

>>685
おれはOOがキライだなんて言ってない。
信者がウザイんだよ。oosquareとかを
読んでると鳥肌立ちっぱなし。

なんか >>680 が激痛なんですけど。

oosquare って、
国内のWeb上では数少ない、
まともな OO全般の情報源 でそ。

DQNなあなたが見て、理解できなくてもしょうがない。
あれって、
国外の本スレ見ながら、評論/コメントしてるスレみたいなもんだからなぁ。

>>688
oosquare-mlの間違い。
Web上のものはよく勉強させてもらってます。

>>686
いつから、ここは感想文を書くスレになったんだ？

最初からだろ

べつにＯＯを否定するのはかまわないけど、否定するならするで、
べつのスタンスからＳＥとＰＧの作業領域にある問題を解決する
方法論ってものを考えていってほすぃ。
否定だけじゃ、なにも進まない。
ＯＯを肯定することや否定すること自体には意味ないのよ。
もう、やめてけれ。

おいおい、従来のスタイルと個人を攻撃したのはＯＯ側が最初だぞ。

>>693
OO 側って何よ？

２ちゃんねるで書き込んでる人間は、特定の指揮系統の元で行動してるわけじゃ
ないんだから、その手の陣営わけは意味がない。しょせんは個人の問題だ。

（で、感想じゃなくて技術的な話はないのか？）

>>693
被害者意識が強いのでは？
「OO は以前の方法に対して この部分がこう素晴らしい」
と論理的かつ的確に説明してあげることが、
従来のスタイルと個人に対する攻撃だというのなら話は別だが。
(それに、OO は「従来のスタイル」を内包しているから、そもそも攻撃なら自己否定になる)

>>689
俺は別にアンチじゃないけど、oosquare-ml はマジでキショいね。

>>693
>ＯＯを肯定することや否定すること自体には意味ないのよ。
ＯＯ派アンチＯＯ派（そんなんがあれば）を肯定することや
否定することにはもっと意味がない。
くだらねぇ・・・おまえ。

おいおい、従来のスタイルと個人を攻撃したのはＯＯ側が最初だぞ。
ふーん

>>687
ん? どこが?

まずいところがあるなら指摘してほしい。

で、結局あんたらの言うOOって何を指してるの？
C++？

>>700
それは (one of) OOPL だろ…。

>>700
俺は〜なんだろうね、OO が解った！って思ったのは 結城氏のデザパタ本読んでた時かなぁ…。
それまで俺のやってた事が、ここでいう「クラス指向」に他ならないって事に気付いたので。

「お前はOOを理解していない」
これを言うのは人の勝手だけど、
それじゃあんたの理解するOO的要求定義〜テストを
説明してくれよ。

上のような言葉を吐くのにろくなのはいないとおれは決め込んでる。

>>703
ほんとに勉強したいのなら、こんなこころで聞かずに、定評ある書籍を読む
ことをすすめるが。

だいたい、まじめに語ったらいくら端折っても「UML モデリングのエッセンス」
ぐらいの厚さになるわけだし。

>>703
>それじゃあんたの理解するOO的要求定義〜テストを説明してくれよ。

口を開けて答えを待ってる馬鹿につける薬は無いんだが、とりあえずどこまで理解
してるか言ってみ？ん？

>>705
703 じゃないけど。

OOについて議論するなら、「OOとは何か」を先に定義しないと
話が進まないというのは事実だと思うがな。

個人的には罵倒覚悟で言うと、最初にOOを喧伝
するよりまずSTLの便利さを単純に示すべきだっ
たのでは、と思います。

>>707
最初って、なんの最初？

oosquare-ml晒し上げ

>>706

先に定義を提出した奴が嬲り殺しに遭うスレですが、何か？

>>707
STL は Generic Programming でしょうが。（多態してないはず）

オブジェクト指向とかいいもんかもしれないが

俺は言語の機能をしっかり引き出し効率的に設計し、効率的にコードを書くのを指向したいな

ひとりでやる時は、好きなように抽象化してコードが書けるけど
他人と作業するときは
　皆が理解して皆がメインテナンス出来る方法で実現することが最も効率的なコードとなるし
それが逆に不効率な人材しかいないなら、どこかで遮断してしまった方がいい。
しかしOO言語にある隠蔽機能はまだまだ足りない。　コンポーネントはいい線いってると思う
一番いいのは　スクリプトにしてしまう事だ

OO信者の信条

自分が作ったものだけが唯一信頼できるものだ。
他人の作ったクラスは使うな。

> 一番いいのは　スクリプトにしてしまう事だ
ようはソース単位でってこと？

>>706
OOとは何か？

　人間は様々なパーツで構成され、それらは多種多様の細胞で構成されている。
　多種多様の細胞は細胞という一つの概念として見ることが出来る。
　細胞は水、タンパク質などの物質で構成されている。

このような分析をする事をOOAと言い、こういう考えで設計する事をOODと言う。
さらにこの構成でプログラムすることをOOPと言い、それに適した言語をOOPLと言う。

で良いのか？

>>715
一応ツッコミ。
OOA, OOD, OOP, OOPLは出てきたがOOが出てきてない。
それからそうゆう例示は「定義」とは言わんよ。

>>715

その論法で動物の体をモデリングしたら細胞の分化レベル毎に染色体の数が違って
しまいそうだが？

ツッコミありがとう、確かにその通りだ。
日本語から勉強し直してきます。

やっぱオブジェクト指向ってモデリングがキモだと思うんよ。
モデリングがクソだと、どう足掻いても生産性や保守性はあがらないよな。
これはコンピュータがただの計算機ではなくなってきたときからかわらないもんだと思うんだけどどうだろ？

>>719

後半、ひらがな多過ぎ。

ツンツンとつつくと何か反応を返すのがオブジェクト。
自分が何者で何に反応するかも答えられると尚よい。

そんなオブジェクトでソフトウェアを構成するのがオブジェクト指向。
ここでいうソフトウェアには分析/設計も含まれる。

ってな感じでどーでしょ。

http://pc.2ch.net/test/read.cgi/tech/1013995470/
レガシーなみなさん、遊びに来てください。

>>721
まあ、そんなもん。

>>723

同意。
ちょうど良い比率だと思う。

>>724
カタカナに騙されるな！

分析をかなり行ってクラス設計しても、仕様変更の
部分によってはかなり根本から設計しないとダメな羽目に
なって結局それでかなり時間とられるようなことも、現場
ではある。

>>726
そうだな
あと、自分の設計スキルが未熟で
自分が設計したモデルと実際のモデルが食い違うこともある。

モデルが大きく異なってしまった場合、オブジェクト指向でも
作り直しに近い状態になる場合がある。

>>727
そういった点では非OOの方が修正がしやすいといえる。
つまりOOの管理のしやすさというのは、かならずしも
正しいとはいえない。

修正の仕方がちがうんじゃないかな？
おれはOO的な修正術なんて知らないから
よく分からないが。

>>727
> そういった点では非OOの方が修正がしやすいといえる。
どういった点だ？
非OOではモデルと実際が食い違っても修正しなくていいのか？
いいな、ぜひその方法論をここで公開してくれ。（藁

いまやってる業務でクラス設計したやつが上司なんだけど、
これがまたクソなんだよ。でも自分ではすばらしい設計
だと思ってやがる。OO信者にはそういう奴が多くないか？
自分流クラス設計の自己満足の世界に浸っている奴。結局
多人数で作業し始めるとその「完璧なる」クラスがボロボロ
になっていき、結局「これは根本的な仕様変更なので・・・」
って言い訳して、また最初からやってやがる。OOって
実際はそんなもん。よほど非OOのほうが融通が利くよ。

オブジェクト指向は戦場では必要無し！

>>731
設計やってるヤツのレベルが低いと大変だよな。OO に限らず、データベースの
スキーマ定義とかでもそうだが。

>>731
根本的な仕様変更だからといって、全部作り変えるようなクラス設計
してるその上司がアホなだけじゃん。

クラスが全て再利用不可能などという事態になることは、マトモに
設計していればありえないと思うんだが…

OO信者の言い訳
「それは設計が悪いから。」


そのまんまじゃん。（ｗ

非OOは設計なんか適当にやっているから、
設計を大きく変更する必要があっても適当にやれる。
正しい設計なんて無関心だから間違った設計で進められる。
神経が麻痺するから、どんな状態でも問題に気づかなくてすむ。
技術的なことに興味がある人がいないので自分も技術力が無くていい。

>>736
もう呆れるね。
それさえも通り越して哀れだね(ﾌﾟ

>>735
空行多すぎ。圧縮してくれ。

>>735
あのさ、非ＯＯとやらでも、根本的な仕様変更があったとしても
それまでそのシステム開発のために作成したライブラリの殆どは
流用できるでしょ？

システムの仕様が顧客の要求で変更になったとしても、それは単に
表層でやり取りするデータの構造が変わったとかビューの表現形式
が変わったとか、せいぜいその程度の事で、それより下の層に関わ
る部分のライブラリってそのまま使えると思うが…
そのように作っていればだけど。

設計がアホなのにＯＯも非ＯＯも関係無いでしょ。

漏れもOOが変更に本当に強いものか疑問を抱いとる。
クラス間の結束が強いと、そこに機能を追加するのに
ばらしにくい。

つーかさ、業界の流れを見てるとOOが普及してきているとしか
思えないじゃん。それでも非OOだけでやっていけると思っているの？
それともOOが普及してきている事実を見たくないの？
そうだよね。COBOLと同じで自分の仕事がなくなるんだもんね。
だめだよ、プロならちゃんと勉強しなきゃ(w

>>740
だから、そういうのはＯＯでも非ＯＯでも同じじゃん。
機能的に独立したライブラリ呼び合うようにしてなければ
非ＯＯだって同じことになるだろうが。

関数間の結束が強いと、そこに機能を追加するのに ばらしにくい。

非OOもOOも同じで○○間の結束は弱くするよう設計しよう。

OOを使ったらそれだけでクラス間の結束が弱くなると考えていたら間違い。

>>376
> 非OOは設計なんか適当にやっているから、
ということにしたいんだね。
OOが普及する前でも設計を適当やっているわけではない。

> 技術的なことに興味がある人がいないので自分も技術力が無くていい。
OOって技術なの？OOPLは技術だと思うが．．．
個人的にはOOは哲学やイデオロギーの部類に入ると思っているのだが？

ﾌﾟﾌﾟｯ

どうもＯＯと非ＯＯとやらの間に、何かのヒエラルキーのようなな
ものを持ち込みたがってる詐欺師がいるな。

ＯＯでのメリットなんて、巧く設計するとライブラリの再利用性を
簡単に上げるチャンスがあるよん、機能単位の抽象化が実装レベルで
簡単に出来るチャンスがあるよん（あくまでも「巧く」設計出来る人
がいれば、だけど）という程度でしょ。

その他のシステム開発に関わる大部分の問題は、ＯＯだろうが非ＯＯだ
ろうが全く同じじゃん。

　情報技術（ＩＴ）系の派遣技術者のうち、ネットワークに使う共通言語「Ruby」を使える
人材の需要が高まっている。派遣会社の受け入れ企業に対する請求額は月額80万円
程度（首都圏）。同じＩＴ系でも比較的単純な業務に当たるプログラマーの料金が下落
傾向なのと対照的だ。

　相次ぐ合併・買収など企業の再編に伴って、各社が持つシステムの変更・更新などの
ため、ネットワーク言語を使いこなせる専門スタッフが必要になっている。システム投資を
控えていた外資系企業の一部でも新規のネットワーク構築の動きがみられ、同様の人材
確保を急ぎ始めた。

　一方、派遣プログラマーには余剰感が強い。これまで派遣会社や需要先のソフト開発
会社などが人材を積極的に育成してきたうえ、人件費が安い中国へ外注したり現地法人
を作って開発したりする例も多い。派遣会社の請求料金は首都圏で月額45万―55万円
程度。特に技術レベルが低い層では、30万円台の料金も登場している。

OOでも非OOでも結局「モデル」と考えないと設計はできない。
OOPLはOOで考えた「モデル」を他の設計技法よりも柔軟で強力に表現できるだけに過ぎない。

設計は戦場では必要なし。
他人のソースを見るにも複雑でときほぐしにくい。
ちゃんと整備されたドキュメントがなければ粗大ゴミソース
実際は世の中にどれだけの糞SEや糞PGがいることか。。。
よって設計は戦場では使いものになりません。

>>743
> OOを使ったらそれだけでクラス間の結束が弱くなると考えていたら間違い。
agree

なんでもかんでも実装継承するバカは逝って良し。

>>746
> ＯＯでのメリットなんて、
不勉強なのがバレバレですな。

とりあえず（本来は UML の本なんだが OO の設計技法に関する入門書としても、
非常に出来が良い）「UML モデリングのエッセンス」あたりを読むことを強く推奨。

>>750
うちの会社には、public変数だけで出来ている構造体もどきクラスを
つくり、さらにそれを継承したものをデータのコンテナとして使用する
設計を行い、美しい設計だと自画自賛してるアホがいる。
バカにＯＯ使わせるとろくなことにならんよ。

>>746
> どうもＯＯと非ＯＯとやらの間に、何かのヒエラルキーのようなな
> ものを持ち込みたがってる詐欺師がいるな。
詐欺師ではありません。詐欺師だったらもう少し頭がいいはずです。

彼らはOO信者なのです。
すべての設計をOOでやれば必ず幸せになれると信じている少し頭の弱い人ですが、
内容のないレスを大量に書くことを厭わない暇人です。

>>752
そういう構造化以前の話はもう聞き飽きた。
OOとは関係ない話だよ、それは。

>>753
正直、氷魚と Kusakabe には負ける。

>>752
バカに非OOを使わせても同じだろ。
OOを使えん奴に非OOを使わせるな。教育してからにしろ。

OOの仕事→OOを使える奴がする
非OOの仕事→非OOを使える奴がする。

出来ない仕事は断るか、仕事が出来るようする。それだけ。

>>754
べつに 750 も 752 も「だから OO はダメだ」とは言ってないと思うけど。
単なる愚痴でしょ。

>>753
OO信者をanti OOにしても、そのまま使えそうな文章だね。

彼らはanti OOなのです。
すべての設計をOOを使わずにやれば必ず幸せになれると信じている少し頭の
弱い人ですが、 内容のないレスを大量に書くことを厭わない暇人です。

（イマイチ、面白くないね。ごめん）

厨です。OOの問題点は何でしょうか。教えてください。

>>759
難しすぎることです

>>759
マトモに使える人が殆どいないこと。
マトモに使えてないのに、使えているフリをして虚構で他社との差別化
をはかり、無知な顧客から大金を巻き上げる、ベンチャーの詐欺行為の
道具に成り下がっていること。

>>753
> すべての設計をOOでやれば必ず幸せになれると信じている少し頭の弱い人ですが、
この行のみには同意。ただし、非OO信者、OO信者両方いると思うけどね。

全ての設計をOOでやれば幸せになるわけではない。
非OOがふさわしければ非OOでやる。
OOがふさわしければOOでやる。

どんなときでも非OOもしくはOOを選ぶ奴は信者。
どちらかしか使えない奴はバカ。

現実としては非OOしか使えない糞SEや糞PGが多いみたいだけどね。

>>756
言いたいことははっきりと言えよ

OOの仕事→OOを使える優秀な奴がする
非OOの仕事→OOを使えない低脳がする

>>558
> OO信者をanti OOにしても、そのまま使えそうな文章だね。
この世にはOO信者とanti OOしかいないと思っている人にはそうみえます:)

あのー、なんでＯＯと非ＯＯが対立する概念のように扱われてるん
でしょうか？

>>765
信者には外の世界はカオスにしか見えないものです:)

>>764
話のつながりが謎だ…

>>765
気のせい。片方に過剰な思い入れがある人間が、そういう書き方をしてるだけ。

非ＯＯって具体的になんだろう？

>>768
Javaを使わないことです。

>>769
違います。Javaが使えないことです。

>>763
そのうち低脳から無能になる(w

>>759
OO で問題領域をモデリングする場合には、その分野のエキスパートの認識方法
を反映した形で設計を行う。それが最終的には仕様変更の強さにつながってくるん
だが、どうしても設計にかかる時間は長くなる。

人間は世界を動的分類で捉えてる節があるんだが（その方が明らかに分析しやす
い）、現在主流の OOPL は動的分類には対応していない。そのため、設計段階で
動的分類を静的分類に落とし込む必要があるのだけど、

- どこまで静的分類に落とし込むのか
- どのような手法を使うのか

が割と難しい。

また再利用性を高めることを目的とした場合、主流の OOPL が言語機能として提
供している「実装継承」は目的の一部しか達成できない上、基底クラスと派生クラ
スの間の結合を不必要に強めてしまう。

実装継承の問題を避けつつ再利用性を上げるための方法は Design Patterns と
してまとめられているが、こういったイディオムを知らないと再利用できる枠組み
が作れないことも、難点かもしれない。Design Pattern を使ってかかれたコードは、
今度は Desgin Pattern 知らないと

　「何を、こんな回りくどいことをやってるんだ」

ってコードに見えてしまうし。

OO でやろうとすると、覚えることが多く、失敗すると悲惨で、かつ初期コストが嵩
むのよ。（それでも OO 捨て捨て、とならない程度にはメリットがあるわけだが）

>>768
> 非ＯＯって具体的になんだろう？
モジュール化設計
OOPLに対応する言語はCやPascal

さらにその前はCOBOLなどがあり、
COBOLには内部変数や再入可能な関数は存在しない

>>772
一つ教えて。
動的分類と静的分類とはどういう意味？

>>774
goto google

（多重分類もキーワードにすると、それっぽいページが出てくると思う）

>>772
> 現在主流の OOPL は動的分類には対応していない。
確認するけどC++やJavaはOOPLと思っているの？
あれはクラス指向言語であってオブジェクト指向言語じゃないよ。

クラス指向とオブジェクト指向の定義は？

珍説登場！

そのうち「真のＯＯＰＬは、まだ登場していない」などという説が出てくるに、２００ガパス。

>>777
くらすべえす
と
ぷろとたいぷべえす
ということでは？

>>776
無理しないでｱﾌｫは素直に非OOしてろよ(藁

776面白すぎる・・・
おかげでキーボードがお茶で汚染されたじゃねーかぁ

>こういったイディオムを知らないと再利用できる枠組み
>が作れないことも
OOがきちんとわかっていれば、
イディオムなんて知らなくても・・・以下略
それとも、脳の問題かな。

>>780
それでは意味が通らないので却下。

>>772
オレがOOに感じている行き詰まり感が簡潔に述べてあるな(w

クラスが扱う問題の領域を設定することが難しいことも問題の
一つとしてあると思う。再利用可能なだけに間違えても修正
しづらいだろうし。

動的分類と静的分類で検索して
たったの4件。あんまりメジャーな
概念ではない？

785
ｽﾏｿ
dynamic static classification
これで山のように出てきました

再利用再利用っていったいなんのこと言ってんの？
フレームワーク・クラスライブラリ・アプリ固有のクラスが混同されてるような。

>>777-782
お前ら今まで使ってきた言語がOOPLじゃないからって
そんなに動揺しなくたっていいだろ？

別にOOPLじゃない言語だってOOは不可能じゃないんだから。

>>785
まぢ？　OO の大御所ファウラーが著した「アナリシスパターン」なんかで詳細に
取り上げられてる話なんだが。

http://www.ogis-ri.co.jp/otc/hiroba/technical/Classification/

クラス指向の例で判りやすいのは
「手続き型クラス」
setVideoModeクラスとか、
caliculateUserPayクラスとか。
でどうよ？

>>790
意味不明

>>788
とどのつまり「俺用語」で客観的な定義はないわけね…

じゃあいったい何がOOPLなんだよ。
理由もつけて教えてくれ。
無いって落ちはやめてくれよ。

みんな、最低限、これくらいは読んでるよな？
http://www.zzz.or.jp/~iizuka/EOO/Japanese/oofaq-j/oo-faq-toc.html

OOPLが何だとか言ってるの・・・不毛だ

>>779
あっそうそう書き忘れてた
> 「真のＯＯＰＬは、まだ登場していない」
現在の言語の中ではSmallTalkがOOを忠実に表現した言語

SmallTalkが自転車だとするとC++やJavaなどは
クラスという補助輪をつけたお子さま用自転車

C++やJavaを使っているごときでOOPLを使っていると言って欲しくないな。
補助輪付き自転車に乗って「自転車に乗れます」というくらい恥ずかしいyo

>794
ブラクラ

信者ならバイブルを示さないとね。
んで現実を無視して
「この本にこう書いてある」としかいわねーのｗ
（現実との擦り合わせが行われない脳構造の持ち主）

OO信者の自作自演劇がそろそろ始まるころです。

>794
精神的ブラクラ

結局 OO に対する技術的な批判は、他にないの？

OO 反対派の人たちから「なるほど」と思う批判を聞いたことがないんだけど。

>801
意見はないが現実を見ろの一言だろ。

そんな優秀な奴がこの世にどれだけ
いるよ。この世はDQNで出来ている
んだよってな感じ。

（バイブルを示したんだから、その内容にツッコミ入れてみろっつーの…）

> 結局 OO に対する技術的な批判は、他にないの？
ないよ。だってOOは技術ではなく、哲学であり、美学であるのだから。

>>801
前から出てるじゃん。
１）生産性が下がる
２）その他、ＯＯ関連本に書いてある事は嘘ばかり
３）詐欺師蔓延、ベテラン圧殺。

>ベテラン圧殺。
ﾜﾗﾀ

>>805
それは*技術的*

>>805
それは批判といわない。ただの推測。

戦いの勝敗は始まる前に九割がた決まってる。
プロは準備に充分過ぎるほど時間をかけるものだ。

書き込み途中だった
>>805
それは*技術的*な批判ではないだろ？
# どっちかってーと愚痴だね

>776
お前も技術的な話なんてなんもしてねーな

>>805
> その他
おいおい（ｗ

>>802
俺の知っている現実は「優秀な奴が生き残る」なのだが…。

おいおい、生産性が技術と関係無いと思ってるのはかなりＤＱＮだぞ。

>>813
俺の知っている現実は「優秀なフリした押しの強いだけの奴が生き残る」なのだが…。

>>813
じゃぁお前一人で全部やってろよ

>>814
つまり、「そういう奴を評価するDQNが経営者やってる」ということですね。

オブジェクト指向一生懸命勉強したのに・・・。
（´・ω・｀）ｼｮﾎﾞｰﾝ
↑
OO信者

>>814
> おいおい、生産性が技術と関係無いと思ってるのはかなりＤＱＮだぞ。
OOだと生産性が下がる、というのが示されてない以上は愚痴と同レベル。
統計データを出せとは言わんが、せめて

「なるほど、それは下がるよなぁ」

と思う程度の理屈は書いてくれないと。

デザインパターンとかUMLとかも指向一生懸命勉強したのに・・・。
（´・ω・｀）ｼｮﾎﾞｰﾝ
↑
OO信者

>>815
どこから、そういう結論が出てくるんだ？　話が飛躍しすぎだろ。

>SmallTalkが自転車だとするとC++やJavaなどは
>クラスという補助輪をつけたお子さま用自転車
なぜ？
SmallTalk信者？
どこがいいんだか語ってください。

>>814
「優秀なフリした押しの強いだけの奴が生き残る」よりも
「優秀で押しの強い奴が生き残る」じゃないのか？

お前ら、業務系の話をしてるんだろ？
業務系で優秀なプログラマだけを集めたら
いくらかかると思ってるんだ？

OOで生産性が下がるのは、プロジェクトに関わる人間のなかに
OO分かってないのに背伸びして分かった振りして、結局出来
なくてプロジェクトに迷惑掛け捲る奴がどこにでも多数いる
という、技術云々以前の社会的要因によるものとおもわれ。

>>823
無能なプログラマ・SEを集めたほうが結果的にお金がかかります。

オブジェクト指向でSmallTalkが連想されるなら、オブジェクト指向が戦場で必要と
されるケースは少ないだろうな…

早く大学でOO仕込まれたまともな学生がたくさん世に出てきて
非OOベテラン(藁低脳コーダとリプレースされないかな

>>824
それを言い出すと派遣云々の話になってややこしくなるに３ベルマーク

Smalltalk　な。

794のリンク先は
1節: 基本
1.1) オブジェクトって何ですか？
1.2) オブジェクトのカプセル化（または保護）っ何ですか？
1.3) クラスって何ですか？
1.4) メタクラスって何ですか？
1.5) オブジェクトとクラスの無限の連鎖って何ですか？
1.6) ＭＯＰｓと自己投影って何ですか？
1.7) 継承って何ですか？
1.8) 多重継承って何ですか？
1.9) 多重継承はどんな付加的な困難をもたらしますか？
1.10) 動的継承って何ですか？
1.11) 共有された（または反復した）継承って何ですか？
1.12) どうして継承を使うのですか？
1.13) どうしてある人たちは継承を嫌うのですか？
1.14) 特化／汎化／再定義って何ですか？
1.15) オブジェクト・ベースとオブジェクト指向って何が違うんですか？
1.16) クラスはオブジェクトですか？
1.17) オブジェクトはクラスですか？
1.18) メソッド（そしてレシーバとメッセージ）って何ですか？
1.19) マルチメソッドと多重の多態性って何ですか？
1.20) ＯＯＰって何ですか？
1.21) ＯＯＡ／ＯＯＤって何ですか（そして必要なものはどこで手に入りますか）？
1.22) オブジェクト指向はどこからきたんですか？
1.23) オブジェクト指向の恩恵は何ですか？
1.24) ほかにどんなＦＡＱが利用できますか？
2節: 型付け
2.1) 多態性って何ですか？
ウェブスターの新世界辞書:
著者の定義:
Stracheyのオリジナルの定義 [Strachey 67]:
CardelliとWegnerの定義 [Cardelli 85]:
Boochの定義 [Booch 91, p. 517]:
Meyerの定義 [Meyer 88, セクション 10.1.5 多態性]:
Stroustrupの定義 [Stroustrup 90, p. 209]:
2.2) 多態性は、オブジェクト指向プログラミング言語において、何に集約されますか？
2.3) 動的束縛って何ですか？
2.4) クラスのメンバーあるいはインスタンスであることに違いはありますか？
2.5) 静的型付けと動的型付けとの違いは何ですか？
2.6) MLと関数的プログラミング言語について私が聞くこれは何ですか？
2.7) タイプとクラスの分離（表現）って何ですか？
2.8) 総称とテンプレートって何ですか？
3節: 一般
3.1) 「古典的な」オブジェクト指向パラダイムって何ですか？
3.2) 「委譲／プロトタイピング」のオブジェクト指向パラダイムって何ですか？
3.3) 他にどんなオブジェクト指向パラダイムがありますか？

>>823
生産性マイナスのバカを雇うよりは、結果的に安くなりますが、何か？

……とはいえ質より人手が重要な場合もあるのは事実。まぁ OOPL といっても、
関数名や詳細仕様まで決めてしまった上で単純なコーディング作業だけやらせ
るぶんには、優秀じゃない人間でも使えるよ。

このあたりは、非 OO で蓄積したノウハウがそのまま活かせる。

>>822
押しの強い奴に責任感ある奴は少ない。

>>821
Javaが補助輪付きだっつうのは当たってるわな。
悔しかったら俺に関数ポインタを返せ！

頭数でプロジェクトの規模を計るのは辞めて欲しい

>>SmallTalkが自転車だとするとC++やJavaなどは
>>クラスという補助輪をつけたお子さま用自転車
>なぜ？
俺もこれ気になる。
書いたやつは責任持って答えろYO

>>832
関数ポインタで何がしたいんだ？

>>832
> 悔しかったら俺に関数ポインタを返せ！
interface 使え Yo!

>>836
せっかくいじめようと思ったのに・・・

>>833
確かにそれは言えてるな。
人月神話以前の問題。
そうやって公共の仕事の
水増し請求してるんだから
世話ない。

>>836
アフォか！インターフェースじゃ関数ポインタの変わりにならんわ！
せめてリフレクションと言え。
つうか携帯java担当なんでどっちも使えないがな。

>>839
多態を利用してディスパッチする事も知らない人は、
OOP使う資格ないです。

>>839
関数ポインタでなにがしたい？

>>840
836だろ？
じわじわいじめようって言ってんだろうが。

>>842
違うって。俺は 837 の時点で、じわじわ虐めるのは承知してる（ｗ

>>839
逃げた?

>>841
いわゆるメタ構造かな？
関数ポインタ無いと静的プログラムしか書けない。

>>845
あなたがそう思い込んでるだけでしょう。

>>845
> いわゆるメタ構造かな？
これだけだと良く分からんので、具体的な事例を希望。

>>843
なるほど、ゴメン。
845の発言を見てニヤリとできるでしょ（ｗ

http://pc.2ch.net/test/read.cgi/tech/1013995470/l50

>>776
>>796
はバグでした。
ごめんなさい。

それよりも１の名前が気になる。けんしろう？

アンチは逃走したようなので、
今日は終了ですな。

まあ、お前らは低脳にふさわしく静的プログラムだけ書いてなさい。

>>853
C で関数ポインタを使うとかけるが、Java だとかけない「動的プログラム」って
具体的に何よ？

データベース覗いて勝手にメソッド生成してくれるルーチンとかだな。

OOプログラマ＝頭がｲｲ！
って思っている馬鹿が数名います。

すばらしいルーチンだ。ぜひ公開してくれ。

>>855
仕様が曖昧すぎ。せめて読んでる人間がコードを書けるぐらいには、詰めて
書いてくれ。

>>856
それはどうか知らんがここのｱﾝﾃｨOOは莫迦ばっかだな。

>>856
どこに？　幻を見てるんじゃないのか。

>>855
なんとなくそれって動的プログラムというより動的プログラミング環境だね。
俺そっちのがいいなあ。誰か作ってくれ。
テストケースやら仕様書やらをどんどんヘルプみたいに取り込んでF1で呼び出せるとか。

それってエージェント指向。

ジョークだと思われてるしｗ;
いちいちプログラム書いてらんない。
普通はメタ使って自己生成する発想に行くと思うな。
ついでに動的ＨＴＭＬも自動生成して、テーブル書くだけで
終わる様にするのな。

>>863
それと関数ポインタとの関係を小一時間（以下略

>>864
とにかく、無いと出来ない。

>>865
出来ないと思いたがってる人には、一生できないだろね。
俺ならJavaでちょいちょいでできるけど。

つーか再三誰かが言ってるがそんなにOOって難しいか？
DQN以上の凡人だったら理解できる内容だと思うが、さて？

>>867
OO のメリットを生かした設計をするのは、それなりに難しい。

設計の大枠が与えられた状況下でプログラミングするのは、それなりのトレー
ニングは必要だけど、無茶苦茶に難しいって事はないと思う。

ＯＯって、理解するのはそれほど難しいとは思わない。
でも、奥が深くて楽しい。

そんなに門が狭いってこともないよな〜。

奥はおもいっきり広いがな。

＞奥はおもいっきり広いがな。

はあ？ライブラリのこと言ってるの？

（´−｀）。o ○ （またこいつか・・・）

>>871
アソコの事でしょう。

ﾏｰｰｰｰﾑｰｰｰｰｰｺｯｯｯ (ﾟДﾟ)ｺﾞﾙｧ
ﾏｰｰｰｰﾑｰｰｰｰｰｺｯｯｯ (ﾟДﾟ)ｺﾞﾙｧ
ﾏｰｰｰｰﾑｰｰｰｰｰｺｯｯｯ (ﾟДﾟ)ｺﾞﾙｧ

㋐㋭

>データベース覗いて勝手にメソッド生成してくれるルーチンとかだな。
おーい、誰かこのバカ何とかしてくれ・・・
C言語でメソッド？
それは置いといて
C言語でプログラムを書き換えるプログラムって書けるかよ。

とりあえず、具体例をあげろよな。

>普通はメタ使って自己生成する発想に行くと思うな。
メタだって(w
メタってなんですか？
と書いてみるテスト

コード出力
コンパイル
子プロセス起動

別段めずらしくもないだろうに…

>>878
いや、それだと C の関数ポインタとの関係が謎になる。どうも C で関数ポインタ
を使うと実現できるが、Java だと実現できない「何か」がキーらしいから。

>動的ＨＴＭＬも自動生成して、テーブル書くだけで
自動生成されたHTMLを動的HTMLといってるんだろう・・・
で、それを吐き出すコードを自動で作るのか？
それはテーブルを入力するとコードを出力するプログラムの事か？
関数ポインタとどう関係があるんだ？

>>878
そんなことするメリットがよくわからないしな・・・・

>>881
コード生成プログラム自体は、使うとスマートに問題を解決できることはあ
る。yacc とか lex とか。

ただ動的にコンパイルするのは、普通はやらんよね。それならインタプリタ
と JIT コンパイラ作るよ。

> そんなことするメリットがよくわからないしな・・・・
分かんなきゃ口出すなよ。

eval的なことをしたいんだろ。

CとJavaの比較スレでもこんなこと言ってるバカがいたな…
同一人物か?

>>884
>eval的なことをしたいんだろ。
「eval的なこと」は、たとえばPerlならできるが、Cでは、
たとえ関数ポインタを使ってもまともな方法ではできない。
ま、機械語コードを自分で生成して「関数ポインタ」で
強制的に呼び出せば可能だが、移植性は完璧に失われるわな。

Javaでは、「Cと同様に」まともな方法ではeval相当のことは
できない。ま、バイトコードを自分で生成してクラスローダ
作って呼び出せば可能だが、移植性は保たれるわな。

結論:少なくともこの点では、Javaの方がCよりはマシ。

Perlとかを比較対象に持ってきて「動的プログラムができない」
というのならわかるが、「Cと関数ポインタ」じゃ、無知を
さらしているだけだよ。

あ、

>CとJavaの比較スレでもこんなこと言ってるバカがいたな…

俺がバカと言ってるのは >>845 のことであって、そこで引用した
>>884 のことじゃないです。…と、一応念を押しとく。

コテハン叩くなや。

>>887
自分が無知であることにようやく気付いたと見える。

さらしage。

単純過ぎる煽り。

>>889
自分の無知さを晒されたからって、こりゃ見苦しいよな。

>>885
まあ、Cのソースから動的に生成するにしても、
「Cのソースから動的ライブラリを作ってロードしてやって、終わったら捨て」
なんつー超ムリヤリな方法が無いでもないがな。

ちなみにSmalltalkなら当然のように超簡単。
Compiler evaluate: 'a source code comes here'
既存のクラスに動的にメソッドを追加するのも超簡単。
つーか、Smalltalkの処理系自体、そうやって動いている。

で、関数ポインタがどうしたって？（藁

>>891
で? Smalltalk が優れているとでも? んなこたぁないよね。言語は適材適所だ。

動的生成ってWin16の頃はサンクという名前で普通に使ってたよ
今でもDelphiではコールバックをメソッドに割り付けるのに使ってる技術

>>893
動的生成って具体的にどんな事なの？

>コールバックをメソッドに割り付けるのに使ってる技術
これは関数ポインタと何が違うんだ？

サンクって16bitのコードを実行するためのものだよね・・・

OO言語のいわゆるメソッドは　いわゆる構造体をポインタとして隠れた引数に含む関数の事が多い
　staticな構造体であっても、メソッドであればこの為に間接参照となる。

仮想関数の場合、関数の呼び出しもポインタを介して行われる
　仮想関数の実装により違うし、その実装方法を指定出来るものも多いが、
　このポインタは書換可能領域を経由する事が多い
　この為、暴走し易い
　関数化しただけでも、関数の帰り番地はメモリに書かれ為嫌われる世界があるのに
　さらに関数の先頭番地までをメモリに置くというのは好ましくない

WindowsAPIではコールバックは関数ポインタを渡すよね？
　メソッドは関数ポインタの他にオブジェクトインスタンスアドレスも渡さなければならない

最近作られたAPIの多くはハンドル作成時にコールバック時に渡すアドレスを渡せるけど
肝心のWinProcには無い。（SetWindowsLongで埋めようと思えば埋めれｒけどね）

これを解決するのにDelphiでは　インスタンスの作成時に、短いコードを動的に作って
その関数内部でインスタンスアドレスを作り出している

Win16の頃は、DLLは共有されていた。　このDLLからコールバックを受ける為には
関数ポインタのほかにセグメントレジスタが必要になる　そこでやっぱり短いコードを
動的に作ってこの関数を経由して呼び出す事で解決していた。この技術をマイクロソフトはサンクと呼んでいた

さて、サンクという用語にしても知っている同士なら　その用語を使うだけで作業を進められるが
相手が知らないなら２つの道がある。
A　一つは知らなくても済むように用意して使わせる道
B　もう一つは相手に知って貰い、理解して貰う道

さてオブジェクト指向は、知り理解しなければならない用語が多い
　　　さらに、その用語がいまだ曖昧であるのは別にして
　となるとBのコストはAに比べれば高くなる

これで
現場を戦場と呼ぶようなプロジェクトでBの戦略を取るのはダメだという１の結論が得られるのだと
俺は思うが　どうか？

>>898
その手法はATLでも使われてるよ

>>899
短期の、あるいは一回限りのプロジェクトならそうとも言えるだろう。
しかし、Bを行っても、一度理解してしまえばその後の進捗は
Aよりも速くすすみ、トータルではBの戦略をとったほうが良いという
1への反論が得られるのだと俺は思うが、どうか？

>>901
現場を戦場と呼ぶようなプロジェクトでは、当然兵隊は外人または徴兵であると思われ

>>899
> さて、サンクという用語にしても知っている同士なら その用語を使うだけで作業を進められるが
ゲイツ社の取り巻き同士ならjargonが通じる、ってことかい？
いいね、狭い世間で生きている人たちは…

>>897
> このポインタは書換可能領域を経由する事が多い
> この為、暴走し易い
> 関数化しただけでも、関数の帰り番地はメモリに書かれ為嫌われる世界があるのに
> さらに関数の先頭番地までをメモリに置くというのは好ましくない
メモリを誤って上書きされるかもしれないから、メモリを使うべきじゃあないって事？
その前に、メモリを誤って上書きされないようにするのが正しいんじゃないの？
ここで質問。
CとJavaではメモリを誤って上書きされてしまう危険はどっちが高いでショーカ？
CとSmalltalkでは？

>>904
＞メモリを誤って上書きされるかもしれないから、メモリを使うべきじゃあないって事？
　スタックエリアはバス上のRAMには取らない とかね
　そういう世界もあるという話　一般的な話ではない

＞CとJavaではメモリを誤って上書きされてしまう危険はどっちが高いでショーカ
そういう世界ではCとJavaではなくROM化にどれだけ対応出来るかどうかが指標でしょう

jargonだらけはオブジェクト指向のほうでしょ >>903

サンクについてはわずか数行で説明出来る概念だけど
OOのjargonはそうではないのが問題なのでは？

構造化パラダイムのjargonに比べてOOはという意味ね

>>899
>A　一つは知らなくても済むように用意して使わせる道
誰が、用意するんだろう．．．。

>>909　ライブラリを作るという事でしょ？
VCLやWTLでサンクは使われてるけど　使ってる人の殆どは知らない し知らないでいい

>>908
とりあえず実装は横に置いといて、
分析・設計でどんなjargonがあるか、変な概念だと思うのを挙げてみてちょ。
そうすれば、それが本当に数行で説明できないものなのか、
本質的にひねくれてるのか、はっきりするんじゃない？

jargonて何よ？
お前ら、ほんとはjargonって言葉使いたいだけちゃうんかと問い詰めたい。小１時間問い詰めたい。

>>911
変な概念という意味ではないでしょ。
いくつかの概念が組み合わさってOOになってるんだけど
その全体像が見えてくるまでにそれなりのお勉強と時間が必要だという事でしょ
訓練で身に付けなければならない部分があって、覚えたその日から使えます
って訳にはゆかない

>>893
thunk は一般に数 word の機械語コードで、

- きわめて限られた用途に使う
- 効率最重要

という用途に使うよね。せいぜい ATL の CWindow で WndProc にポインタを
埋め込むとか、多重継承時に this ポインタのオフセットを調整する (vcall) と
か、その程度。

とてもじゃないが >>863 が言うようなメタプログラミングしようっつーのは非現
実的だと思う。前にも書いたが、ふつーはインタプリタにしないか？

で、関数ポインタと「メタ使って自己生成」の関係は何よ？ >>863

アンチメタとやりあうのは疲れた

>>915
どこにメタプログラミング捨て捨て、といってるヤツがいるんだ?　俺には
見えないんだけど。

アンチメタメタ系でてこーい

http://www.system-azure.co.jp/boo/

オブジェクト指向を理解するのに数学は必要なんですか？
なんか恒例の煽りみたいで、申し訳ないんですが。

OOを理解するには哲学を学びなさい。

>>920
哲学の何を学べばいいのですか？
ラッセル？アリストテレース？

ＯＯの哲学を無視して、技術的側面のみを、徹底して追いかけなさい。
そうすれば、偽者が哲学と言っている事柄の本質を、より良く理解できるでしょう。

>>921
カント

読んだこともない人の名前はあげないように

カントぐらい中学で読むよねー。普通。

>>925
読まないよ。西田読む奴はいるかも
しれないがそれにしても変な奴だよ（和良

素養がなくて、難しい事に直面すると、
すぐ宗教とか哲学に走る人って、
どの世界にも居るんだよねぇー。

漏れは、分析的な目を曇らせるな、と言いたい。

＃OOを宗教に例えると何よ(藁？

>>925 旧制中学かよ!

まあ、ＯＯ信者はこれを読めや。
http://www.eleutheria.com/philo/kdrv/kdrv0.html

哲学なんて必要なし、予備知識としての
数学も必要なしってことでいいんですね？

漏れは、数学的素養が足りないと反省してまーす

最低限は中学卒業レベルの知識(数学も哲学もその他も)

>>930
OK

OO でも論理学の助けを借りて、形式的な仕様記述を行うような方法論もあり
ますが、主流ではありません。必要になったら考えれば良いかと。

＞＃OOを宗教に例えると何よ(藁？

イスラム原理主義

>>934
それは宗教ではないが。敢えて言うなら宗派かなぁ。

じゃオウム真理教

>>934 >> 936
本当にどういう宗教か知って言ってるのか？
単にイメージの悪い宗教を羅列してるだけだろ。
次はあれかな？

じゃあ仏教は何よ？

>>932
アニミズム

ＯＯは道徳の授業無しでは語れないよ

OOにかぎらず、「プログラム技術」には数学の素養は必要だよな。
形式的手法とかで数学を前面に押さなくても、
やはり自分が書いている設計なりプログラムなりの意味を理解するには
数学という道具は必要だよね。

>>929
まあ面白いし、科学的方法論の基礎に、
こういう考え方がある事に、同意します。

って優香、情報工学の営みって、哲学と被り過ぎ。
実用的な情報工学だけでなく、こういう基礎的な分野と手を結ばないと、
本質的なブレークスルーは生まれない気がする...

OOはアムウェイなどのマルチまがい商法と共通点ある。

巧妙なだましだよ。

直接は関係がないけど読む価値はある
そういった程度のものでしょ。学者ですら
引用を控えるくらいなんだから、うち等が
そんなもの口にするときはどんな結論に
なるのか大体想像がつく。

>>943
相変わらず、どこが問題なのかの具体的な指摘はないのな。

>>941
意味論だと、数学よりはメタ数学（論理学、数学基礎論）だろ。

ただ、意味論をやって良いプログラムを設計できるようになるかというと、今の
ところはあまり関係ない。

>>943
非OOだってアムウェイなどのマルチまがい商法と共通点あるじゃん。

先生ぇー、オブジェクト指向のモデル論を、哲学の認識論と結び付けてしまうと、
認識の相違の数だけ、異なったモデルが生まれてしまうと思うですけど、
どうやって皆の認識を統合したらよかとですかぁー？

共通感覚（ｗ

サブジェクト指向って、、

>>948
だから道徳を習うんだ。
思いやりは大切です。

共時性？

つうか、一つの対象に複数のモデルがあって、
それをアナパタ本の多重分類/動的分類問題とか、
多重世界仮説みたいな問題として捉えた場合に、
どうやって解決しようか？っつう事なんですが...

>>949 まあ、それでよいのかな、利害対立がない場合は...

なにげに940は的を得た意見かも

>>940,>>954 協調性ですか

>>954
的を持っていくなよ。元の場所に戻しとけ。

>>952
非 OO の設計手法を使っても、人によって異なる設計が得られるけど。

boochとかアナパタ本の作者は人文系の本も
相当よんでるのか？それとも建築関連とか
あくまで工学の範疇のものを読んでるのかな？

俺らには関係ないか。

>>957 そですね。
単純なコーディングなら、「必ず同じコードになる」つうのが自慢な言語もあるそうですが、
問題解決、分析設計だと、担当者毎の個体差が激しそう...。

>>952 について、漏れはこういう感じ。
複数のモデル間を、mediatorで結び付け、
モデル間の矛盾の解決をmethodを追加する。
でも、問題解決/矛盾解決の方法は、千差万別という気がする...

>>959 あれ、文が変だ...
○モデル間の矛盾や、その原因となっている問題を解決するmethodを追加する。
×モデル間の矛盾の解決をmethodを追加する。

既にジスレノ時期。
まだこのスレタイトルでやるんですか？
でもまともなタイトルだと人があつまらないんだよな（藁

お任せします。とってもきゃっちーなタイトル、考えてください。

OO信者は禿げ

>>956
初めて見るタイプのツッコミだ。ﾜﾗﾀﾖ｡

>>963 禿げじゃないもん。あ、信者じゃないからかぁ(ｗ

stroustrupとかbooch,Fowler。
なんか禿げてる人おおくないですか？
デニスリッチーなんてもっと歳いってるのに
ふさふさのカッコいい男優みたい。

次スレ
【オイル】オブジェクト指向やると禿になっちゃうの？【セクシー】

スレ立てよろぴく！

いいんかよぉぉぉーーー、ホントにそれでー？(叫

他になんかいいのある？

オブジェクト指向を勉強始めると
とめどなく本を買うことを迫られるからやだな。
なんかOO詐欺に引っかかった気分。
おれなんてもうそれ関連で20冊近く本買ったよ。

だめっすよね、こんなんしかかけなかった。ここのキーボード壊れてるし..

神秘系：
【神秘】オブジェクト指向の道【東洋思想】

宗教系：
【能天気】私オブジェクト指向で幸せなになれました【信仰告白】

見下し系：
今時オブジェクト指向使えないｳﾞｫｹ共へのメッセージ その→

祭り＆ヒス系：
【祭】私を騙したオブジェクト指向信者、訴えてやります、ｷｨｰ【祭】

＃そーいえば、永田町方面の田中真紀子先生祭り、盛り上がってましたね。
＃田中先生ってば、エンターテインメントなんだからぁー。

【ムネオ】OO*は地雷原【ハウス】

>>974 キャッチーだけどネタスレにしか見えんのよね、、、
って所詮ネタスレだけど(笑

タイトルはおまかせしました。
早く次スレたててくだちい。

つーか、うざいからもういいよ。
粘着アンチがまた適当にスレ立ててくれるだろ

じゃぁ、アンチOOスレはもう終了って事で。さいなら。

#bye all

駄留馬参我古論駄

結局戦場ではOOどころかPGは何の役にも立たないという事ですか？

戦場では客をなだめる才能のあるものだけが
必要とされます。そこまで逝ってしまっては
もう既に手遅れなのです。

アナリシスパターンって何？

>>982
客によっては挨拶するだけで怒号・・・
バグ修整するだけで罵倒・・・
電話掛けるだけでイヤミ・・・
そんな客をなだめつつまともな話が出来る人は
戦場では必須だね(ｗ

「おれより頭がいいやつは全員氏ね」
って書けよ。すっきりするぞ。クズども。

>>985
おまえだけは書かないでね。地球上の9割が死ぬから。

たった一人になっちまう

そして誰もいなくなった

>>983
書籍のタイトル。

で、パート3のタイトルは決まった？

新スレ 「オブジェクト指向は戦場では必要なし - おれより頭がいいやつは全員氏ね」

スレッド.終了()

　 　 　 　 ┌―─┐
　 　 　 　 │　╋ │
┌──―┘ 　　 └─―─┐
│　 �V　　　　　 　　 �V　　　| ＜ｼﾝｼﾞﾙﾓﾉﾊ　ｽｸﾜﾚﾙｰ〜♪
｜　　 　ＯＯ 真理教　　　　　|
│　　　 ┌―┬―┐　　　　 |
｜　　　　|。　｜。　|　　　　　|　　　　　　　ｳﾜｱｧｰｰｰｰｰﾝ
┴―‐―┴―┴─┴ｰ―─┴ 　ヽ(　TД)ﾉ　ｺﾝﾅ ﾄｺ ﾓｳｺﾈｪﾖ!!
　　　　　　　　　　　　　　　　　　　　（ 　 ）　　　　ｳﾜｧｧｧﾝ
　　　　　　　　　　　　　　　　〜　　/　ヽ

前にいつだったかニュー速板に
オブジェクト指向のスレが立ったのにはわらった

「信じるものは足すくわれる」

このスレが1000までのびるとはおもわなんだ。

つーかこのスレ Part2なんだが....

1000とった派が勝ちという事にしよう

1000

新スレ 「オブジェクト指向は戦場では必要なし - 詐欺はやめよう」

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