オブジェクト指向は戦場では必要無し その２
■ このスレッドは過去ログ倉庫に格納されています
0001あたたたた
NGNGを理解する労力が大きく、目的まで達成するのに時間がかかる。
他人のソースを見るにも複雑でときほぐしにくい。
ちゃんと整備されたドキュメントがなければ粗大ゴミソース。
またオブジェクト指向が○○に優れているとかいう話も、あくまでちゃ
んと設計され、ちゃんと実装されたクラスがあるという前提での話。
実際は世の中にどれだけの糞SEや糞PGがいることか。。。
よってオブジェクト指向は戦場では使いものになりません。
前スレ http://pc.2ch.net/test/read.cgi/tech/1011997945/
いつの間にかスレが1000に達しようとしていました。たくさん
の意見ありがとうございます。
前スレでの議論の結果、やはりというか当然というかオブジェ
クト指向の戦場での実績や有効性には大きく疑問が残るという
結果となりました。。。
皆さんも本当に何が残ってゆく技術なのか、何がイマイチぱっ
とせずに中途半端に終る技術なのか見きわめて、技術を習得して
いきましょう。
0446将軍
NGNG管理も大変だし。戦場ではいらん。
0447デフォルトの名無しさん
NGNG座標の精度上げるのに、int→doubleにするんなら、
intのインターフェース残す意味あるかもしれない。
でも、解像度が上がって足りなくなったから、
short→longにしよう、っていうなら、古いインターフェース
では、桁あふれ起こした座標しか扱えないんだから、
古いインターフェース残す意味無いし。
0448デフォルトの名無しさん
NGNG（´・ω・｀）ｼｮﾎﾞｰﾝ
↑
OO信者
0449412
NGNG>ただし、その状況次第ってのは例えばAWTやWin32のPointの場合は実際に
>...
>privateにしても全体のパフォーマンスに有意な差がなければ、
>conservativeにprivate宣言したほうがいいと思うが、どうよ？
何を実測するのかわからないが、少なくともpublicのほうが速いだろ。
使用ドメインを特定できないんだから、全体のパフォーマンスなんてどうやって計るんだ？
「そのパフォーマンスの低下が問題にならないようなものを対象とする」というならいいが。
それにパフォーマンスの問題だけじゃないよ。
a.x = b.x + 3;
と言うコードが
a.setX(b.getX() + 3);
になるのは非常に読みにくい。最初のバージョンは数学的な表現で直感的だ。少し複雑な
座表計算を行えばすぐにアクセッサ経由の記法は限界を迎える。
>>445
Pointが拡張されることが予測されているなら、アクセッサのほうに分があると思うけど？
既存の古いインターフェイスを使って計算するライブラリがあったとして、そのライブラリで
計算したPointオブジェクトを新しいインターフェイスでアクセスしたくなったらpublic方式は
困るだろう。
publicにしていいのはこれ以上拡張されることを想定していないからだよ。
0450通りすがりだからログなんかよんでないぞ
NGNG演算子オーバーロードマンセー
シンタックスシュガー万歳
Ｃ＋＋マンセー
0451デフォルトの名無しさん
NGNG俺にもわかるように。
0453404
NGNGチューニングする時にはやみくもに局所的な最適化をするよりも
ホットスポットを特定して最適化したほうがいい。
つまり、全体のパフォーマンスにどれぐらいの影響が出るかは
ホットスポットの中でのPointクラスへのアクセス頻度できまる。
例えばWin32ならばアクセサに直接起因するオーバヘッドが
描画自体のボトルネックよりも十分に小さいこともありうる。
>>449
まず、数学的に見える表現式ならば、どんな複雑な計算式でも
a.setXは1つの式あたり通常1個所だけ。したがって複雑さとは関係なし。
a.getX()がそんなにイヤならばa.x()という表現でもいいし、
Eiffelなど、 言語によってはa.xという表記でC++でいうa.x()を表わすものもある。
よってアクセサ自体に本質的な問題というわけではない。
もちろんC++のみに限定して議論するというのなら、a.x()ということになるが。
0454412
NGNG>チューニングする時にはやみくもに局所的な最適化をするよりも
>...
>例えばWin32ならばアクセサに直接起因するオーバヘッドが
>描画自体のボトルネックよりも十分に小さいこともありうる。
「想定されるどんな場合でもこのオーバヘッドは無視できる」じゃない限り、意味ないとおもうが。
不特定多数の人間が使うライブラリでどうやってそれを測定するんだ？
実測なんぞ不可能で、予測するしかないだろう。
>まず、数学的に見える表現式ならば、どんな複雑な計算式でも
>a.setXは1つの式あたり通常1個所だけ。したがって複雑さとは関係なし。
複雑と言うのはたくさんの式と言うことだ。20個のsetXがあったら読みにくいと思うが。
>a.getX()がそんなにイヤならばa.x()という表現でもいいし、
a.x()ならだいぶ評価が変わる。getXだから複雑に感じるだけ。
>Eiffelなど、 言語によってはa.xという表記でC++でいうa.x()を表わすものもある。
まさしくそうだ。言語がサポートしてくれるのならなんの問題もなくアクセッサでいい
0455404
NGNG> 不特定多数の人間が使うライブラリでどうやってそれを測定するんだ？
> 実測なんぞ不可能で、予測するしかないだろう。
個々の機能のパフォーマンスを実測する。
AWTやWin32なら、標準で提供するウィジットの描画や更新など。
もちろん使用対象での全パフォーマンスへの影響までは実測できないが、
現実に則した予測は可能でしょ。
少なくとも「アクセサなんて遅くなりそうじゃん」よりは現実的なデータが求まる。
> 複雑と言うのはたくさんの式と言うことだ。20個のsetXがあったら読みにくいと思うが。
それって、
a.x = b.x * c.y - c.y - b.x;
a.y = ..............
b.x = ..............
: (以下似たようなのが20個ぐらい続く)
みたいなケースだよね？
こういう場合、セッターは1つの文の最外・最左に1つ出るだけでしょう。もちろん代入演算子のほうが読みやすいのは確かだけど、
一番左に縦一列に並んでいるだけなら何とか我慢できない？
直感的にはわかりにくいけど、間違えを誘発するようなものでもないと思う。
0456412
NGNG>AWTやWin32なら、標準で提供するウィジットの描画や更新など。
よくわからんがPointはライブラリの中でしか使わないと言う前提？
>もちろん使用対象での全パフォーマンスへの影響までは実測できないが、
>現実に則した予測は可能でしょ。
>少なくとも「アクセサなんて遅くなりそうじゃん」よりは現実的なデータが求まる。
アプリ側でPointを使うことを想定するなら確実に遅くなる例はいくらでも思い付くぞ。
「遅くなりそうじゃん」なんてもんじゃなく「遅くなる」だ。(しかも実験するまでもなく)
>一番左に縦一列に並んでいるだけなら何とか我慢できない？
我慢は出来る。
>直感的にはわかりにくいけど、間違えを誘発するようなものでもないと思う。
まあね。
0457デフォルトの名無しさん
NGNG戦場と関係ない話は別のスレでやってくれ。
実質的にスレが止まっとるぞ。
0458デフォルトの名無しさん
NGNG（´・ω・｀）ｼｮﾎﾞｰﾝ
↑
OO信者
0459414
NGNG> アプリ側でPointを使うことを想定するなら確実に遅くなる例はいくらでも思い付くぞ。
そういう場合にはアプリ側に適したPointクラスを使うもんでしょ。
適材適所ね。
>「遅くなりそうじゃん」なんてもんじゃなく「遅くなる」だ。(しかも実験するまでもなく)
a.xとa.x()じゃ、a.xのほうが断然速いのは当たり前。
それがどれぐらい全体に影響を与えるかが問題。
「Pointのアクセサ経由しなくなったおかげで
ウィジット描画性能が平均0.2%向上しました。」
は多くの場合技術者として正しい選択とは思えないっつーこと。
その0.2%がクリティカルでなければね。
0461デフォルトの名無しさん
NGNG俺は AWT は Win32 の Point は構造体で十分だと思ってるが
> a.xとa.x()じゃ、a.xのほうが断然速いのは当たり前。
これはダウトだろ。
MS が提供する WTL に POINT, RECT やらのラッパクラスである CPoint, CRect
なんかがあるんだが、主要な operator はすべて inline 定義されていて、最適化
するとまったく差がないぞ。
> 「Pointのアクセサ経由しなくなったおかげで
> ウィジット描画性能が平均0.2%向上しました。」
それ以前に、設計の最重要項目は
ソフトウェアの複雑さを抑制すること
だろ。POINT にさまざまな機能やら int, long 複数の型を突っ込んだ結果として
学習が複雑になったら本末転倒だ。
そのばあいには lseek, lseeko のように API 分けちゃうのが一般的な解決だと
思うが。
0462デフォルトの名無しさん
NGNGつかもうネタが無いんだよ！
ネタ拾って来いや！
0463デフォルトの名無しさん
NGNG414 に聞きたいんだけど OO は「何で」勉強した？ OO に関して読んだ書籍や
レポートをざっと挙げてもらえると嬉しいんだけど。
0464デフォルトの名無しさん
NGNGそもそも、スレが進んでたことないじゃん。無限ループはしてたけど。
0465デフォルトの名無しさん
NGNG0466412
NGNG>そういう場合にはアプリ側に適したPointクラスを使うもんでしょ。
Pointクラスをライブラリの内部だけで使うことを想定するっつーことか？
>a.xとa.x()じゃ、a.xのほうが断然速いのは当たり前。
>...
>は多くの場合技術者として正しい選択とは思えないっつーこと。
>その0.2%がクリティカルでなければね。
何遍も繰り返しになるが、Pointクラスを作る時の思想として、アプリ側では使用しない
とか、パフォーマンスを要求される処理には使用しない、とかあれば君のいうとおり。
「使用対象がはっきりしなくちゃ設計は出来ない」
0467414
NGNG単なる抽象データ型でも押さえられる様な話だったからねぇ。
「何で」ってのは言語の事か？主に使ってる言語はSmalltalk。
最初の出会いから十数年、開発に使っているのはだいたいSmalltalk。
Javaもたまには書くけど、あんまり仕事に使いたいとは思わない。
最近はPythonも面白いと思って遊んでいる。
書籍といわれるとねー、やっぱSmalltalkのブルーブックだろ。
Bertrand MeyerのObject-Oriented Software Constructionも
Smalltalkとは違う視点でいい本だと思う。
OOが主題じゃあないけど、CardelliとWegnerの
On Understanding Types, Data Abstraction, and Polymorphism
も印象に残っているペーパーだな。
0468414
NGNG> 何遍も繰り返しになるが、Pointクラスを作る時の思想として、アプリ側では使用しない
> とか、パフォーマンスを要求される処理には使用しない、とかあれば君のいうとおり。
アプリ側から完全に排除は出来ない、とした上で、
アプリ側がどのような状況でどのクラスを使うか、
具体的にはAWTのPointをどの範囲で使うかは
アプリ側の設計の問題。AWTの設計には関係ない。
0469デフォルトの名無しさん
NGNG外向けには宣伝してないだろうけど、プロジェクト終了後にケーススタディを
紹介する会合なんかは実在してる。
OO の大御所にマーチン・ファウラーという人間がいるが、彼が関わってる企
業のリストなんかを眺めると、どのあたりで OO が「使われてる」かは分かる
ぞ。
っつか、この世界、黙って口を開けている人間にわざわざ餌を運んでくれる
親切なやつはいない。本気で情報が必要なら、自分で金や人脈を使って探
さないと。
0470デフォルトの名無しさん
NGNG> 「何で」ってのは言語の事か？
いや、書籍やレポートの方。紛らわしい書き方だったな。
しかし少ないな。ほんとにそれだけ、それとも面倒だから抜粋した？
0471412
NGNG>アプリ側から完全に排除は出来ない、とした上で、
>アプリ側がどのような状況でどのクラスを使うか、
>具体的にはAWTのPointをどの範囲で使うかは
>アプリ側の設計の問題。AWTの設計には関係ない。
本気か？Pointがどの範囲で使われるか想定しないで
どうやってx,yをpublicにするかどうか決定するんだ？
どうやって必要なメソッドを決定するんだ？
もちろんPointはAWTのインターナルユースでしか使われない、という設計目標なら
AWTとその使用アプリの設計は関係なくなるが。
0472418==432
NGNG0473デフォルトの名無しさん
NGNG>>465
まだ成功してるとはいえないが
今やってるシミュレータの開発なんかになると、
非OOの言語だと仕様で複雑なアルゴリズム考えて実装させてる感覚が強いが
OOだと自然現象をそのまま実装してる感覚が強い。
結果的に計算方法は一緒なんだが、実装ははるかにOOのほうが楽。
OOによるソフト的なパフォーマンスの低下は前述の通り？だろうが
ソフト設計〜実装に関してはOOの方が断然コストが低いと思うのだが。
0474デフォルトの名無しさん
NGNGシミュレーションでは、シミュレーション対象の個々の要素が比較的自然に
OOPL のインスタンスと対応するから、特に OO 向きのアプリケーションだ
ね。
ただ、シミュレーションプログラムだけから
> ソフト設計〜実装に関してはOOの方が断然コストが低いと思うのだが。
この結論もってくるのは、ちと結論を急ぎすぎだと思う。
たとえば金融アナリスト向けのソフトウェア開発なんかを考えてもらうと良
いんだが、大抵のソフトウェア開発でまず問題になるのが
クライアントの世界の用語や概念理解と、システム開発者の間に著しい
開きがある
という点。OOA/OOD ではクライアントの問題意識に近い形で設計をする
ことになるから、分析担当者だけでなく設計担当者もクライアントの世界
に足を踏み入れる必要がある。
それが最終的にはソフトウェアの柔軟性につながるわけだが、短期的には
設計者への負担となるし、設計がクライアント側の意識に引きずられてプロ
グラミングの実態から乖離する危険性もある。特に、
「あとは実装段階で個別に対処すれば十分だよ」
というレベルの詳細まで設計に織り込んでしまい、かえって柔軟性を損なう
話は良く聞く。
あとは実装レベルでも、使える実装者を集めるのが非 OO の従来型開発
に比べると難しい／高くつく／育てる方法が根付いてない組織が多いとい
うのはあると思うな。
0475414
NGNG> しかし少ないな。ほんとにそれだけ、それとも面倒だから抜粋した？
あたりまえだろ。特に印象に残っていて毛色が違うのを厳選した。
お前はどうなんだ？どんな本読んだか聞かれたとき厳選しないのか？
>>471
> 本気か？Pointがどの範囲で使われるか想定しないで
> どうやってx,yをpublicにするかどうか決定するんだ？
はあ？お前、ライブラリ設計者が予め想定できるようなありふれたアプリしか書いてないのか？
つーか、じゃあAWTが想定しているPointの使用範囲ってのを全てのアプリを考慮して言ってみろよ。
過去書かれたアプリも、未来に書かれるかもしれないアプリも、全て考慮に入れてな。
お前の説じゃあ、それができなきゃライブラリなんて書けないんだろ？
0476
NGNG0477デフォルトの名無しさん
NGNG> じゃあAWTが想定しているPointの使用範囲
非ユークリッド空間の点座標じゃないことは確かだな。
0478デフォルトの名無しさん
NGNG毛色が違うヤツじゃなく、むしろ王道の方を紹介するのが普通だと思われ。
っつか、お奨めがあるようなら読んでみようかと思ったんだが。
0480293
NGNG>Eiffelなど、 言語によってはa.xという表記でC++でいうa.x()を表わすものもある。
>よってアクセサ自体に本質的な問題というわけではない。
Eiffelなら、必要になるまでアクセサ書かないよな。
0481デフォルトの名無しさん
NGNG> 絶版だけど。
ダメじゃん。
0482
NGNG本題にもどっていいか？
0483デフォルトの名無しさん
NGNG本題って……まだ話すことがあったのか？
0484
NGNG２）職場に信者がいたら、帰り道で待ち伏せて袋にする。
３）特定伝染病に指定して患者を隔離する。
４）職場でＯＯＰＬ使ってる人は積極的に非ＯＯの工夫を報告し会う。
などなど・・・。
0485
NGNG６）布教者を集めて穴に埋める。
0486デフォルトの名無しさん
NGNG現存するオブジェクト指向のライブラリを非オブジェクト指向にしても
オブジェクト指向よりも使いかってが悪くならないことを証明すればいいのに。
まぁ無理だろうがな。
0487
NGNG0488デフォルトの名無しさん
NGNG１が言いたいのは、ＯＯＰが役にたたないということではなく、
きちんとＯＯＰができる優秀なＰＧ・ＳＥなどほとんどいないうえに、
きちんとＯＯＰがされてないプログラムがシステム中に一部にでもあったら、結局システム全体はＯＯＰではなくなってしまうのだから、
ＯＯＰなど絵に描いた餅だといいたいいだとおもう。
0489Rubyist!
NGNG0490デフォルトの名無しさん
NGNG１はずっと非ＯＯＰで書いてたらいいんじゃないか。
0491デフォルトの名無しさん
NGNGひとつの事がやりたいだけなのに１０個近くのクラスをイモヅル式に
初期化してメソッドに渡さないとだめだったりとか
それだけのために結構な行数になるし、すごくめんどくさいのは確か。
関数だと一発呼び出しで終るのになって思うけど。
0492デフォルトの名無しさん
NGNG設計がマズイ気がする…
0493デフォルトの名無しさん
NGNG>初期化してメソッドに渡さないとだめだったりとか
？
これって関数コールだよね、メソッドと言いながら。
これはOOPじゃないが．．．
せめて親イモが子イモを初期化するようにしたら？
0494通りすがり
NGNG某大企業にゆうてくれ。
>>492
メソッドの引数がクラスだから、
それらを初期化せなあかんのよ。
で初期化っていうのがまた、
別のクラスを引数にして生成せなあかんから、
結局すさまじい手間になるのよ。ネズミ算式に
というか、イモヅル式というか、クラスが
どんどん膨らんでゆく。。。こういうのがあるから
C++は嫌い。関数にして欲しい。
0495デフォルトの名無しさん
NGNGクラスの中にクラスのオブジェクトを保持してくれるから便利なんでしょう。
メソッドにクラスが要るって、どーゆーことよ。
0496a
NGNGまじかよ！！
俺最近OOPじゃねー言語なんて
使いたくね〜よ。
これほど再利用するさいに頭にすんなり
受け入れられる構造なんてないじゃねーか。
戦場とか関係なくただ単に処理する用途、環境で
言語は選ぶもんだ。戦場だってマシンガンだけじゃ戦えね〜だろ。
こんなのがスレの本筋だったら2chにきてるプログラマーは
みんな駄目野郎なのか??
いやそんなことはねーはずだ2chのFellowsは。
きっと厨が多いだけなんだろう。
0497デフォルトの名無しさん
NGNG俺が担当してるモジュールは、すっきりＯＯで設計、実装してるよ。
unittestの環境もちゃんと整えてあるし、エラーチェックもちゃんとやってる。
言語はC++。
だから、プロジェクトがデスマーチになって（なってるんだけど）、障害票が沢山
上がってきても、自分のモジュールのせいじゃない事は、すぐに証明できる。
自分のモジュール内のクラスの役割や責任範囲をはっきり定義できるＯＯの
おかげだと思ってるよ。
まぁ、自己防衛だけのためにでも、ＯＯはやっとけってこった。
0498デフォルトの名無しさん
NGNGいや、すごく正しいと思うんだけどさ、
自分のモジュールの責任ではない証明を
理解する能力を周りの人間が持っているということは
とてもありがたいことだと思うよ。
0500デフォルトの名無しさん
NGNG>で初期化っていうのがまた、別のクラスを引数にして生成せな
>あかんから、結局すさまじい手間になるのよ。ネズミ算式に
>というか、イモヅル式というか、クラスがどんどん膨らんでゆく。。。
それがOOの醜いところ。
0501デフォルトの名無しさん
NGNGDirectX の下手くそなラッパーライブラリでそういうのを見たことがある。
0502デフォルトの名無しさん
NGNG関数にしたっていっしょ。クラスが構造体か変数と関数になるだけ、
ほとんどのクラスは構造体と関数に分離されるから、よけい増える。
0503デフォルトの名無しさん
NGNGそれ C にしたところで、
メソッドの引数が、別の構造体へのポインタで
別の構造体のフィールドに、さらに別の構造体へのポインタがあって
…
となるだけだと思うけど。
0504デフォルトの名無しさん
NGNGわかってないだろ。
0505デフォルトの名無しさん
NGNG設計の悪さを何でもOOのせいにするのがアンチの醜いところ。
0506デフォルトの名無しさん
NGNG何言ってるのお前？根本的に違うだろーが。
0507
NGNGコボラーがやってた、「仕様書をほとんど一対一でコードにおとすだけ」
に近いくらいになる。
それに仕様変更にとても弱い。
0508デフォルトの名無しさん
NGNGあ〜始まったよ。OO信者の口ぐせ「それは設計が悪いから」。
お前の設計はよほど完璧なんだろうなってオモウヨ。
まあどちらにしろ大規模なプログラムをしらん、小さいプログラム
をチマチマとしか書いたことない奴の吐く言葉だね。
0509
NGNGまあＣでＯＯしてる分にはそうかもしれないけど、
クラスオンリーのＯＯＰＬだとそうはいかない。
クラスという存在が些細な部分にさえある種の構造を要求し、
その構造が変更を困難にしている。
全部staticメソッドで組むしかないな。
0510デフォルトの名無しさん
NGNG言語もライブラリもOOなのにわざわざ非OOにするの？
まだ非OOの言語もたくさん使われているかもしれないけど、
いま考えられるこれからの主流はOOしかないじゃん。
たしかに今現在はOOは完全に普及してないけど、少し先の未来はOOだらけじゃん。
周りがOOばかりになるのは目に見えているのに、
今だに、OOの有効性を疑問視しているなんて遅すぎるね。
過去のシステムのメンテしかしないとか、少し先の未来で引退するならいいけどさ。
そうじゃないなら、今のコボラーみたいに勉強しないって馬鹿にされるよ。
0511デフォルトの名無しさん
NGNG何処の誰から許可証を得て、それを何処の誰に渡して
トイレに行く権利を得られるって仕組みは繁雑だよな。
この例はまだマシなほうだけど、実際のプログラムでは
もっとめんどくさい手続きしないといけないときがあるからね。
0512デフォルトの名無しさん
NGNGﾊｧ?
ﾊｧ?
0513デフォルトの名無しさん
NGNGうむ、わけわからん。具体的に話をせよ。
たとえばOOならこうなるが、非OOならこうなる。という風に。
0514デフォルトの名無しさん
NGNGOOはそれほど普及しないで、機能をコンポーネント化
してそのオブジェクトを分散するというのが主流になると思う。
それに非OOの手法は絶対になくならない。便利だからね。
0515デフォルトの名無しさん
NGNG今のVBと同じようなもんか？
とりあえず、コンポーネント（といってもクラスだよね）のインスタンスを
作成するとか、そのメソッドを呼び出すとかそういったレベルの知識は
必要ということだよね。
0516515
NGNGあと、コンポーネントを作成/拡張するときにはOOの知識は必要だよね。
0517デフォルトの名無しさん
NGNGここのアンチにわざわざ OO 教えてやる必要ないよね。
っていうか、OO で失敗した奴(「大規模には向かない」とか言う奴)って、
どう考えても OO に対して誤解を持っていたから失敗したとしか思えない。
どの部分に対して用いるか、どの部分が可変で、どの部分が不変か、
そういうのを見誤ってるだけじゃん。
もう相手にすんなよ、自分の失敗を人のせいにするタイプの奴を。
0518デフォルトの名無しさん
NGNGOO信者ひとり戦線離脱(w
0519
NGNGＯＯで大規模作った事あるの？
ソースは何行くらい？
0520デフォルトの名無しさん
NGNG５０００行くらいの大規模なのＯＯで作ったよ。
0521デフォルトの名無しさん
NGNGそれって2人日くらいだろ。
0522デフォルトの名無しさん
NGNG規模が大きいと何か偉いのか？
いやまぁ 1000 行とか言ったら、そりゃプロトタイプか toy program だろうとは
思うけどさ。
0523デフォルトの名無しさん
NGNG俺は 1 日 2500 ステップは書いたことないぞ、さすがに。
0525デフォルトの名無しさん
NGNG0526デフォルトの名無しさん
NGNG0527デフォルトの名無しさん
NGNG一日 2500 行だと、正味 8 時間働くとして毎時 300 行強＝毎分 5 行。それを
二日間続けて、しかも 521 はリリースまでするって言ってるんだろ。どう考え
ても無理だって。
（毎分五行 syntax error なしで書きつづけるのも難しいぞ）
0528デフォルトの名無しさん
NGNGそれともネタなのか？
5000行って大規模には入らんと思うが。
0529デフォルトの名無しさん
NGNG当然ネタだろう。
0530デフォルトの名無しさん
NGNGやっぱ大人数とか画面数が100以上あるとか、
コードとは異なる次元が絡むんでは？
0531デフォルトの名無しさん
NGNG>>474
たしかにその通りだな。
それがこのスレの話題になってるOOのﾂｯｺﾐ所なんだろうな。
結局、要求仕様をどういうレベルで実装させるかってことになってしまうから、
戦場とか非OO設計で考えると、単純に手続きを実装させたほうが速いつーことなんだろう。
たとえば、>>491を車のゲームと仮定すると
道路クラスに所属してる車クラスっていうふうに設計して
基本的な車を実装はそのクラスにまかせて(タイヤが4つあるとか)、
そのクラスを派生させて特殊な車(ターボ車とか大型車とか)を実装すればいい。
で、車インスタンスの管理は道路クラスに任せると。
おれのOOの捉え方としてはコードよりも設計。
シミュレータになると、設計にOOを使うかどうかによって
単なる計算機になるか、物理現象を再現するかくらい*コードの実装*が変わる。
まあ、実際の(ミクロな)コードには差がないわけで
UMLが実用的に(JBuilder6みたいに)なれば問題を解決してくれると思うが。
フリー(か現実的な価格)で便利なUMLエディタきぼんぬ。
0533デフォルトの名無しさん
NGNGMagicDraw はどうよ。
ArgoUML/IIOSS がもう少し stable になればなあ。
もう2年も待ってる。
0534デフォルトの名無しさん
NGNG「一般的」だと曖昧だから、具体例挙げましょうや。
OOPL の祖先である Simula は event based simulation のために作られた
言語ではある。
0535531
NGNGまあ一例だからな。
完全に実装が数式化されてるような物なんかは手続き型で十分かつ速いし。
他のOOが向いてる例を挙げるとすれば、GUIとかだろーな。
ただの道具なんだから必要にあわせて使えば良いと思われ
で、OOPLは非OOでの実装も一応できる？が、
その逆はできない？からOO一種類使ってやったほうが効率的でわ？
0536デフォルトの名無しさん
NGNG「むずかしーけどマスターすりゃきっと便利なはず」ってやつばっかだろ？
正直にいってみろよー！
ま、完全に非OOPLでやるのも辛いけどな。ビシバシのパターン使ってやったら
コードだけじゃどーやったってソース追えないよ
ようは程度の問題、やりすぎは禁物だ。
極論言えばabstractがなくなればちょっと不便にはなるが
人のソース見てここまでわけわかんないって状況はなくなると思うYO!
0537デフォルトの名無しさん
NGNGコードだけで、仕様書も設計書もなしっつーのはデスマーチ直行便だろ。
0538デフォルトの名無しさん
NGNG0540デフォルトの名無しさん
NGNG> いやあＯＯの設計は難しいよ。本気で設計すると、
> コボラーがやってた、「仕様書をほとんど一対一でコードにおとすだけ」
> に近いくらいになる。
何の冗談だ？
「本気で設計すると」じゃなくて
「設計とは何かを勘違いして設計すると」の間違いじゃないのか？
0541デフォルトの名無しさん
NGNG中身がない煽りは、もう良いよ。
0542≠538
NGNG> >>538はライブラリが便利、クラスで書けたって程度だろ。
アンチの妄想大爆発（わら
つーか、はっきりいってやる。
「大丈夫、君は自分で思っているほど駄目な奴じゃあない。
君にはOO以外にも生きていく方法が何かあるはずだよ。
システム開発だけが人生じゃあない。世の中広いんだ。
この失敗にめげないで、他の業界で活躍してくれ。
君の前途に幸多かれ！」
0543531
NGNGOOか非OOかを選択するフェーズは機能設計が終わってソフト設計する頭の部分。
実装レベルになってから論議するのは無意味。
プロのプログラマー限定になってしまうが、
SEの領域は要求仕様から機能設計するとこまでで、
プログラマーの領域はソフト設計から実装までだよね？
要求仕様で言語が決まってるのはよくあることだが（ｗ
0544デフォルトの名無しさん
NGNGＯＯだとそうはいかない。
ソフト設計の細部まで全体設計に含めてやらないければならない。
でないと基底クラスの破綻が全体を駄目にしたりするから。
弊害多し。
0545デフォルトの名無しさん
NGNG> ソフト設計の細部まで全体設計に含めてやらないければならない。
どこで OO 勉強したんだ？ 参考書を挙げてくれ。
■ このスレッドは過去ログ倉庫に格納されています