オブジェクト指向は戦場では必要無し
■ このスレッドは過去ログ倉庫に格納されています
0001あたたたた
NGNGクラスを理解する労力が大きく、目的まで達成するのに
時間がかかる。他人のソースを見るにも複雑でときほぐしにくい。
ちゃんと整備されたドキュメントがなければ粗大ゴミソース。
またオブジェクト指向が○○に優れているとかいう話も、あくまで
ちゃんと設計され、ちゃんと実装されたクラスがあるという前提での話。
実際は世の中にどれだけの糞SEや糞PGがいることか。。。
よってオブジェクト指向は戦場では使いものになりません。
0232デフォルトの名無しさん
NGNG0233デフォルトの名無しさん
NGNG> 「扱う」のがオブジェクト。「扱わせる」のはオブジェクトではない
意味が良くわからんが、主語は何なんだ?
0234デフォルトの名無しさん
NGNGハァ？ 何だか「オブジェクト指向分析・設計 〜初級編〜」とかを
斜め読みしただけの厨房みたいな事いうヤツだなぁ 。
インタプリタみたいな「処理」が中核的概念になっているドメインでは
当然「処理」もオブジェクトとしてモデリングするにきまってるだろ。
というわけで228は読みかじった本の練習問題を3回通り解いてから
出直すように (藁
0235デフォルトの名無しさん
NGNG漏れは普通に字句解析オブジェクトや、構文解析オブジェクト（＝ツリー中のノードを兼ねる）作って使ってるけどなぁ。
0236デフォルトの名無しさん
NGNG処理を中心としてクラスを定義するよりは、データを
中心として考えた方が良さそうだよね。コンパイラの
中身なんてどうなってるのか知らないけどさ。
ちなみにこれのクラス設計はどうなの？＞詳しい人
http://os.inf.tu-dresden.de/fiasco/doxy/hierarchy.html
0237
NGNGすげえな。クラスかなんかでラップすればなんでもオブジェクトかｗ
0238デフォルトの名無しさん
NGNG誰がクラス型の言語で書くといったんだ? 別にプロトタイプベースの言語で書いても
良いぞ。
（っつか 237 が考えるオブジェクトの「定義」って何よ?）
0239デフォルトの名無しさん
NGNGバカ丸出しだね、君。
ラップすればオブジェクトなんじゃなくて、
「その問題領域でオブジェクトとしてモデリングするほうが
簡潔かつ的確に表現できるのであれば、オブジェクトとする」
というアタリマエな話をしているだけだよ。
サラシアゲ
0240
NGNG「かなんか」つっとるだろ！
0241
NGNG便利なのとオブジェクト指向かどうかとは別の話。
0242デフォルトの名無しさん
NGNG237 の定義によると
「オブジェクト」＝「かなんか」
ということ? （さっぱり分からん）
0243デフォルトの名無しさん
NGNG0244デフォルトの名無しさん
NGNGオブジェクト指向という概念の範囲にくい違いがあると思われ。
0245デフォルトの名無しさん
NGNGで、241の「オブジェクト」および「オブジェクト指向」の定義は？
不便であるという事？ (プププ
0246デフォルトの名無しさん
NGNGOOっぽくできるのはシステムコールぐらいだな。
でも制約が厳しい奴はOOでは書かない。
0247デフォルトの名無しさん
NGNG0248デフォルトの名無しさん
NGNG0249デフォルトの名無しさん
NGNGっつーか、237=241が自分の「オブジェクト」の定義を示すまでは
厨房とそうでない者のくい違いとみなさざるを得まい。
0250デフォルトの名無しさん
NGNG0251デフォルトの名無しさん
NGNGスケジューラは別に OO で設計しても良いと思うけど。
オブジェクトの定義が何かってのは人によって幅があるけど、
問題領域を分析した結果として出てきた
比較的独立性が強く
内部状態を持ち
固有の操作を備えたもの
ぐらいじゃないのかな（実際には、さらに設計段階で認識されたオブジェクトも加わる
けど）。OO と ADT の差異は、オブジェクト間の関係を、掘り下げて考察する点ね。
この定義でいけばインタプリタを実装する場合に、構文解析をひとつのオブジェクトと
して切り出すのは、自然な成り行きと思うが、どうよ?
0252デフォルトの名無しさん
NGNG中間コードそのものは?
0253デフォルトの名無しさん
NGNGOSのスケジューラは各処理ごとに優先度を決めて正確な時間で
確実に処理しなければいけない。
ここでスタックガンガン使うような処理は好ましくない。
OOの利点である再利用もする必要が無いのでわざわざ
不確定要素を含みパフォーマンスが落ちる手段で設計する必要が無い。
0254デフォルトの名無しさん
NGNGヘ？OOだとスタックを浪費すると言いたい？
関数呼び出しとメッセージ送信とでスタックの使用頻度がどう変わるのか
説明キボーン。
0255デフォルトの名無しさん
NGNG> ここでスタックガンガン使うような処理は好ましくない。
> ...
> 不確定要素を含みパフォーマンスが落ちる手段で設計する必要が無い。
OO と
スタックをがんがん使う
不確定要素を含む
パフォーマンスが落ちる
は、関係ないですね。
0257デフォルトの名無しさん
NGNGＯＯ信者は口だけでロクなもん作れない。
0258デフォルトの名無しさん
NGNG当たり前。“信者”と名の付く者はふつー、そう。
今頃気付くな阿呆。
0259デフォルトの名無しさん
NGNG勉強して使いたいと思う？ 俺はウンザリするね。実際に体験したけど。
結局OOマンセーの奴ってチマチマしたプログラム
を設計して満悦してる奴か、JavaやMFC使って満足してる奴だと思う。
0260デフォルトの名無しさん
NGNG関数呼び出しとグロオーバルなフラグセットではアセンブラに落としたときの
ステップ数は確実に多くなるってこった。
よって無駄なCPUパワーを使う＝パフォーマンスガ落ちるという結果になる。
0261デフォルトの名無しさん
NGNGこいつはCをオベンキョウする時も
「現場に入って他人が作った数十?数百の標準関数を勉強して使いたいと思う？
結局Cマンセーの奴ってチマチマしたプログラムを設計して満悦してる奴か、
libcやシステムコール使って満足してる奴だと思う。」
とか言い出すんだろうな。馬鹿丸出し。
0262デフォルトの名無しさん
NGNG数十〜数百のクラス郡をクラスを使わずに処理しようとしたら
数十〜数百の構造体と数百〜数千の関数群が出来上がると思われ。
0263デフォルトの名無しさん
NGNG> よって無駄なCPUパワーを使う＝パフォーマンスガ落ちるという結果になる。
グローバル変数は最適化してレジスタ割り当てしにくいから、最近のプロセッサだと
優位な性能差が出るかは微妙だぞ。
0264デフォルトの名無しさん
NGNGこんな文章、どっかで読んだ覚えない？
文法が単純な場合。文法が複雑な場合には
文法を表現するクラス階層が大きくなり、
管理できなくなる。そのような場合には、
パーサジェネレータのようなツールの方が
適している。
0265デフォルトの名無しさん
NGNGパーサジェネレータって yacc だけじゃないぞ。
ANTLR とか調べてみ。
0266デフォルトの名無しさん
NGNGグローバル変数多用、非同期に割り込み処理がかかるプログラムを解析する
よりはマシだ。（某交換機とか）
0267デフォルトの名無しさん
NGNGあと、t-genとか。
ＯＯじゃなければサブルーチン群はＯＯのクラス群の1/10程度に減ると
思うよ。
クラス爆発の原因の大部分がＯＯとクラスが自ら招いた問題を解決
するマッチポンプな構造に由来しているから。
0269デフォルトの名無しさん
NGNG0270デフォルトの名無しさん
NGNG記述しなければならないものが同じだけあっても、
何度か同じ記述が繰り返されているときにも
Cなどではそのまま関数の中に埋め込んでしまいがちなのに比べて
OO言語ではメソッドとして切り出すことが促進されている
ってだけの話でしょ。
もちろん、この違いはクラスやオブジェクトという枠組みによって
名前空間や可視性を柔軟に指定できるという点に負うところが多い。
0271デフォルトの名無しさん
NGNGどうも関数呼び出しによるオーバーヘッドが解っていないようだな。
同時に複数の処理が呼び出された場合で割り込み処理が絡んでくる場合を考えてみると良い。
レジスタのSPの値が違ったり入れ替わっただけで正確な処理がされない、あるいは暴走するだろう。
0272デフォルトの名無しさん
NGNG1/10は絶対に無理そうだが・・・
クラスは関数と違って、ネームスペース（あるいはパッケージ）のほかに継承という構造を持っている。
もしすべてのクラスがフラットなら覚えるのは大変だが、継承＆ネームスペースによって構造化されたクラスを覚えるのは難しくない。
0273デフォルトの名無しさん
NGNG割り込みもまともに処理できない処理系をお使いで？
0274デフォルトの名無しさん
NGNG割り込みと関数呼び出しとの違い説明しな。
実際に一万行ぐらいの書いて見りゃ判るよ。
0276デフォルトの名無しさん
NGNGコンテキストの待避/回復とか割り込みマスクの解除/設定とか、
あとアーキテクチャによっては別のスタックに飛ぶこともありますなあ。
処理の中身も要求によっては再入可能（re-entrant)にせにゃならん場合もあるねぇ。
で、何が問題なの？
0277デフォルトの名無しさん
NGNG> で、何が問題なの？
何なんだろうね。OO とまったく関係ない気がするんだが。
0278デフォルトの名無しさん
NGNG同じだけのサービスを提供するライブラリについて、手続的なら簡単でOOなら理解できないなんて、
サッパリ理解できんわ。
これでも一応はOO言語のライブラリ構築で自分の担当分だけでも１０万行は軽く超えているんだが、
全然わからん。詳細説明きぼーん。
ＯＯ信者はデムパばかり・・・。
誰が「理解出来ない」と書いた？1/10をどう読むとそう変換されるんだ？
デムパ氏ね！
0280デフォルトの名無しさん
NGNGおいおい、説明できなくなると電波呼ばわりかよ（ｗ
0281デフォルトの名無しさん
NGNG> クラス爆発の原因の大部分がＯＯとクラスが自ら招いた問題を解決
> するマッチポンプな構造に由来しているから。
具体的に例をあげて説明してくれないか?
0282デフォルトの名無しさん
NGNG入力の変換が行われています。
「担当」「１０万行」というのは全て妄想でしょう。
実際は試用期間中で社内クラッキングやセクハラがばれてクビ確定の
デムパＰＧだとプロファイリングしてみる。
0283デフォルトの名無しさん
NGNG妄想は良いから、技術的な方向で話を頼む。
0284デフォルトの名無しさん
NGNG藁多。それなら >>275 の
> 実際に一万行ぐらいの書いて見りゃ判るよ。
は亜空間デムパ、絶好調オンエア中だわな（プププ
0285デフォルトの名無しさん
NGNG0286デフォルトの名無しさん
NGNG0287ﾈｶ心者
NGNGまず初めに「複雑な問題は分割しよう」ってのがプログラムを作成する際のお約束でしょ。
たとえば Ａ ってシステムを作るとき、それが a と b という（比較的簡単な）部分に分割されたとする。
で、a の動作が完全で、なおかつ b の動作も完全なら Ａ は完全なシステムって話になる訳だ。
非オブジェクト指向の奴がシステムを分割する際は a と b はそれぞれ（まぁ、普通は）手続きとして、
また、オブジェクト指向の奴の場合は a と b はそれぞれオブジェクトとして実装するのだろう。
そしてその後、とりあえず a と b らしき物ができたとして、それらの動作の完全性を保証する
必要がある訳だが、そのためにはどういうテストをすればいいかというと、手続きとして分割した場合は、
・全ての入力に対して
・全ての出力が正しい
ならば、完全といえるのに対して、オブジェクトとして分割した場合は
・全ての状態の時に
・全てのメッセージに対して
・全ての振る舞いが正しい
という様にならなければいけない訳だろ？
テストをする条件が少ない分、非オブジェクト指向の方が「勝ち」っていうのは駄
0289デフォルトの名無しさん
NGNG現実問題として、
> ・全ての入力に対して
> ・全ての出力が正しい
これはテスト不可能。たとえば Win32 環境で int 引数二つをとる関数があったとすると、
その入力全てをテストするには 2^64 通りのテストが必要になるでしょ。
それと、手続き型で組もうが、現実には簡単な副作用のない関数だけには分割できな
い。たとえば Windows プログラムなら、
RegisterClassEx() でウィンドウクラスを登録して
CreateWindow() でウィンドウを作成して
ShowWindow() でウィンドウを表示して
メッセージループを回す
みたいに、相互に依存性がある分割にせざるを得ない。
0290デフォルトの名無しさん
NGNG> 手続きとして分割した場合は、
> ・全ての入力に対して
> ・全ての出力が正しい
> ならば、完全といえるのに対して、
ダウト。
オブジェクトとして分割した時にそのオブジェクトの状態が必要な場合には
手続きとして分割した時にも、その状態を共有する必要があるわけだから、
（非局所変数として実装されるのが典型的だね）
オブジェクトとして分割したときに
> ・全ての状態のときに
が必要な状況では、手続きとして分割したときにも
・全ての状態のときに
が必要になる。
逆に、共有されている変数へのアクセス経路が限定できる分だけ
オブジェクトとして分割したほうがユニットテストをしやすくなる。
0291デフォルトの名無しさん
NGNG0292デフォルトの名無しさん
NGNGage 荒らしの方が許せんよ、俺は。
0293デフォルトの名無しさん
NGNG>コンテキストの待避/回復とか割り込みマスクの解除/設定とか
OO信者は所詮その程度の解釈か。そういうのはシステムコールで実装されてんの。
まあOS上のソフト作るだけだから無理も無いか。
割り込み発生する事にプロセッサは実行中のレジスタの値をスタックへ一旦保持をして
ハンドラ内で処理をし、退避していた値をまた戻しreti命令によって呼び出しもとへ戻らなければいけない。
スタックをタスクごとに別領域に設けることもあるが、多重割り込みやマルチプロセス、マルチスレッドな環境
では同一空間で処理をする。
そしてスケジューラが行う処理にはタスクの切り替え処理も含まれる。
その切り替えタイミングはタイマ等による割り込み処理であり、その処理をOOPで
やると関数呼び出しによるオーバーヘッドが増えてしまう。
つまりまともなOSは作れないってこった。
0294デフォルトの名無しさん
NGNGOOと非OOの成功率は？ 本場アメリカではどうなのよ
0295デフォルトの名無しさん
NGNGreti って、またずいぶんプロセッサ依存の話を持ってきたな。
タスク切り替えの話と OO の関係が見えないんだが、
> その切り替えタイミングはタイマ等による割り込み処理であり、その処理をOOPで
> やると関数呼び出しによるオーバーヘッドが増えてしまう。
気のせい、気のせい。
0296デフォルトの名無しさん
NGNG> OO信者は所詮その程度の解釈か。そういうのはシステムコールで実装されてんの。
> まあOS上のソフト作るだけだから無理も無いか。
プププ、自己矛盾してるね（藁
> 割り込み発生する事にプロセッサは実行中のレジスタの値をスタックへ一旦保持をして
だから、それってコンテキストの待避でしょ。そんでもって、
> ハンドラ内で処理をし、退避していた値をまた戻しreti命令によって呼び出しもとへ戻らなければいけない。
これはコンテキストの回復。
> スタックをタスクごとに別領域に設けることもあるが、多重割り込みやマルチプロセス、マルチスレッドな環境
> では同一空間で処理をする。
アーキテクチャによっては別のスタックに飛ぶってことだね。
結局は>>276が言ってること繰り返しているだけ。しかも
>その処理をOOPでやると関数呼び出しによるオーバーヘッドが増えてしまう。
の根拠が不明。
何故OOPでやるとコンテキストスイッチが関数呼び出しにならなきゃいけないの？
しかも、それだけでOS全体を否定する。謎としか言いようがない。
0297デフォルトの名無しさん
NGNG0298デフォルトの名無しさん
NGNG折れもわけわからないのだが、
「OOで設計ないし実装すると、割り込みハンドラの内部で関数呼び出しをしなければならない。」
という御主張なのかなあ、と思ってみるテスト。
0299デフォルトの名無しさん
NGNG関数ポインタで直接ジャンプするか、
委譲の繰り返しで、関数コールがネストするかの違いじゃないの？
0300デフォルトの名無しさん
NGNGOOだからって、コンテキストスイッチのたびに委譲の繰り返しでネストする必然性はないんだけどなぁ。
メッセージ送信にしたって、あらかじめ実行されるメソッドがわかっているものについては
コンパイル時に探索を解決して単純な関数呼び出しとして扱ったり、
さらにそれをインライン展開したりする最適化も存在するわけで、
OOだからといって、必ずしもオーバーヘッドが発生する実装しかできないわけじゃあないのだが。
まあ、よくある誤解ではあるけどね。
Smalltalkなんていう、かなり純粋なOO言語でも、
特定のメッセージ送信をインライン展開するコンパイラがあるっていうか、
それが普通なんだけど。
0301297
NGNGＯＯＰであるがゆえに、割り込みハンドラ内部で関数呼び出しを（余分に）
行わざるを得ない場面って、無いよねぇ。
0302デフォルトの名無しさん
NGNGシステムコールしか扱わない奴には何言っての解らんとはおもうが。
0303デフォルトの名無しさん
NGNG0304デフォルトの名無しさん
NGNG抽象化による保守性の向上と、実行速度のトレードオフと言う話なのね。
そんなモン目的によって使い分けるだけちゃうの？
0305デフォルトの名無しさん
NGNG割り込み処理の終了だな。
0306デフォルトの名無しさん
NGNG割り込みの話をしているときに「コンテキストの待避」といえば
（プログラムポインタを含む）レジスタ群をスタック上にダンプすることだ
というのは常識だとおもうのだが。
っていうか、それ以外の何の事だと思ったわけ？
ついでにいうと、そんぐらい自動的にやってくれるプロセッサも多いんだけどね。
0307303
NGNG0308デフォルトの名無しさん
NGNGそうなんだよね。ついでに言うと、
「どうしてもパフォーマンスを出さなきゃいけない箇所を切り出して徹底的にチューニングする」
あるいは
「それでもどうしても要求されるパフォーマンスが出ない時にはその部分だけ他の言語で実装する。
しかし全体はきちんと抽象して設計/実装するし、他の言語で実装した部分も全体に無理なく適合させる。」
という選択肢もあるっていう点も、アセンブリとCの関係と同じ。
0309デフォルトの名無しさん
NGNGこれだと、オブジェクトの入出力がプロパティという形で目に見える。
その効果もその場で（設計段階で）目で確かめられる
またそれに関連するコードがイベントという形でどこにあるかすぐに探せる
だからコンポーネントは戦場でも非常に有効というか火消し役になりえる
単なるクラスとは大違いだと思う
0310デフォルトの名無しさん
NGNG一般的なReturnInterruptのつもりで書いたのですけど。
Cでサポートしてる場合は
#pragma で宣言して記述する。
0312デフォルトの名無しさん
NGNG>ついでにいうと、そんぐらい自動的にやってくれるプロセッサも多いんだけどね。
そんなプロセッサは存在しない。
嘘つくな（ｗ
これもある種のOOの弊害だな。
0313デフォルトの名無しさん
NGNG0314デフォルトの名無しさん
NGNG存在するよ。
http://www.infineon.com/jp/products/mcu-dsp/tricore/c9804_tricore.pdf
http://www.be.wakwak.com/~murasakigawa/tech/dsp/execpipe.html
0315デフォルトの名無しさん
NGNG> そんなプロセッサは存在しない。
常識なさすぎ。
ついでに言えばカーネルモードとユーザモードでレジスタを共用しないプロセッサも
多いぞ。この場合には、ユーザ空間からのシステムコール呼び出しではレジスタの
退避は必要ない。（割り込みはネスとする可能性があるから、話が別だが）
0316デフォルトの名無しさん
NGNGソフトウェアの全ての要素をオブジェクトにして
手続き的な部分を一切なくすってわけじゃないが。
ソフトウェアをオブジェクトという観点で切り刻んで構成すると
結構見通しがいいよってだけで。
必要もないのに
「int? char? はぁ？Integer オブジェクトに Character オブジェクトでなければ許しがたい」
などという教条主義者は確かに必要なし。
0317デフォルトの名無しさん
NGNGなんでも OO のせいにするなよ（ｗ
ちなみに、それは OO の弊害ではなくてプラズマのせいです。
0318312じゃないけど常識なし
NGNG>カーネルモードとユーザモードでレジスタを共用しないプロセッサも
>多いぞ。
へー、知らんかったYO！最近のプロセッサはOSの仕組みに迎合するように
なったのねー。Javaチップみたいなもんだな。
0319デフォルトの名無しさん
NGNGそうなんだよね。
手続き型ベースなOO言語では逐次実行なんかの手続き的な概念が必ず残るし。
ただ、Smalltalkマンセーな俺的には整数や文字もオブジェクトなほうが快適だけどね。
別にオブジェクトにしたからといって、インスタンスにメモリをアロケートしなきゃいかん
っつーわけでもないし。たまにそういう誤解もあるんだけど。
0320312じゃないけど常識なし
NGNG>必要もないのに
>「int? char? はぁ？Integer オブジェクトに Character オブジェクトでなければ許しがたい」
>などという教条主義者は確かに必要なし。
あー、レベルは違うけど、可読性向上などが何らメリットをもたら
さない状態なのに、既存の既に動いているプログラムをデザパタ適用
して切り刻むアフォならうちの会社にいるぞ。この忙しいのに…
リファクタリングって、すべき時、すべきコードと、そんなことする
べきでないとき、コードってのがあると思うんだけどね。
0322デフォルトの名無しさん
NGNGデザパタでも OO でもそうだが、
使い方が分からないやつは初心者
使い方が分かったら中級者
使いドコロを抑えて、使うべきでない時を見極められたら上級者
って事だな。
0323319
NGNG整数や文字がオブジェクトでなければオブジェクト指向じゃないなんて
言うつもりは、これっぽっちもない。
ただ、オブジェクトになっていたほうが多くの場合により本質に着目できる、とは思う。
あくまで「多くの場合」ね。
>>320
ま、OOがどうのというよりも、コードのマネージメントの問題だよね。
0324デフォルトの名無しさん
NGNG単に
OO の本質を重視するか、
既存の環境との互換性や効率を重視するか
というトレードオフだよね。言語は道具だから、解こうとする問題にあわせて選択すれば
OK。
0325デフォルトの名無しさん
NGNGもはや、何を言いたいのかサッパリだな。
今日は日が悪いから、出直してきなよ。（ついでに、こっそり最近のプロセッサアーキテ
クチャと OO の動向についてカンニングしとけ）
0326実は321とかいろいろ
NGNGコードの再利用性を考えると、システムコールでの抽象化は必要だと思ったまでよ。
これから転職でも考えるか。
0327デフォルトの名無しさん
NGNG適材適所。
0328デフォルトの名無しさん
NGNG戦場でもDelphiスタイルのコンポーネント指向はとても有効だと思うよ
これだと、オブジェクトの入出力がプロパティという形で目に見える。
その効果もその場で（設計段階で）目で確かめられる
またそれに関連するコードがイベントという形でどこにあるかすぐに探せる
だからコンポーネントは戦場でも非常に有効というか火消し役になりえる
単なるクラスとは大違いだと思う
0329デフォルトの名無しさん
NGNGつーか時代の流れについていけない奴が最も糞。
0330デフォルトの名無しさん
NGNGOOでカーネル組んで何か問題でも？
0331デフォルトの名無しさん
NGNGいや、別段問題があるというわけでは…。
■ このスレッドは過去ログ倉庫に格納されています