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

オブジェクト指向はより自然なモデルに即したものではあるが、
クラスを理解する労力が大きく、目的まで達成するのに
時間がかかる。他人のソースを見るにも複雑でときほぐしにくい。
ちゃんと整備されたドキュメントがなければ粗大ゴミソース。
またオブジェクト指向が○○に優れているとかいう話も、あくまで
ちゃんと設計され、ちゃんと実装されたクラスがあるという前提での話。
実際は世の中にどれだけの糞SEや糞PGがいることか。。。
よってオブジェクト指向は戦場では使いものになりません。

自分で２げっと

プログラムはやっぱり体育会系。

まあでも
　○ひとりでやるなら効率的
　○能力差が大きい少人数なら効率的
　○能力のあるグループなら効率的

　という事で

Ruby以外の言語は糞だと何度言ったら分かるのやら。

>>1
しかしOOにより糞SEや糞PGの生産性が落ちるのなら、
「OOは世に糞システムを増やさないという偉大な貢献をしている」
とも言えるな。
OOがなければ糞SEや糞PGのクサレゾンビシステムが山のように… (怖

自分で勉強せん奴に教えるのはもう疲れた

糞PGというか使えんのが多い時は　
しょうがないからスクリプト作ってスクリプト触らせてる。
OOで共同でやるより効率的になった

なんでもかんでも新しいものの方が優れているということにはならんからな。
そもそもマイクロソフトがC++を採用しなければC++もマイナー言語だったっ
て話があったからな。まあひとつのプログラミングスタイルにオブジェクト
指向というものがある。ということで。

>クラスを理解する労力が大きく
？
データとメソッド分けて考えると労力が要るじゃない。

∀a(a∈プログラミング言語,a≠Ruby)⇒a∈糞言語
Ruby∈オブジェクト指向プログラミング言語
∴
∀a(a∈プログラミング言語,a∈非オブジェクト指向プログラミング言語)
⇒a∈糞言語

ナンタラオブジェクトのカンタラメソッドでゲットしたオブジェクトを
アンタラオブジェクトのソンタラメソッドの引数で渡してケンタラオブジェクトが
ゲットできるので。。。(以下ループ)

。。。ゲットしたポケモンを使い捨て、ピカチュウ特別扱い

どうでも良いけど、たかがOOごときにについていけない奴は
プログラミングなんてもうやめろよ。

>>1
パターンとかイディオムとか見えないと、
たしかに「書き手の勝手な都合で書き散らかしたゴミ」
にしか見えないかもな(藁

JavaBeanより、COBOLやFORTRAN60の方が、対人殺傷能力が高い。

小説家は紙とペンさえあればモノを書くことができる。
プログラマはPCとC言語さえあればプログラムできる。
エレガントさなんて要らない。

人の作ったオブジェクトって信用できない。

では、オブジェクト指向は糞Ｓヨ、糞ＰＧを淘汰する為のフィルターとして
これから益々栄えるということで。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊　糸冬 　了　＊＊＊＊＊＊＊＊＊＊＊＊＊＊

今>>17がいいこといった。

とりあえず、次のプロジェクトはdoxygenの導入を検討中・・・

オブジェクト指向は年寄りPGリストラのための大義名分・方便にすぎん
オブジェクト指向で良い思いしたやつらは、自分がいずれ同じ目にあう。

>>20
いや、哀れなオッサン達をその脳裏にしっかりと焼き付けたからには、
自分の今のスキルにしがみつかないで常に勉強を続けるから大丈夫。

というわけで我々のために「勉強しないコはこうなっちゃうのよ」という
例を見せてください先人達よ！

>>19
その前にTesting Frameworkの導入検討しろよ

>>22
レスサンクス。
それも検討している。
できればテストのログをXML化して、試験成績のドキュメント生成の自動化も。
doxygenもXML出力をサポートしているみたいだし、構造化文書化しておけば
クライアントから「Excelで〜」とか言われても、コンバージョンがきくんじゃ
ないかと・・・。

とかいいながらdoxygenの日本語環境構築に四苦八苦中だったりする厨房だが（汗

OOはそれなりに効果あるんだけど、そのプロジェクトにだれかを途中参戦させて
できてるコードを引き継がせようとするとコストが大きいきがする。
あと、デザパタなどで仕様が既知のものとして暗黙の了解になってるとこがある
んで、ドキュメントが書きにくい気がするんですよ。

doxygenのcssを自分で書いた人いれば、
分けていただけませんか？

doxygenって読みずらいですよね・・・

ドキュ資源いいよな。ドキュメント作成はこれに統一しようぜ。
フィルタ設定すれば日本語通る。

>>23
> とかいいながらdoxygenの日本語環境構築に四苦八苦中だったりする厨房だが（汗
INPUT_FILTER に nkf あたりを設定して、入力を日本語 EUC にすれば
HTML 作成は OK。

HTML Help も作ろうとすると、

1 doxygen で作成した HTML ファイルそれぞれについて、文字コードを SJIS に
　変換し、さらにファイルの meta タグを使って書いてある charset も euc-jp から
　Shift_JIS に変更。

2 Html Help Project の Language= の行を「Language=0x411 日本語」に書き換え。

という作業が必要になる。私は shell script と perl 使って自動化してるよ。

（HTML Help の方がコンパクトで検索もできるから好きだ）

>>18
その「淘汰」で糞ＰＧや糞ＳＥばかりが生き残ったらどうすんだよ？

>>27
サンクスです。

>>INPUT_FILTER に nkf あたりを設定して、入力を日本語 EUC にすれば

ってのは。SJISのソースを使う場合には。
INPUT_FILTER = "nkf32 -e"
ですよね。（Windowsです）
とりあえず、これだけやれば、HTML版はできるんですよね？
LANGUAGEはどっちでも関係ないですよね？
どーも、Japaneseにするとうまく行かない・・・・

>>28
ありえない

>>30
ありえる。
ハッタリかまして、あたかもＯＯが判ってる振りをして宣伝しまくり、
詐欺師仲間を集めれば良いだけ。
本物のＯＯ使いが現れたら罠にかけるなどして追い出す。
（マジレス）

>>31
ありがちだな。うちもそんな奴いっぱいいるな。
口は達者で押しが強くて煙に巻くのが巧くて、でも良く聞いていると
いっている事がいかにも理解不足で薄っぺらな奴。で、疑問を投げると
逆上して、こっちを政治的に排除しようとしだす奴。ムネオみたい。

知識のギャップが金儲けの手段になることって、詐欺師の道具に成り
果てるんだな。OOに限った話じゃないな。

>>29
> INPUT_FILTER = "nkf32 -e"
はい。これで OUTPUT_LANGUAGE = Japanese にして利用してます。

> どーも、Japaneseにするとうまく行かない・・・・
なんでしょうね。ウチの環境を参考までに書いときます。

　Windows 2000 SP2
　doxygen 1.2.12
　graphvis 1.7.3b
　nkf 1.7 for Win32

具体的にどう動かないのかまとめて、適当なスレに書くと、誰か反応してくれるかも。

　　　糸冬　糸吉

>>1は「戦場では」って書いているけど、戦場にならないように
管理できていないだけっていうオチ？

まあ、修羅場になってから呼ばれたんだったら、開発方法論
もへったくれもないけど、単にパラダイムがわかていない人間
が多いから、人海戦術のために人を掻き集めたときに対応で
きないことが多いってことを言っているように見えるけど。

オブジェクト指向＝御座敷剣法
ＣＯＢＯＬ＝薩摩示現流

オブジェクト指向＝単騎の騎馬武者
ＶＢ＝足軽鉄砲隊

スレタイトルを見て、
「戦車・戦闘機等の防衛関連のソフト開発ではOOは要らない、ということか」
と読んでしまった漏れは、どうすればいいのだ？

doxygen
私は
OutputLanguage=Englishにして使っているのですが、
非常に読みづらいのはそのせいでしょうか？
文字サイズの設定おかしくないですか？
OutputLanguageをEnglishにしておけば、nkfは不要です。
>>19
Qtをインストールすれば、設定がGUIでできますよ。
きっと設定間違ってるんだと思います。
cssを編集できるデザイナーいないですかね・・・

アンチOOのみなさん
言語は何をお使いですか？
C言語を使ってる人に質問です。
関数ポインタを何に使ってるんですか？
それとポリモーフィズムを比較するとどうでしょうか？

＞関数ポインタを何に使ってるんですか？
LoadLibrary,GetProcAddrでDLLをダイナミックロードする際に使用してます。

＞それとポリモーフィズムを比較するとどうでしょうか？
ポリモーフィズムとは関係ないと思います。

>ポリモーフィズムとは関係ないと思います。
勉強不足なようで

>>42
たまたま関数ポインタがプリモーフィズムの代用として使えるだけ。
比較するのはナンセンス。アホですな。

ＶＢも間接的にＯＯの恩恵受けてる
なかったら、珍花好

>>43
ｵﾏｴが文脈読めないｱﾌｫ

いかにもAPIリファレンスを読んで理解したような素振りを見せる奴は
大抵「サルでもわかるC言語」から読んでいる法則

そういう奴に限って「本代＞収入」な法則

そういう奴に限ってヒッキーな法則

そういう奴に限って知識だけで、使ってない法則

って知ってる？

>たまたま関数ポインタがプリモーフィズムの代用として使えるだけ
その逆も真なら、どういう意味かわかるっしょ（ｗ

doxygen
コメント全部英語で書いたよ（；´Д`）
CSS自作したけど、doxygenのはくHTML自体がCSSでカスタマイズされることを考えてないから、あきらめたほうがよいかと。
カスタムファイルをスペース含んだパスに置くとdoxywizardが機能しなくなるのも萎え。

近いうちに非OO言語の即効性が見直されて行くことでしょう。
OO勉強した人ご苦労様です。

おいおい・・・
非OOPLってのはOOPLのサブセットじゃないかい？

>>46
類は友を呼ぶ、というのは有名だが。
（自分の周りを見てレベルが低そうだと思ったら、職場変えよう）

>>40
メタ構造が必要になる設計を思いつかない人にはそれで良いのかも知れませんがね。

doxygenって、1.2.13では、こっちが日本語で入れたコメントは出るけど
地の部分を日本語に設定すると化けてしまって、1.2.12にしたらうまくいった
ことがあった…と思う。

「と思う」ってのは、バージョン番号がうる覚えだからなんだが。

関係ないが、doxygenという名前を聞くと、

2ch仕様ドキュメント生成ツール 「ﾄﾞｷｭｿgen」

ってのをすぐ連想してしまう俺は厨房ですか？

>>7
当方ゲーム屋ですが１０年前に編み出した手法です。
ＰＧではなくデザイナーや企画の人にスクリプト書いてもらってます。

マジ質問す。
doxygenって何なんでしょう。サイトは見つかりましたが、
どういう方面で有名なんでしょう。
みんな当たり前のように書いていて、俺はとても不安なんです。

>>1
>またオブジェクト指向が○○に優れているとかいう話も、あくまで
>ちゃんと設計され、ちゃんと実装されたクラスがあるという前提での話。
つまり、まともなら、OOがいいってことだろ。
まともな職場へ逝けよ。

>>55
コメントからドキュメントを生成するツール。
生成されるHTMLが腐ってるのが難点だが。

>>57
ありがとうございます。全然知りませんでした。勉強します。

>>56
ＩＢＭでさえプロジェクト破綻させちゃったしねえ・・・。

プログラミングコンテストなんかだと
スクリプトと関数型言語が上位を独占するみたい。
これについての意見をC++とJava派の人に聞きたい。

>>60
オブジェクト指向で設計してて嬉しいのは、なんと言っても「柔軟性」だと思う。

スパイラルな開発とか、システムがいったん動き出した後の保守などで利点
があるが、逆に初期開発コストは高い、ということじゃないのか。プログラミング
コンテストみたいに

　仕様は明快
　規模は小さめ
　一回作ったらおしまい

というプログラムに対しては、OO はあまり向かんと。

（私は使い捨てなら Perl や JScript で非 OO なスクリプト書くことが多い）

１０００行ぐらいの「システム」か？ｗ

>59
何の？

>>62
もう少し面白い煽りを頼む。

６２が言いたいのは、１０００行じゃシステムと呼べないといいたいのか？
もう少し面白い煽りを頼む

このあいだ、オブジェクト指向の威力をまざまざと見せ付けられました。
１０００行に及ぶ大規模な開発をたった１０人・１年半で終わらせる
事が出来ました。
ウチの社員は全員クラスを使えます。もう、ＯＯマンセーですね。
オブジェクト指向でもっとも強力だと感じたのはj2seのＡＰＩでした。
以前、社内で最もデキル人がＶＣ＋＋でやろうとして、どうしても
できなかったウィンドウプログラムがＯＯだと半年も掛からずに
hello worldを出せました。
ＯＯを理解しない人は時代遅れです。
アンチは逝って良し。

>>66
評価 D。再提出。

１０００行に及ぶ大規模な開発

>66
OOは何か単語を隠していらっしゃると思うのですが、
そこには、どのような単語が入るのでしょうか？

>>59
> ＩＢＭでさえプロジェクト破綻させちゃったしねえ・・・。

あれはまた別の話だよ。当時それにちょっと関わった IBM の人が「仕事取るつもりで
ハイハイ言ってたら、本当にＯＯで作れって言って来てさ、まいったよ…」って言ってた
から。ＯＯで完成させたプロジェクトで僕が知ってるのは朝○生命くらいかな。どこの
開発会社もノウハウ無いもんだから結局手続き型 C/S みたいになっちゃうんだよね。

１０００行にも及ぶ大規模な関数。

ちなみにお客さん側になる情報システム部でＯＯに興味がある人は結構いますよ。
むしろ 「ＯＯでやったら具体的にどういう設計になるのか? (多分本当に出来そうなら
使う気)」とか言う人多いです。でも開発会社側のノウハウがないもんだから、よく分
からないけどＯＯは難しいと思わせるような話にしちゃう。○日の時みたいに開発の
神様が一人いると違うだろうけど。

>>69
ＯＯ＝オブジェクト指向
ってネタにマジレスした？

>>73
うん、した。

オブジェクト指向も使えない連中がやるから戦場になるに一票。

>68 >71
>66 は明らかにネタなのに揚げ足取ってらっしゃるのですか?

＞本当にＯＯで作れって言って来てさ、まいったよ…」

なーんだそんなの、
「ウチは創業時からＯＯで組んでますよ」
で済むじゃん。

オブジェクト指向プログラミング標準 = Object-Oriented Programming Standard = OOPS

>>71
それは確かに、戦場でよく見かけるな。

>>77
ＩＢＭが受注した後、ＯＯでやらなきゃ金払わないって九側が相当ごねたらしい
(医師団の権力争いとかいろいろな関係でどうしてもＯＯでやりたかったんらしい)。
都心から SmallTalk 使いが消えたり、米国からＩＢＭ内の SmallTalk の権威 (名前
しらんけど) つれてきたりという話は有名か。

>>78
標準がOOPS言ってたら困るよな。

>>60
>プログラミングコンテストなんかだと
>スクリプトと関数型言語が上位を独占するみたい。
>これについての意見をC++とJava派の人に聞きたい。

今時、プログラミングコンテストなんてあるの？
俺はプログラミングコンテスト見たことないけど、
あるんなら参加したい。
スレ立てるか

>>60
>プログラミングコンテストなんかだと
前にここで聞いたが、
ごくフツーのプログラマは静的な型付けがないと辛い、ってことだろ。
規模が大きくなってくるとなおさら。

昔いた会社の社長は「ペーパーレスオフィス」の宣伝を間に受けて
プリンター使うと睨まれたっけ。
そりゃ滅多に使わないけど、不便とか以前の問題として、日経あたりの宣伝を
間に受ける馬鹿はホント困る。
「ペーパーレスオフィス」の記事を書いた同じ人間が「カラープリンタの成功」
なんて記事を書いてるんだろうな。

あげわすれ

>>70
もっと聞かせて!!
最近九州方面では、XML化も盛んだとか？

>プログラミングコンテストなんかだと
あるレベル以上で仕事している人はコンテストに出ている
時間なんかないんじゃないかと思ったり。
どうでしょうね。

アセンブラの1000行とCの1000行とC++の1000行は
量として等価ではない。

C だったら一日1000行書けるしね。

行数比較は、無意味。せめてFunction Pointとか、UseCase Point(藁 とか
使ってみそ。

software metrics 使ってるけど何か？

ぁ、その本あったっけ。
具体的に何を計っているの？

>>91
継承の深さ、クラスのメソッド数、クラスのインスタンス変数数、メソッドの行数など。
大体20項目くらいある。
自分でデータを溜めて指標にしないといけないのがちと難点。

>>88
行数比較は、生産性を図るのには使えないよ。

単純に行数比較すると、配列も使わずに延々と if - else 書く奴の方が生産性が高い
ことになるし、同期処理のの込み入った部分を実装する人間も、ほとんど繰り返しに近
いデータ部分を書くのも区別できないし。たとえば

static unsigned char data[] = {
　　// 以下千行
};

とかさ。

ただし、データためて開発チーム全体の統計的な指標として使うのは有用だけどね。
（あくまで「異常発見」の指標として使うべきで、それで個々人を評価してはいけない）

>>93
ループはなるべく展開していますが何か？

比較の絶対基準はやっぱ受注費でしょう。
お客「お宅、オブジェクト指向全面採用なんでしょ？だったら２割引で・・・・」
営業「・・・そうですね。開発の連中も効率上がったと言ってますし、その条件で
　　受けましょう」

そしてデスマーチが始まる。

他の会社の営業「実はウチもオブジェクト指向採用してるんです。
　　　　　　　　発注はぜひ我が社にお願いします」

そして、業界は泥沼の値引き合戦に突入するのであった。

数年後、戦争は終わった。
不毛な値引き合戦を生き残ったのはＶＢ房とＣＯＢＯＬＥＲだけであったそうな・・・。

平坦な戦場で
僕らが生き延びること

なんだ、戦場ってデスマーチのことだったのね。
もっと物騒な戦争関係のアプリケーションのことを議論するスレかと誤解したーョ。

　　　　　　　　　　　　　　　　　　　　　　　　　　　ヘ ヘ
　　　　　　　　　　　　　　　　　　　　　　　　　　ミ．"．ミ
　　　　　　　　　　　　　　　　　　　　　　　　　　ι ~ι )〜
┌────────────────────┐
│ 　 100ゲトズサーでちゅ 　 　 　 　 　 　 　 　 　 　 │
│ 　 　 　 　 　 　 　 　 　 　 　 　 　 　　 By 逸見中　│
└────────────────────┘

101!

根本的にOOって大規模なシステムでの成功例あるのか？

Windows

Office

iアプリ

TRON
BeOS

あ、失敗だった。

俺のプロジェクト。

あ、失敗だった。

MSは開発手法だけではなく､
アプリ自身もOOなところがよい｡
まあWORDは糞だが｡

>>70

>>106
BeOS は商業的には失敗だが、ソフトウェア／開発環境としては失敗じゃなかろう。

このあいだ、オブジェクト指向の威力をまざまざと見せ付けられました。
１０００行に及ぶ大規模な開発をたった１０人・１年半で終わらせる
事が出来ました。
ウチの社員は全員クラスを使えます。もう、ＯＯマンセーですね。
オブジェクト指向でもっとも強力だと感じたのはj2seのＡＰＩでした。
以前、社内で最もデキル人がＶＣ＋＋でやろうとして、どうしても
できなかったウィンドウプログラムがＯＯだと半年も掛からずに
hello worldを出せました。
ＯＯを理解しない人は時代遅れです。
アンチは逝って良し。

>>111
ﾈﾀとしてこの文章はおもしろいのか？

>>111 は2点

>>111 ねただろ　たった1000行！！
一人で1日でかくりょうだ。

OOっていったってライブラリーのコアはOOでないし
OOだと基本クラスを変更されると一から書き直し

つーかOOでプログラム書くとプログラムでなくてクラスの宣言文のほうが
おおくないか？

あとデフォルトのクラス使うんだったら
構造体でデータ保持してポインタで関数に渡すほうが拡張性と汎用性高いし
サブセットとして関数があるならばOOの必然性はなし

OOの最大のメリットをあえていうならばコンパイラが最適化するとき
不要部分のチェックがべた書きより多いことぐらい

いや、だからつまんないんだってばよ

OOにメリット無いという人は、APIを全部覚えられるくらいの記憶力が
あるのだろうと思う。また、中身をのぞくことで興奮する性質の人が
多いのだろうとも思う。

>>114
オブジェクト指向と クラスを使用する事の
区別がついてないのかな？

>>111のネタレベルの人は結構多いってこと。

俺が思うに、１種の資格（今はなまえなんだっけ？）持ってるやつのが
１０人要るけど、OOわかってるやつ一人もいない。
派遣でJAVAやってるやつは、大勢いたけど一人もいない。
ただ、うん百万って金を一プロジェクトで手にするような人間に
できない奴は一人もいなかったな。

というか、OOって他人に教えたくないよね。
こんな簡単なポイントで、こんなにいいコードが書けるって思うと。
だから、本がなくて、そのせいでOOわかってるやつも少ないのかな？
最近になって、JAVAでOOについて説明したやつが２，３でてきたけど。

まあ、デザパタを無理して使ってれば身につくとは思うけど。
別にOOのハードルって高くないよね？
俺が１０分説明したら、全部技術コピーされる気がする。
それとも、理解してしまった物は簡単に思えるだけかな。

OOできる人どう思います？

> 俺が１０分説明したら、全部技術コピーされる気がする
１０分で説明できるような知識を技術とは言いません。

>>というか、OOって他人に教えたくないよね。
これって自分が理解しているものが
他人と違うとアレだから
（それで自分の理解してると思ってたヤツが
　間違ってると、もっとアレだしねぇ…）
とゆーわけで説明したくない、とかって考えも入ってないか？

>>121
> １０分で説明できるような知識を技術とは言いません。

魔術ですね。

OOは便利だが、とにかく遅い。何かいい書き方があるのだろうか・・・

なんか、OOが"宣言が多い"とか"遅いとか"、変なの出てきてるけど、
まさか、ActiveXやCOM+をOOだと勘違いしてないよね？

AXは宣言が多いし、激遅だし、OOじゃない（コンポーネント指向と呼ぶらしい）ので宜しく。

ここですか？
２０世紀にタイムトリップ出来るスレッドってのは？

2037年までは 20世紀ですが、なにか?

>>126
そうです。８０年代以前の世界にようこそ（藁

今時OOがどうとかはやんねーんだよ。OOっていつの時代の技術だよ。
10数年も前に生まれた化石じゃねーかよ。
くだらん議論だ。以前の「アセンブラ対C言語」の議論とどこが違うんだ。

あー、違うよ。全然違うよ。

OOは現場には向かない正しくない技術です。
OO以外の別の解の登場を待つしかないでしょう。

OO すら実践的に使えない連中が何やったって同じ

>>130
> OOは現場には向かない正しくない技術です。

OOは戦場に逝かない為の技術、戦場で生き残る技術ではない。

では戦場や現場に向くやりかたってどんな感じ？

>>130
現場と言うところは、分析ってしないの？
ロジックツリーとか利用しないの？
プログラムに応用する時OOのアイディア利用してみると
分析が容易だと思うんだけど。

火がついてる現場に投入された場合
　構造化レベルのコードがあるなら
　　○とにかく出来てる部分を取り出して DLL化しVBから呼び出す 　　画面はVBで作り直す
　　○単一EXEじゃないとダメと言われたら BCBかDelphiから呼び出す

　という対策があるけど

いわゆるクラスの出来そこないがゴロゴロレベルじゃ何も無いのと同じ
　それでも何とかしなければいけない場合は・・・・

下のどこまでなら実践できる？

・OOPL => クラスライブラリの恩恵を享受するための OO
・OOD イディオム デザインパターン => 設計手法としての OO
・OOA XP RUP => 開発手法としての OO

OOPL 使っているならオブジェクト指向で設計しないと勿体無いと思うが。
個人的には C でガリガリ書くのが好きだけどね。
コードの行数だけは稼げるし（ｗ

OOPLやOODはともかくとして、OOAは一人でやろうとしても無理だろ

OOも理解できん奴は現実世界の事象についても理解できん奴

>>138
それ

138=理解できん奴

★★★ >>132 がいい事言った!! ★★★

dxygenうごかしてみたよ。
日本語が出力されたとき、チョト勘当したYO!

そもそもOO支持派って大規模なOOプロジェクトやったことあるのかいな？
OOで泥沼にはまったらタイヘンだぞー

>>143
泥沼にはまったら大変なのは、OO に限らないって。

それと、泥沼にはまったら大変だから避けよう、っつー後ろ向きな話をしても仕方ないと
思うんだが。

職業プログラマとしては、泥沼にはまったときにどうするか考えるよりデスマーチ臭の漂
うプロジェクトを嗅ぎ分けて避ける方が重要だしさ。（技術板でやることじゃないよな）

泥沼にはまったらOOの方が大変だろうよ。
俺はOOはヘタレ集団が取り入れるのは危険だと
いいたい。おれはOOのプロジェクトで成功したの
なんて見たことないぜ。おれがヘタレだっつーのは
さておいてもよ。

>>145
> おれはOOのプロジェクトで成功したのなんて見たことないぜ。
Windows

カーネル部分はまだ C で書かれたコードが大半だが、周辺は COM の塊だから
OO プロジェクトといって良いと思う。Microsoft Office や Internet Explorer も同類。

がいしゅつ

>>143
○十億円のプロジェクト Composite & Strategy & State パターンを中心にやりましたが何か？

いや、でも実際でかいプロジェクトは関数型というか手続き型設計が多い。何でかって言うと

　�@ でかい所は大抵ホストが絡んでてＯＯを知らないコボラーが設計をリードする
　�A そこそこ技術力があるところはスーパーＣ屋が設計をリードする
　�B 派遣で安価に手数を集めるとＶＢ厨上がりが群がる
　�C ポリモーフィズム (多態性)、派生継承、インスタンススコープ、ブラックボックス化など
　　　をドキュメントに書けない、お客さんに説明できない (というかあまり分かっていない)

というＯＯの是非とはあまり関係の無い理由で。ＯＯで出来ないのは使う人が実用レベルまで
使いこなせてないだけに感じる。

大抵こういう所が使うフレームワークの主軸は Command パターンになるので見分けが付く。
で、ホスト屋とクライアント屋が慣れないサーバアプリ組んだり慣れないＯＯ設計すると
花火が上がる。結果 Java とＯＯの評価が下がる。

パフォーマンスはですね、アクセスログを集計したら最大 1 秒間に 80 アプリケーション
処理を裁いてました (ファイル返すだけの HTTPd のパフォーマンスと単純比較しないで)。
ロードバランシングなしの１台構成です。

VM上でしか動かん糞言語は逝ってよし！

サーブレットらくちんだし。

>>149
はぁ、Windows が石ネイティブなコードだとでも?

21世紀のコボラー＝Javaプログラマ
むかし、Javaで粋がってた人を思い出しました。

とにかくOOで詳細設計ができるぐらいのプログラマでないと
ほんとにコーダーとなっちゃうよ。単価安いよ。

まさかMFCやらJavaやらでちょこっとプログラムしてこれからは
OOだねとか言ってる奴おらんだろうな。とにかくOOは大規模な
プロジェクトでは見通しが悪くて使えないのよ。

日本っていったい・・・

>>153
開発者がみんな揃ってOOPを使いこなせていれば、
部品化とかインクリメンタル開発とか、楽になるだろう
と思うが。

まあ、↑の前提条件を満たせるような状況になるのは、
元コボラーだのC屋だのが仕切りでない奴に世代交代
するまで無理だろうな。

>>145
> おれはOOのプロジェクトで成功したのなんて見たことないぜ。

WebObjects

つーか今の職場、OOP以前に構造化プログラミングが必要…
ソース追うのはもう鬱だ。

>>155
やってもjavaみたいにライブラリ大爆発して収集つかんぞ。
費用は天文学的になるし、個人ライブラリでやるしかない。

>ライブラリ大爆発して収集つかん

ハァ？

>>158
ライブラリってのは、単にある機能を簡単に実現できるよう
にパッケージングしたクラスの集まりだ。

別に無理してつかわんでもいいぞ。勝手に自分でゼロベースで
シコシコ作ってれば？俺はそんな暇人じゃないのでライブラリ
使うけど。

Javaのライブラリ全部把握する暇があったら俺は自分で作るＹＯ!

>>161
全部把握する必要があると思ってる奴は、それだけで
頭悪い証拠。

馬鹿だねー、全部把握しないと何が出来るか判らんじゃないか？
知らない間にライブラリで用意されてる車輪を再発明してるかもしれんのだぜ？

>>161
バカかお前。どこにどんな機能のクラスがあるかだけ把握しといて、
後は使う時にAPIドキュメント読みながらで十分だろうが。

なんかどっかで見た流れだな（ｗ

>>160と>>162は矛盾してるんだが、同一人物か？

なんで全部把握する必要があるんだ？
必要に迫られたもんを把握すればいいじゃないか。

>158
がたこ殴りに遭ってます。

不毛だ・・・

OO的な設計からOOPLの必然性はどこから出てくるの？
おれはOOは別に否定しないがこれに関しては疑問。
当然のように考えてる人が多いからちょっと萎える。

あとOOPLでプログラミングしたときはコメントに、
メソッドに「何をする処理」というコメントの他に
クラスやインターフェイスに「何をするためのクラス」と
クラスを作ったその意義を書き込んで欲しい。
必要であるということは理由があることだからそれを的確に。
下手なクラス設計だろうがその意義を書き込んでくれれば、
あとから見たものが理解するのに役立つ。
追加のコメントにはその逸脱具合を書いて欲しい。
大事なことは最初のコメントは消してはいけないということ。

ちなみにJavaのライブラリは整理されてて名前見るだけで
だいたい推測できるからいいと思う。あれをすんなり使えない
人はC++のライブラリを直ぐに使わなくてはいけない状況を
知らない、ある意味、幸せもの。

＞Javaのライブラリは整理されてて名前見るだけで

マジデスカ？

>170
おれは名前の意味以前にあの先頭大文字単語様式が気に入らん

>>164
未知のクラスが必要か必要でないか、なんで判ると思うんだ？

OOPLって横着しすぎて
バグ出やすいよな。

言語・方法論に罪はない。

罪はある。
従来の開発スタイルを否定し、人間を否定した。
そんなことやったのはＯＯだけ。

ごめんで済んだら警察は要らないって最初にいった人って誰ですか？
っていう質問をしたいんですけどどこで質問すればいいですかね？

>>176

技術は変わらないものだとでも言いたいのか？
逝け。

言語・方法論はただそこにあるだけ。
責任は採用したものにある。
現場がアホならアホに適した方法論を
採用すべし。

>>178
ＯＯは技術ではなくビジネスモデルだよ。
いいかげんに気付けよ。

＞現場がアホならアホに適した方法論を

ＯＯのことですね。

>>180
ビジネスモデルってなんですか？
説明できないなら厨房とみなしていいですか？

OOPLってバグも伝染するから嫌なんだよな。
何人かでプロジェクト組んでやる時は管理しっかりしないと。
ハイリスク，ハイリターンだよ。

>>179
「この服はアフォには見えない服です」と言われて見えるフリをしてるアフォ

>>180

ちげーよ。
おまえらが要求したものを提供したまでだよ。
「もっと楽になりたい」って言ってたじゃん（W

>>182
新聞雑誌に提灯記事を書かせ、セミナーを開き、嘘を並べ立てて
事情を知らないnewbeeを騙して要らないものを売りつけて金を取る手法。

アメリカはあたりまえのように
OOなんですけど・・・

>>187
そうでもない。
人月の神話やデマルコの本でも読んでみれ。

ＯＳやインタプリタはＯＯじゃ無理だろ。

アメリカのソース。全然ＯＯじゃない（スプライトぐらいしか）
http://www.alien-factory.co.uk/download/Gundam_v1.0_beta1_src.zip

>>188

古くねーかそれ。

>>189
何で？
「無理」 が 「全てを OOPL で書けない」 という意味ならそうかもしれないが、
オブジェクト指向で設計して作るのは可能。

だいたいインタプリタが作れないなら Smalltalk の VM の立場がない。

>>189
> ＯＳやインタプリタはＯＯじゃ無理だろ。
ネタだろ（ｗ

>>176
> 従来の開発スタイルを否定し、人間を否定した。
それは OO コンサル屋だけだろ。

実際には OO は従来の考え方の延長線上にあって、突然、無から出てきたわけではな
い。

>>170
> OO的な設計からOOPLの必然性はどこから出てくるの？
OOPL じゃないと、OO で設計した結果をそのままコードに落としにくいから。

>>189

>ＯＳやインタプリタはＯＯじゃ無理だろ。

サラシアゲ (ワラワラワラ

アプリに使うなら効果的

OOの実装ってみんなどんなことしてきたの？＞OO肯定派
それを最初に書いてくれないとあんまり説得力ないな。

とりあえず、ポリモーフィズム勉強してから来い！！
C++でvirtual使わない奴はいってよし

>>198
> OOの実装
意味不明なんだが、仕事でどんなプログラムを組んできたのか聞きたいの?

補足：ポリモーフィズム＝多相性

>>200
そう。
一般論なんて聞き飽きたから、
個々の人の経験談を聞きたい。

まずはおれから。
立場：大規模プロジェクトでのOOは難しいため否定的
　　　小規模なものなら相互の理解が可能なため有効
理由：昔CORBAを使ったシステムに関わったが、
　　　ドキュソが大量に混じっていたため、
　　　一プロセス＝一クラス、そしてその中に数十のメソッド
　　　という構成になってしまった。当初はOOらしい設計をする
　　　つもりだったらしいが、そんなのは全て安いお金で
　　　かき集めたSE、コーダーに理解されるまでもなく、
　　　無残にも消えた。おれもドキュソなVB房だったため、
　　　当然プロジェクトを潰すのに貢献。ﾆｬﾊﾊ

つまりCOBOLまんせ〜ということですな？

>>202
そうそう、現実の世の中は優れたPGの数よりも
ドキュソ（自分含）の絶対数のほうが多いものだから、
OOのなんて理想論の話でしかない。OOの成功例として
Windowsとかいってる奴がいるけど、そのWindows開発に
今までいくらかかってると思ってるんだ？　OOは手間が
かかるからコストにも響いてくるもの。

OOってクラスライブラリを使う分には便利だなあとか思うけど、
OO設計しろとか言われると、どうしていいか分からん。

>>203
それはいいたかないけどな。
なにしろ上の悲惨な体験のときはほんとにまいった。
奴ら数千行なんて関数を平気で書くんだぜ。
まったくたまんねぇよなｗ。
そんな奴らにOOなんてぜってー無理だよ。

とにかくプログラマってピンきりで底辺の奴らが
沢山いるのがこの業務系の世界。
理念も結構だが、実際に集められるメンバーのことを
まず考えるのが先だな。よく知らんけど、
EJBってのはドキュソをEJBコンポーネントに
閉じ込めておくための技術なのか？
だったら使えるなｗ。

>>204
いくらかかっているか知らないが、ペイできて利益が出れば成功には違いない。

>>204
> OOの成功例として Windowsとかいってる奴がいるけど、そのWindows開発に
> 今までいくらかかってると思ってるんだ？
それは Windows は OO で設計しなければ、もっと安上がりに実現できたはずだ、
という主張か?

他の奴も自慢の成功談、失敗談を書いてくれよ。

>>209
それは、技術板よりマ板むきのネタなんでわ?

ＯＳやインタプリタはＯＯじゃ無理だつーの！

さらしあげてる奴はどうせ「クラスで書けるじゃん」とかいう馬鹿だろうが、
何をオブジェクトにできるのか挙げて見ろ。

Gof本すら読んだ事無いのか……

はっきり言ってしまうと要求がシビアなプログラムは
OOでは書かないほうがよい。

護符本って何ですくw??

>>212
あんなもんでGofなんて名乗るのは
おこがましいにも程がある！
Mao Zedongに失礼だ

>>211
インタプリタなら

　トークン
　字句解析機
　構文解析機
　シンボルテーブル
　構文解析結果を保持しておくツリー
　ツリー中のノード
　中間コードをネイティブコードに変換する JIT

あたりを、それぞれオブジェクトにする。

>>211
サラシアゲする必要すらなかったな (藁
とりあえずSqueakのクラスライブラリでも眺めてみろよ。
OSに必要な技術要素もインタプリタもコンパイラも
ちゃーんとOOで実装されてるから。

>>217
どうせ Smalltalk のソースなんて読めない、に一票。

>>216
それは処理であってオブジェクトではない。

OOじゃないプログラムなんて信じらんない（マジで
関数あふれかえってるし読みにくいし全体を把握しにくいし。
非OO世代の人間がOOするのは大変かもしれないけどさ、
漏れ的には非OOプログラミングなんて考えただけでめまいがする。

>>216
それは処理や構造であってオブジェクトではない。

>>219
ちとまて。オブジェクトの定義をはっきりさせてくれ。

ああ、クラス＝ＯＯだと思ってるアフォが割りこんでくるし。
どうして過去レスを読まずに次から次へと現れるのか？
スライムかお前は？

>>219
処理をオブジェクトにしてはいけない理由は？
ヒント： コマンドパターン

>>219
> トークン
> シンボルテーブル
> 構文解析結果を保持しておくツリー
> ツリー中のノード

は明らかにオブジェクトだと思うけどなぁ？
でも俺だったら>>216の書いたやつはみんなオブジェクトにすると思うな。

>>223
どこにいるんだ？　俺には見えないんだが。

>>226
たぶん>>223にだけ見えるんだよ。
人はそれを幻覚と呼ぶけどね。

>>224
処理はオブジェクト指向で言うところのオブジェクトではありません。
>>225
そこらはオブジェクトでもいいけど「トークンオブジェクト」なんて
作ってもなんに使うんだ？・・・・可変にして予約・・・・ぐらいしか

関数でもＯＯＰは出来るよ。常識だろ。

>>225
JITにするかどうかは横に置いといて (藁
折も>>216に出てきてるのは全部オブジェクトにするなあ。

>>226
たぶん221のことだと思われ。

「扱う」のがオブジェクト。「扱わせる」のはオブジェクトではない
構文解析機など屁理屈じゃん。

OSのサービスパックなんてOOPの弊害だよな。

>>231
> 「扱う」のがオブジェクト。「扱わせる」のはオブジェクトではない
意味が良くわからんが、主語は何なんだ?

>>228
ハァ？ 何だか「オブジェクト指向分析・設計 〜初級編〜」とかを
斜め読みしただけの厨房みたいな事いうヤツだなぁ 。
インタプリタみたいな「処理」が中核的概念になっているドメインでは
当然「処理」もオブジェクトとしてモデリングするにきまってるだろ。

というわけで228は読みかじった本の練習問題を3回通り解いてから
出直すように (藁

>>231
漏れは普通に字句解析オブジェクトや、構文解析オブジェクト（＝ツリー中のノードを兼ねる）作って使ってるけどなぁ。

何をオブジェクトにすればいいのか分からないときは
処理を中心としてクラスを定義するよりは、データを
中心として考えた方が良さそうだよね。コンパイラの
中身なんてどうなってるのか知らないけどさ。

ちなみにこれのクラス設計はどうなの？＞詳しい人
http://os.inf.tu-dresden.de/fiasco/doxy/hierarchy.html

>>234
すげえな。クラスかなんかでラップすればなんでもオブジェクトかｗ

>>237
誰がクラス型の言語で書くといったんだ?　別にプロトタイプベースの言語で書いても
良いぞ。

（っつか 237 が考えるオブジェクトの「定義」って何よ?）

>>237
バカ丸出しだね、君。
ラップすればオブジェクトなんじゃなくて、
「その問題領域でオブジェクトとしてモデリングするほうが
簡潔かつ的確に表現できるのであれば、オブジェクトとする」
というアタリマエな話をしているだけだよ。
サラシアゲ

>>238
「かなんか」つっとるだろ！

>>239
便利なのとオブジェクト指向かどうかとは別の話。

>>240
237 の定義によると

　「オブジェクト」＝「かなんか」

ということ?　（さっぱり分からん）

あー、また始まったよｗ

多分インタープリタオブジェクト指向派とそうでない派の間に、
オブジェクト指向という概念の範囲にくい違いがあると思われ。

>>241
で、241の「オブジェクト」および「オブジェクト指向」の定義は？
不便であるという事？ (プププ

OSのスケジューラ、TCB、リスト処理は確実にOOではない。
OOっぽくできるのはシステムコールぐらいだな。
でも制約が厳しい奴はOOでは書かない。

信者の言う事は常人には理解できません。

お前等全員るびぃでもヴぃびーでもやってろ

>>244
っつーか、237=241が自分の「オブジェクト」の定義を示すまでは
厨房とそうでない者のくい違いとみなさざるを得まい。

GoFのINTERPRETERパターンってオブジェクト指向じゃないのかなぁ？

>>246
スケジューラは別に OO で設計しても良いと思うけど。

オブジェクトの定義が何かってのは人によって幅があるけど、

　問題領域を分析した結果として出てきた
　比較的独立性が強く
　内部状態を持ち
　固有の操作を備えたもの

ぐらいじゃないのかな（実際には、さらに設計段階で認識されたオブジェクトも加わる
けど）。OO と ADT の差異は、オブジェクト間の関係を、掘り下げて考察する点ね。

この定義でいけばインタプリタを実装する場合に、構文解析をひとつのオブジェクトと
して切り出すのは、自然な成り行きと思うが、どうよ?

>>216
中間コードそのものは?



　

>>251
OSのスケジューラは各処理ごとに優先度を決めて正確な時間で
確実に処理しなければいけない。
ここでスタックガンガン使うような処理は好ましくない。

OOの利点である再利用もする必要が無いのでわざわざ
不確定要素を含みパフォーマンスが落ちる手段で設計する必要が無い。

>>253
ヘ？OOだとスタックを浪費すると言いたい？
関数呼び出しとメッセージ送信とでスタックの使用頻度がどう変わるのか
説明キボーン。

>>253
> ここでスタックガンガン使うような処理は好ましくない。
> ...
> 不確定要素を含みパフォーマンスが落ちる手段で設計する必要が無い。
OO と

　スタックをがんがん使う
　不確定要素を含む
　パフォーマンスが落ちる

は、関係ないですね。

>>255
ケコーンじゃなかった、ペアプロしよう！

大体判った。
ＯＯ信者は口だけでロクなもん作れない。

>>257
当たり前。“信者”と名の付く者はふつー、そう。
今頃気付くな阿呆。

つーかさ、現場に入って他人が作った数十〜数百のクラス群を
勉強して使いたいと思う？ 俺はウンザリするね。実際に体験したけど。
結局OOマンセーの奴ってチマチマしたプログラム
を設計して満悦してる奴か、JavaやMFC使って満足してる奴だと思う。

別にスタックに限ったことではないが
関数呼び出しとグロオーバルなフラグセットではアセンブラに落としたときの
ステップ数は確実に多くなるってこった。
よって無駄なCPUパワーを使う＝パフォーマンスガ落ちるという結果になる。

>>259
こいつはCをオベンキョウする時も
「現場に入って他人が作った数十?数百の標準関数を勉強して使いたいと思う？
結局Cマンセーの奴ってチマチマしたプログラムを設計して満悦してる奴か、
libcやシステムコール使って満足してる奴だと思う。」
とか言い出すんだろうな。馬鹿丸出し。

>>259
数十〜数百のクラス郡をクラスを使わずに処理しようとしたら
数十〜数百の構造体と数百〜数千の関数群が出来上がると思われ。

>>260
> よって無駄なCPUパワーを使う＝パフォーマンスガ落ちるという結果になる。
グローバル変数は最適化してレジスタ割り当てしにくいから、最近のプロセッサだと
優位な性能差が出るかは微妙だぞ。

>>250
こんな文章、どっかで読んだ覚えない？

    文法が単純な場合。文法が複雑な場合には
    文法を表現するクラス階層が大きくなり、
    管理できなくなる。そのような場合には、
    パーサジェネレータのようなツールの方が
    適している。

>>264
パーサジェネレータって yacc だけじゃないぞ。

ANTLR とか調べてみ。

>>259
グローバル変数多用、非同期に割り込み処理がかかるプログラムを解析する
よりはマシだ。（某交換機とか）

>>265
あと、t-genとか。

>>261
ＯＯじゃなければサブルーチン群はＯＯのクラス群の1/10程度に減ると
思うよ。
クラス爆発の原因の大部分がＯＯとクラスが自ら招いた問題を解決
するマッチポンプな構造に由来しているから。

ネタだな

>>268
記述しなければならないものが同じだけあっても、
何度か同じ記述が繰り返されているときにも
Cなどではそのまま関数の中に埋め込んでしまいがちなのに比べて
OO言語ではメソッドとして切り出すことが促進されている
ってだけの話でしょ。
もちろん、この違いはクラスやオブジェクトという枠組みによって
名前空間や可視性を柔軟に指定できるという点に負うところが多い。

>>260
どうも関数呼び出しによるオーバーヘッドが解っていないようだな。
同時に複数の処理が呼び出された場合で割り込み処理が絡んでくる場合を考えてみると良い。
レジスタのSPの値が違ったり入れ替わっただけで正確な処理がされない、あるいは暴走するだろう。

>>268
1/10は絶対に無理そうだが・・・

クラスは関数と違って、ネームスペース（あるいはパッケージ）のほかに継承という構造を持っている。
もしすべてのクラスがフラットなら覚えるのは大変だが、継承＆ネームスペースによって構造化されたクラスを覚えるのは難しくない。

>>271
割り込みもまともに処理できない処理系をお使いで？

>>273
割り込みと関数呼び出しとの違い説明しな。

>>272
実際に一万行ぐらいの書いて見りゃ判るよ。

>>274
コンテキストの待避/回復とか割り込みマスクの解除/設定とか、
あとアーキテクチャによっては別のスタックに飛ぶこともありますなあ。
処理の中身も要求によっては再入可能（re-entrant)にせにゃならん場合もあるねぇ。
で、何が問題なの？

>>276
> で、何が問題なの？
何なんだろうね。OO とまったく関係ない気がするんだが。

>>275
同じだけのサービスを提供するライブラリについて、手続的なら簡単でOOなら理解できないなんて、
サッパリ理解できんわ。
これでも一応はOO言語のライブラリ構築で自分の担当分だけでも１０万行は軽く超えているんだが、
全然わからん。詳細説明きぼーん。

>>278
ＯＯ信者はデムパばかり・・・。
誰が「理解出来ない」と書いた？1/10をどう読むとそう変換されるんだ？
デムパ氏ね！

>>279
おいおい、説明できなくなると電波呼ばわりかよ（ｗ

>>279
> クラス爆発の原因の大部分がＯＯとクラスが自ら招いた問題を解決
> するマッチポンプな構造に由来しているから。
具体的に例をあげて説明してくれないか?

ＯＯ信者の脳内では他にも色々と「自分は偉い」と結論が出るべく、
入力の変換が行われています。
「担当」「１０万行」というのは全て妄想でしょう。
実際は試用期間中で社内クラッキングやセクハラがばれてクビ確定の
デムパＰＧだとプロファイリングしてみる。

>>282
妄想は良いから、技術的な方向で話を頼む。

>>282
藁多。それなら　>>275　の
> 実際に一万行ぐらいの書いて見りゃ判るよ。
は亜空間デムパ、絶好調オンエア中だわな（プププ

それにしても今日は大荒れですねー

そですねー。またーり逝きまひょ。

スマソ、すげー大雑把な主張をしていい？

まず初めに「複雑な問題は分割しよう」ってのがプログラムを作成する際のお約束でしょ。

たとえば Ａ ってシステムを作るとき、それが a と b という（比較的簡単な）部分に分割されたとする。

で、a の動作が完全で、なおかつ b の動作も完全なら Ａ は完全なシステムって話になる訳だ。

非オブジェクト指向の奴がシステムを分割する際は a と b はそれぞれ（まぁ、普通は）手続きとして、
また、オブジェクト指向の奴の場合は a と b はそれぞれオブジェクトとして実装するのだろう。

そしてその後、とりあえず a と b らしき物ができたとして、それらの動作の完全性を保証する
必要がある訳だが、そのためにはどういうテストをすればいいかというと、手続きとして分割した場合は、
・全ての入力に対して
・全ての出力が正しい
ならば、完全といえるのに対して、オブジェクトとして分割した場合は
・全ての状態の時に
・全てのメッセージに対して
・全ての振る舞いが正しい
という様にならなければいけない訳だろ？

テストをする条件が少ない分、非オブジェクト指向の方が「勝ち」っていうのは駄

>>287の続き
目？

>>287
現実問題として、

> ・全ての入力に対して
> ・全ての出力が正しい

これはテスト不可能。たとえば Win32 環境で int 引数二つをとる関数があったとすると、
その入力全てをテストするには 2^64 通りのテストが必要になるでしょ。

それと、手続き型で組もうが、現実には簡単な副作用のない関数だけには分割できな
い。たとえば Windows プログラムなら、

　RegisterClassEx() でウィンドウクラスを登録して
　CreateWindow() でウィンドウを作成して
　ShowWindow() でウィンドウを表示して
　メッセージループを回す

みたいに、相互に依存性がある分割にせざるを得ない。

>>287
> 手続きとして分割した場合は、
> ・全ての入力に対して
> ・全ての出力が正しい
> ならば、完全といえるのに対して、

ダウト。

オブジェクトとして分割した時にそのオブジェクトの状態が必要な場合には
手続きとして分割した時にも、その状態を共有する必要があるわけだから、
（非局所変数として実装されるのが典型的だね）
オブジェクトとして分割したときに
> ・全ての状態のときに
が必要な状況では、手続きとして分割したときにも
・全ての状態のときに
が必要になる。
逆に、共有されている変数へのアクセス経路が限定できる分だけ
オブジェクトとして分割したほうがユニットテストをしやすくなる。

ＯＯ許すまじ

>>291
age 荒らしの方が許せんよ、俺は。

>>276
>コンテキストの待避/回復とか割り込みマスクの解除/設定とか
OO信者は所詮その程度の解釈か。そういうのはシステムコールで実装されてんの。
まあOS上のソフト作るだけだから無理も無いか。

割り込み発生する事にプロセッサは実行中のレジスタの値をスタックへ一旦保持をして
ハンドラ内で処理をし、退避していた値をまた戻しreti命令によって呼び出しもとへ戻らなければいけない。
スタックをタスクごとに別領域に設けることもあるが、多重割り込みやマルチプロセス、マルチスレッドな環境
では同一空間で処理をする。
そしてスケジューラが行う処理にはタスクの切り替え処理も含まれる。
その切り替えタイミングはタイマ等による割り込み処理であり、その処理をOOPで
やると関数呼び出しによるオーバーヘッドが増えてしまう。
つまりまともなOSは作れないってこった。

だから理論はいいからさ〜。数字で証明しろよ。
OOと非OOの成功率は？ 本場アメリカではどうなのよ

>>293
reti って、またずいぶんプロセッサ依存の話を持ってきたな。

タスク切り替えの話と OO の関係が見えないんだが、
> その切り替えタイミングはタイマ等による割り込み処理であり、その処理をOOPで
> やると関数呼び出しによるオーバーヘッドが増えてしまう。
気のせい、気のせい。

>>293
> OO信者は所詮その程度の解釈か。そういうのはシステムコールで実装されてんの。
> まあOS上のソフト作るだけだから無理も無いか。
プププ、自己矛盾してるね（藁

> 割り込み発生する事にプロセッサは実行中のレジスタの値をスタックへ一旦保持をして
だから、それってコンテキストの待避でしょ。そんでもって、
> ハンドラ内で処理をし、退避していた値をまた戻しreti命令によって呼び出しもとへ戻らなければいけない。
これはコンテキストの回復。
> スタックをタスクごとに別領域に設けることもあるが、多重割り込みやマルチプロセス、マルチスレッドな環境
> では同一空間で処理をする。
アーキテクチャによっては別のスタックに飛ぶってことだね。

結局は>>276が言ってること繰り返しているだけ。しかも
>その処理をOOPでやると関数呼び出しによるオーバーヘッドが増えてしまう。
の根拠が不明。
何故OOPでやるとコンテキストスイッチが関数呼び出しにならなきゃいけないの？
しかも、それだけでOS全体を否定する。謎としか言いようがない。

OOPでやると関数呼び出しのオーバーヘッドが、って、メソッド探索のことか？？

>>297
折れもわけわからないのだが、
「OOで設計ないし実装すると、割り込みハンドラの内部で関数呼び出しをしなければならない。」
という御主張なのかなあ、と思ってみるテスト。

>>297
関数ポインタで直接ジャンプするか、
委譲の繰り返しで、関数コールがネストするかの違いじゃないの？

>>299
OOだからって、コンテキストスイッチのたびに委譲の繰り返しでネストする必然性はないんだけどなぁ。
メッセージ送信にしたって、あらかじめ実行されるメソッドがわかっているものについては
コンパイル時に探索を解決して単純な関数呼び出しとして扱ったり、
さらにそれをインライン展開したりする最適化も存在するわけで、
OOだからといって、必ずしもオーバーヘッドが発生する実装しかできないわけじゃあないのだが。
まあ、よくある誤解ではあるけどね。
Smalltalkなんていう、かなり純粋なOO言語でも、
特定のメッセージ送信をインライン展開するコンパイラがあるっていうか、
それが普通なんだけど。

だよね。
ＯＯＰであるがゆえに、割り込みハンドラ内部で関数呼び出しを（余分に）
行わざるを得ない場面って、無いよねぇ。

そのコンテキストが、既にラップされて抽象化された形。
システムコールしか扱わない奴には何言っての解らんとはおもうが。

ところで、retiって、なんのニーモニック？

OOP言語と非OOP言語の関係って、アセンブラとCの関係と一緒なのか…

抽象化による保守性の向上と、実行速度のトレードオフと言う話なのね。
そんなモン目的によって使い分けるだけちゃうの？

retrun from interrupt
割り込み処理の終了だな。

>>302
割り込みの話をしているときに「コンテキストの待避」といえば
（プログラムポインタを含む）レジスタ群をスタック上にダンプすることだ
というのは常識だとおもうのだが。
っていうか、それ以外の何の事だと思ったわけ？
ついでにいうと、そんぐらい自動的にやってくれるプロセッサも多いんだけどね。

や、あの、retiって、どのプロセッサのナニ表記？ってこと。

>>304
そうなんだよね。ついでに言うと、
「どうしてもパフォーマンスを出さなきゃいけない箇所を切り出して徹底的にチューニングする」
あるいは
「それでもどうしても要求されるパフォーマンスが出ない時にはその部分だけ他の言語で実装する。
しかし全体はきちんと抽象して設計/実装するし、他の言語で実装した部分も全体に無理なく適合させる。」
という選択肢もあるっていう点も、アセンブリとCの関係と同じ。

戦場でもDelphiスタイルのコンポーネント指向はとても有効だと思うよ

これだと、オブジェクトの入出力がプロパティという形で目に見える。
　その効果もその場で（設計段階で）目で確かめられる
またそれに関連するコードがイベントという形でどこにあるかすぐに探せる

だからコンポーネントは戦場でも非常に有効というか火消し役になりえる

　単なるクラスとは大違いだと思う

>>303
一般的なReturnInterruptのつもりで書いたのですけど。
Cでサポートしてる場合は
#pragma で宣言して記述する。

>>295
＞reti って、またずいぶんプロセッサ依存の話を持ってきたな。
ってのがきになったもんで、どもでした。

>>306
>ついでにいうと、そんぐらい自動的にやってくれるプロセッサも多いんだけどね。

そんなプロセッサは存在しない。
嘘つくな（ｗ
これもある種のOOの弊害だな。

ＯＯの弊害…

>>312
存在するよ。
http://www.infineon.com/jp/products/mcu-dsp/tricore/c9804_tricore.pdf
http://www.be.wakwak.com/~murasakigawa/tech/dsp/execpipe.html

>>312
> そんなプロセッサは存在しない。
常識なさすぎ。

ついでに言えばカーネルモードとユーザモードでレジスタを共用しないプロセッサも
多いぞ。この場合には、ユーザ空間からのシステムコール呼び出しではレジスタの
退避は必要ない。（割り込みはネスとする可能性があるから、話が別だが）

オブジェクト指向で開発するからって
ソフトウェアの全ての要素をオブジェクトにして
手続き的な部分を一切なくすってわけじゃないが。
ソフトウェアをオブジェクトという観点で切り刻んで構成すると
結構見通しがいいよってだけで。

必要もないのに
「int? char? はぁ？Integer オブジェクトに Character オブジェクトでなければ許しがたい」
などという教条主義者は確かに必要なし。

>>312
なんでも OO のせいにするなよ（ｗ

ちなみに、それは OO の弊害ではなくてプラズマのせいです。

>>315

>カーネルモードとユーザモードでレジスタを共用しないプロセッサも
>多いぞ。

へー、知らんかったYO！最近のプロセッサはOSの仕組みに迎合するように
なったのねー。Javaチップみたいなもんだな。

>>316
そうなんだよね。
手続き型ベースなOO言語では逐次実行なんかの手続き的な概念が必ず残るし。
ただ、Smalltalkマンセーな俺的には整数や文字もオブジェクトなほうが快適だけどね。
別にオブジェクトにしたからといって、インスタンスにメモリをアロケートしなきゃいかん
っつーわけでもないし。たまにそういう誤解もあるんだけど。

>>316
>必要もないのに
>「int? char? はぁ？Integer オブジェクトに Character オブジェクトでなければ許しがたい」
>などという教条主義者は確かに必要なし。

あー、レベルは違うけど、可読性向上などが何らメリットをもたら
さない状態なのに、既存の既に動いているプログラムをデザパタ適用
して切り刻むアフォならうちの会社にいるぞ。この忙しいのに…

リファクタリングって、すべき時、すべきコードと、そんなことする
べきでないとき、コードってのがあると思うんだけどね。

>>314
ふーん。あんがと。そいつは良い。興味がある。
でも抽象化は必要だろ？

>>320
デザパタでも OO でもそうだが、

　使い方が分からないやつは初心者
　使い方が分かったら中級者
　使いドコロを抑えて、使うべきでない時を見極められたら上級者

って事だな。

ちなみに誤解のないように言っておくと、Smalltalkマンセーな俺でも
整数や文字がオブジェクトでなければオブジェクト指向じゃないなんて
言うつもりは、これっぽっちもない。
ただ、オブジェクトになっていたほうが多くの場合により本質に着目できる、とは思う。
あくまで「多くの場合」ね。

>>320
ま、OOがどうのというよりも、コードのマネージメントの問題だよね。

>>323
単に

　OO の本質を重視するか、
　既存の環境との互換性や効率を重視するか

というトレードオフだよね。言語は道具だから、解こうとする問題にあわせて選択すれば
OK。

>>321
もはや、何を言いたいのかサッパリだな。

今日は日が悪いから、出直してきなよ。（ついでに、こっそり最近のプロセッサアーキテ
クチャと OO の動向についてカンニングしとけ）

いくらハードで直接実行できるとしても
コードの再利用性を考えると、システムコールでの抽象化は必要だと思ったまでよ。
これから転職でも考えるか。

なんか一日見ないうちに OO でカーネルでも組む話になっちゃったのか?
適材適所。

俺の発言無視されちゃったよ　もういちどコピペ

戦場でもDelphiスタイルのコンポーネント指向はとても有効だと思うよ

これだと、オブジェクトの入出力がプロパティという形で目に見える。
　その効果もその場で（設計段階で）目で確かめられる
またそれに関連するコードがイベントという形でどこにあるかすぐに探せる

だからコンポーネントは戦場でも非常に有効というか火消し役になりえる

　単なるクラスとは大違いだと思う

C++やDelphi/Kylixを使えば両の問題を解決できるので終了
つーか時代の流れについていけない奴が最も糞。

>>327
OOでカーネル組んで何か問題でも？

>>330
いや、別段問題があるというわけでは…。

＞時代の流れについていけない奴

出たな、この詐欺師の殺し文句。

>>332
まぁ勝手に死んで暮れや。

>>332
正当な意見に対し、そういう言葉でしか対抗できない。
殺し文句という言葉自体が殺し文句。

洗脳されんなちゅうの
http://www.google.com/search?hl=ja&q=%83I%83u%83W%83F%83N%83g%8Ew%8C%FC%81@%8E%9E%91%E3%82%CC%97%AC%82%EA&lr=

332,335はオッサンです。
30歳前後かな？

若けえ奴らが次々と洗脳されていくのを黙ってみてられません。
まあ「ソフト技術」なんて昔から声のでかい方が勝つんだけど。

>>335
「オブジェクト指向　時代の流れ」を検索させて何を言いたいんだろう…

>>337
おい、ビデオの予約できるようになったのか YO!

若い奴らがOOを選ぶのはOOの方がいいからだろ。
先入観に凝り固まった古いおっさんよりよっぽど正しい判断が下せる。

オッサンは
組み込み系へ隔離するのが現実的と思われ。
ハード屋とよろしくやってろっ・・フン

で、ｴｰｼﾞｪﾝﾄ指向はどうですかおまえら

さー、恒例の流れになってきました。
そうたいしたことでもない概念を、理解する事もできない
バカオッサンの負け惜しみパターン（会社パターンその38）
です！

>>343
・・・なんか延々と同じことを繰り返してる気がするな・・・

>>342
バカオッサンが己でも良く分かっていない単語をとりあえず
いってみたパターン（負け惜しみパターンの派生）。

>>344
>>327か>>328ぐらいまでは一応は技術的な話だったのにねぇ。
厨が嵐に入るのはいつものことだけど、技術的な話につながるネタを振ってくれないとこーなる典型例だな。

技術だって　ぷっ

エージェント指向ってオブジェクト指向のオブジェクトをもっと主体的に機能するようにするって考え方でオケ？
でもちょっと定義域が違う気がするけど・・・。

>>348
自律的に動くシステムなりプロセスなりがエージェントって
やつなんでしょ？OO云々とベクトルの方向が関係ないじゃん。

>>346

このスレに技術的価値があったと判断するとは・・・
アホですな。

>>249
Windowsはオブジェクト指向なOSだよねぇ。
たとえばIEなんかが、サーバーやクライアントとしてだけではなく、
主体的に何かするようになったら、それがエージェント指向？

若い奴らが聞きなれない単語を使い始めたと思ったら、
しばらくすると急に仕事の効率が下がるしさー。
直そうとすると、年寄りを排除しようとするし・・・。

アンチＯＯの隔離スレですが何か?

今日、明日は週末房祭となりそうなヨカーン。

　　　　　　　　　　　　　終わりかよ！

まず、日本が最悪であるということを
認識してから議論をはじめませんか？

>CMMの成熟度レベル
> ・日本の多くの組織のレベルはレベル1以下
> ・米国、インドでレベル5企業多数

>>356
淫妖したならソースだせや

>>356 ＣＭＭって何かの指標っすか？

>>357

疑うとは信じられん・・・
だれもが知ってることやんけ。

http://www.ertl.ics.tut.ac.jp/SWEST/report/b3.txt

インドなんかに負けたくないよ〜。

http://mentai.2ch.net/test/read.cgi/infosys/992453236/
こっちでもよんだ。

>>357
誰が疑った？

>>356
あのな、日本はCMMに頼らんでも品質の良いソフトウェアを作ってきたんだよ。
日本の銀行、通信会社、電力会社のシステムはほとんど設計からコードまで日本人
が作ってきたってこと分かっている？。

>誰が疑った？

間違えました。すみません。

>>361

コピペウザい

CMM ってはじめて聞いたんだけど、OO と何か関係があるの?

>>364

OO賛成反対の議論は、
もうやめにしましょうよということ。
で、どうやって、OOを活かすか。
開発プロセスとの関係についてなにかありません？

>>365
てめえ、無理やり賛成に持っていくんじゃねえ。

ＲＵＰってかなりＣＭＭのことを考慮して定義されている。
まあ、ラショナルは構成管理ツールとかＣＭＭに関連する各種ツールをいろいろ出しているので当然なのだが。

要求管理なんかも含めて使いこなしている人いる？
（英語版でのRationalSuite2002使っているけど結構良いと思われ）

だからさあ、そんなに良いもんなら何で人に薦めるのさ？
秘密にしといて自分だけ効率上げればいいだろーが。
何考えてんの？

>>367
いねーよ馬鹿！

rational、誰かMXしろ。
おれが品定めしてやる！

>>367

禿げ同。
RUPいいと思う。
XPは絶対に現実的じゃないよ。

要件定義で概略的な登場人物を見つける。まぁ「社員」「顧客」「身分証明書」「○○申込書」
「○○申請書」「ポストオフィス」「メールボックス」「ホスト」「申請キュー」等がありがちなクラス
かな。この時点でシス管は LDAP だとか FireWall だとか考えてるし、ＤＢは論理設計考え
てるはず。次の設計でオブジェクトの挙動とＤＢの論理設計をまとめて、そして実装。

すげー簡単に書いたけど、途中にはＤＦＤもいるしネットワーク構成もいるし、ユースケース・
ステート図・クラス図・シーケンス図・テーブルアクセス順序・トランザクション分離・ハード
ウェア構成も書かなきゃいけないし結構大変。まぁ OO で機能モデルがかなり単純化され
るので、開発物の機能変更や仕様変更時の対応が早くなったな、というのがいつもやって
たサーバサイドの設計。最近は C/S やってた VB 会社や汎用機開発専門会社がこぞっ
て流れてきたから、再び「フロー」中心設計になりつつあるような気がする。

現実モデル持ち込むと、設計概念が簡単になる代わりに実装可能性とかパフォーマンスの
観点で設計にそこそこのスキルが必要。嫌う人もいるけどね、規模がでかく=人が多くなれ
ば概念が簡単になるメリットもでかい。「今の動き」に「その機能変更」を入れた場合の影響を、
お客さんはもとよりマネージャ、運用レベルの人に説明しやすい。出来ないのははっきり
逝って設計者のスキルだけ。

>>372
なにやら、凄い狭い世界しか見えてない方のようで・・・。

>>372
システム開発に銀玉はねーよ。

>>368
激しく同意！
ここの賛成派って多分クソ高い輸入ツール売りたいだけだと思うよ。

>>373
なはは、仕事でやっている奴だからそうかもな。ぐち入ってるし。

>>375
っつーより、隠す価値のある知識なり経験がないだけでしょ、君の場合。
見せるほどのものもないんだろうけどな。(Ｗ

自社オリジナルの開発プロセスは、
どう考えてもやばいと思われるが。

>>378
しかしそれは実績とよばれている

>>379
なるほど。

>>379

旧プロジェクトの実績を
そのままOOプロジェクトに適用して
デスマーチへ。
そんな会社も多いよ。

>>381
多い YO! というより OO デスマーチのほとんどがそうなんじゃ…
手続き型言語の開発プロセスで OO やり始めると、双方の欠点モロに被ることにしかならない
からねぇ。ＤＦＤやＩＰＯを「オブジェクト指向設計です」と断言する無茶な営業もいるし。

>>382
まあ、一応DFDはOMTでも使われてたけどね。

>371
いやいや、始めるとＸＰは現実に即して進むぞ。

始めるまでの苦労はあるかもしれんが。

ということで、
「無能なPMがOOを活かさない原因である。」
という結論がでました。

以上。

>>385
あぁ、そういわれてみればでかい案件 OO で出来たのは勉強好きな
元技術屋 PM さんの理解がかなり大きかったな。というか居なかったら
無理だったろうな。

さらにまとめると、
経験をつんだ年齢の高いものが無能でもPMに
なってしまうという、日本独特の方式が生む弊害。
まぁ、これは本質的には変わらないでしょう。

終了。

オブジェクト指向システム分析設計入門
青木　淳
http://www.sra.co.jp/people/aoki/IntroductionToOOAOOD/


2.2.2 直喩と隠喩
http://www.sra.co.jp/people/aoki/IntroductionToOOAOOD/chapter2/Chapter2.htm#2-2-3

>UNIX/Cなどの世界では，未だに省略された数文字のコマンド名や変数名そして
>関数名などを多用している。マウスなどのポインティングデバイスを利用して簡単
>に長い文字列がコピーやペーストができるウィンドウ環境が整備された時代になっ
>ているというのに，昔のテレタイプの時代の悪い習慣が尾を引いている。それぞれ
>の環境には，その環境の独特の名前の付け方(習慣)があるはずである。この習
>慣を破る技術者は嫌われる。しかし，習慣は良い方向に破らなければ発展はない。
>そのために比喩を使うのである。うまい比喩なら許容されるであろう。


年寄り氏ね。

>>387
今時それは少ないだろ。
やってる会社はごく僅か・・・想像つくけど。Ｈ立とか、Ｎチーチーデータとか

>>388
またＯＯの嘘セミナーめっけ。
＞UNIX/Cなどの世界では，未だに省略された数文字のコマンド名や変数名そして
＞関数名などを多用している。

んなもんはＯＯＰＬでもやっとるわい。

「こういう嘘情報が抵抗無く脳に入っていく奴」が洗脳されるんだな。
ハックされて脳のバックドア全開で信者と化す。

例の洗脳の手法ですね。
・しかるべく結論の出るような嘘情報を並べて本人に判断させる。
・本人は自分で考えたつもりなのでチェック機構が働かない
・結論通りに操縦される。

>>184
そうそう、ここで アンチOOに対して「お前らわかってない」って言ってる
人ってアフォだよね。ちゃんと

「この服はアフォには見えない服です」

って説明してもらってるのに、それをCOBOLerやC親父の前で着て
「(･∀･)裸族ﾊｹｰﾝ!!」
って言われて怒ってるんだもん。

だからアフォには OO の素晴らしさなんてわかんないんだって。

Rubyの素晴らしさを聞いてるようだｗ

>>1
OOが総てを解決するという妄想が良くないのであって、
OOそのものは高度な技術だよ。

ただ、やはり、使いこなせる奴とそうでない奴がいて、ここら辺はどうやっても
解決されないだろ。

>>390
Smalltalk で書かれたコードを読もう。
リファクタリング本を読もう。

>>390
その後にはノーコメントですか。

>この習
>慣を破る技術者は嫌われる。しかし，習慣は良い方向に破らなければ発展はない。
>そのために比喩を使うのである。うまい比喩なら許容されるであろう。

大体、あの変数名はテレタイプ時代から来たんじゃなくて、数学の方から
来たの。
全く、出鱈目ばかり書きおって。
間違いならともかく、誇張、歪曲、捏造だらけの文章は先を読む気には
なれませんな。

>>397
言ってる事がよくわからないんだけど
>大体、あの変数名はテレタイプ時代から来たんじゃなくて、数学の方
具体例いくつか教えてくれない？

とりあえず、アンチOOはポリモーフィズム勉強してきたのか？

アンチOOのなかで、OOを極めた上で批判できるという奴はいねぇの?
単にOOで挫折してコンプレックスまみれになってるｶﾜｲｿｳな人たちばかり
なのか?

>>399
あーあ、言っちゃった。
「王様の耳はロバの耳」

>>397
大体が、数学だと変数名は省略形っつーよりアルファベット順だろうが。
整数ならi,j,k、未知変数ならx, y, z、 関数ならf, g, h、角度ならθ,φとかな。

まったくアンチOOは嘘ばっか並べてOO批判した気になってる糞ばっか。
あーあ、俺も言っちゃった。
これに懲りないで楽しませてくれよ (藁 > アンチOOの糞ども

>>396
しかも、引用されている部分はOOPLだけでなく
プログラミング全般について言ってる部分なのにね。

ネタスレあげ荒し

ls というコマンド名は数学が由来です。
pwd もです。
creat という関数名もそうです。
洗脳されたOO厨どもはさっさと死んで下さい。

>>403
ネタに解説するのも何だが、
lsはLiSt
pwdはPrint Working Directory
creatはcreateにeを付け忘れた(本人がそう認めている)
っつーわけで、数学由来ではなく、意図的な省略または単なる間違い。

> ls というコマンド名は数学が由来です。
> pwd もです。
> creat という関数名もそうです。

表現力豊かだね。

> 洗脳されたOO厨どもはさっさと死んで下さい。

電波、漏れてるよ。

OOについてなら

http://mentai.2ch.net/test/read.cgi/infosys/981101071/

>>404
> creatはcreateにeを付け忘れた
ぶっ！まじっすか！？

OOなんてエスペラント語のようなもんだよ。意味ねーよ。
エスペラント語も昔一部ではやった時期があったらしいけどね。

コンポーネントが主流になればOOである必要ないよね？

>>408
＞ OOなんてエスペラント語のようなもんだよ
全てのプログラミング言語が人工言語ですが何か？

>409
OOである必要はないが、OOの考え方を知っている必要はある。

コンポーネント⊂オブジェクト

>>407
インタビューにてKen Thompsonいわく、
「もう一度UNIXを設計しなければならなくなったら、
creatシステムコールにeを加えるだろう。」
そのものズバリじゃないけど、
http://www.computer.org/computer/thompson.htm
にもその話に言及してるよ。

>>404
「本人」って Ken Thompson ですっけ?

>>405
お褒めの言葉を頂きとても嬉しいです。

>409 名前：デフォルトの名無しさん ：02/02/04 14:21
> コンポーネントが主流になればOOである必要ないよね？
>
>411 名前：デフォルトの名無しさん ：02/02/04 14:23
>>409
>OOである必要はないが、OOの考え方を知っている必要はある。

では言語としてのOOは死んだということで。

○○○○○　終　劇　○○○○○

>>412
コンポーネントの全ての実装がOOでなければならないわけじゃないよ。
ただ、現状ではコンポーネントを実装する時には
「オブジェクト」が独立性や自己完結性や複合化という点で
一番向いているというだけ。
「オブジェクト」以上にソフトウェア部品の実装に適した概念がでてくれば
そっちを使うことになるだろうね。

>>414 くそ、食いつくと思ったのに…

>>414
Ken Thompsonでないなら誰？

トン・ケンプソン

もっとないのか、アンチＯＯ！

ほれほれ。

OO信者静かだな。。。

このようなスレって書き込み数は多くて結構はやっているけどさ
読んでいて思うんだけど、結局中身がないんだよね。
こんなやり取りが本当に面白いの？

>>422
じゃ、422が何か中身があるやつ書いてよ。

>>423
このスレの方向性自体が意味が無い。
だいたい、仕事の種類によってOOP/OODが必要かどうか
が決まるじゃん。
どういうプロジェクトにおける話なのかがはっきりとしていない
から、まともな議論にならずにすぐに「信者」という表現が
でてくるばかりである。　よって、、、

----------------------終了---------------------------------

>>424　ほら中身ないじゃん

>>422
いいんだよ、アンチの隔離スレだから

>>425 オマエモナー

>>426
なーんだ！そうだったのか！
納得！！

たとえば役所に書類を届けるとして、ただ単に
■■課の○番窓口に提出してください。というのと
▲▲課の×番窓口に書類を提出して、その後受け取った書類を
▽▽課の◆番窓口に提出して、さらにそれを◇◇課の●●に
提出して、そのご書類を◎◎に郵送するというのとどちらが楽であろうか？

つーか全部ネタだろ。
いまさらマジアンチなんていないだろ？いたらぜひその面を拝んでみたい。

アンチOOはJAVAとかC++,rubyを使わないの？

とりあえず、何度も書いてるけどポリモーフィズム勉強してからきてよ。
OOで一番難しいのはポリモーフィズム。
まあ、C言語でポインタが山なのと一緒。
君らはポインタわからんのに、C言語くそ。
関数で値変更できないよ。って言ってるようなもん。
ポリモーフィズムがわかっちゃえば、後は経験を積んで
それを活かせる設計ができるようになれば、脱アンチOOだよ。
まあ、経験を積むのには最低６ヶ月はかかると思うけど。

Javaで金を稼いでる日本人プログラマーの９割５分は
OOがわかってないらしい・・・
派遣を雇っても、９割５分の確率で
ゴミを残していく。

Javaってある意味、C++を完全に理解してないと
使いこなせないんだよね・・・

>431
いまさらそんな話題ださなくてもいいよ。
終了。

クラスが和漢ね―って、もう人間じゃねーだろ。
イヌとか猫だろ。それ。アホとかバカと罵倒することも
気が引けるだろ。猫とか犬だよ？猫にバカって言わねーだろ？
（笑）やっぱムリムリ、ごめん。僕にはできないっすよ、それ（爆笑）
撫でて抱きしめてエサをやるんならＯＫっす（大爆笑）
あ、でも小便垂れたら蹴り飛ばしますが（超爆笑）
飽きたら保健所逝きですが（超大爆笑）
ＯＯＰ和漢ね―やつはみんな保健所逝って下さいホントに。

最後の行の末尾に（超新星の大爆笑）が抜けてます（微笑）

コンポーネント指向の話題の書き込み以来、
OO支持派の負け惜しみが始まりました。

大規模プロジェクトで果たして
本当にOOが有効とは思えませんね。

コンポーネント指向がOOじゃないと思ってるDQNですか？

>>435 は?
コンポーネント指向とオブジェクト指向の違いを 500 字以内で論述せよ (3点)

コンポーネント指向がOOの話だけと思ってるDQNですか？

（● ´ ー ｀ ●）ｷｼｮｲ

>>439
0 点

嵐はいらん。アンチOOを出せ。

名誉に思えアンチOOよ。
漏れは嵐は相手にする価値もないと思っているが、
お前らを改宗させる事には意義を感じている。

はやく出てきてお前らの意見を述べぬか。

会社やめた奴のソースを任されたんだけど、
全部OOなんだよね。しかも資料が無いんだぜ。
かろうじてソース中に多少のコメントがあるから
それを頼りに、このクラスは何のクラスとか、このメンバ
は何に使うか、このメソッドは何をするのかとか、
クラス間の関係を分析したり、無茶苦茶大変っす。
OOって再利用度高いんじゃなかったのかよ〜。

>>443
非OOでも同じ事じゃん。むしろもっとひどいか・・・

>大規模プロジェクトで果たして
>本当にOOが有効とは思えませんね。
実際にそうみたいだよ。

>大規模プロジェクトで果たして
>本当にOOが有効とは思えませんね。
OOPを意識できないほど細分化してわたさないと、だめでしょう。

自分が実用レベルで使いこなせないのを OO のせいにしてる ﾄﾞｷｭｿ たくさんいるね。
そのくせ新人に「ポインタも使いこなせないで給料もらうな」とか言っちゃってるんだよね。
もうみてらんない。

つーかあれだわ、
変にクラス化されるとドキュメントが無いとさぱーりわからん、
かたや非ＯＯは最悪ドキュメント無しでもなんとかなるかも？
から始まったんでは。
変にまとめられると、分解に要する時間が半端ではないのには同意。

コンポーネント指向ってなに？

UMLのコンポーネントズと、
MSやJavaSoftの言うコンポーネントと、
粒度が違うのは分かるけど...

日本語で「コンポーネント」とは何か、
きちんと定義しようとしている本って、２−３冊しか見たことない...

>449
「コンポーネント」という言葉自体、日本語じゃないだろ
どうせならそこから始めろ

>>448
漏れは逆だ。
OOなら最悪ドキュメントなしでもどうにか出来そう。
（クラスにまとめられてることそのものが解読の助けになるし）
非OOなら詳細なドキュメントなしにはやってられない・・・。

>>451
クラスが、何がしかの抽象的な概念と結びつける事ができれば、だよね。
ある程度賢い人が作ったライブラリじゃないと、そうはならなかったりして。

>451
甘い、ね。アホなやつのソース見てみろ
＞クラスにまとめられてることそのものが
コーティングの障害になることがほとんど。

>>452-453
ｱﾌｫにOOやらせないでください・・・キチガイに刃物です。

>>453
それはＯＯとは呼ばない
ＯＯライクと呼ぶ(藁

doxygen だっけ
いいよね

>>453
コボラーや VB 厨が作るとそうなるな。

>>456
doxygenって主力HTML自分で書けるっけ？
もう、あのHTML最悪、スタイルシート適応する隙間もない。

クラスを、適当な構造体だと思ってる人たちっておおいよね。
メンバ変数の状態の整合性を保証できないクラスなんて、存在
価値ないと思われ。

>>459
メンバpublicにされて更にあちこちで参照されたあげくに
更新までされるともう・・・

おいらの出向先の、自社製フレームワーク設計責任者がそんな感じ
なのよ…まるっきり意味なし作業だと分かっていて、毎日それを
完成させる為にシコシコ働いてるんだよう…鬱だ死のう。

>>460
そういうコード書きまくって鬼の首取ったかのように勝ち誇った顔してるオヤヂこぼらー知ってるよ。
もう会社くんな。

昔ＤＢ使う為のフレームワーク作って使ってたやつがいたが、
辞めてしまった。ろくにドキュメントの無いそのフレームワークに
酷く依存しているソースのメンテは悲惨な事に。

>>450
ソフトウェア開発技術における「Component」とは何か、
きちんと定義しようとしている本って日本語でも英語でも、
5-6冊しか見たことない...

こういう話聞くとやっぱりOOって導入できないなって思う。

>>465
OOは悪くないが、バカの啓蒙作業は茨の道。

>>465
ちゃんと教育させないと非常に危険。
非ＯＯはプロジェクトにぶち込めば大抵それなりに使えるようになるが
ＯＯは血を見るだけ。

オイラはOOもやるけど、非OOの手軽さも捨てきれないなぁって思う。
数十万行くらいなら非OOでOKだと思う。

>数十万行くらいなら非OOでOKだと思う。
それ以上でもOO導入で失敗したことを考えると怖いです

ＯＯは包丁と同じ。
使い方を熟知した料理人が使えば美味しい料理が出来るが、
ネオ麦に持たせれば生首がころがる。

非OO開発において、バカは単なる役立たずでしかないが、
OO開発において、バカ=爆弾です。
爆弾がいないことを確認するまでは、導入は慎重に。

>>470
包丁どころではないぞ

一つの関数が何千行もあるようなDQNの書いたプログラムを見て
「構造化って使えねえなぁ。GOTOあった方が便利じゃん。」って
言っているようなものと思われ。

>>473
問題提起するにしても、発想が貧困だな。

>>473
真実を突いてしまったと思われ。

>>474
OO と手続き型、両方やってるなら「そうそう」って思わないか?

>>473 つまり、言いたい事は　
　そもさん　OOが使えないとは
　せっぱ　　構造化してないコードを見て　構造化してないというがごとし

という事？
　しかし、ひとつの関数が何千行もあれば、それは構造化してないと簡単にいえるけど
　OOの場合、定義がそもそも曖昧で、OOかどうかさえ判らない所に問題があるのでは？

>>443
………漏れの事じゃないよね？
だとしたら ほとんど Strategy パターンと Decorator パターン(の変形)なので
そこだけ押さえてソース見ていただければ、至極単純なコードですので。

>>477
OOPの勉強が終わっていれば、その差はあきらかだと思うが？

>>479
どこまで行けばOOPの勉強は終わるのでしょうか？
拙者はGoF23の奥義を極めただけで自惚れておりましたが、
どうやらまだまだ私などは未熟者の群の中のようです。

この「道」はたして「極」など存在するのでござろうか？

>>480
構造化だって同じようなものでしょ？
なぜにoopのみを特別視するの？？

>>480
> 拙者はGoF23の奥義を極めただけで自惚れておりましたが、
> どうやらまだまだ私などは未熟者の群の中のようです。

「GoF読んだけどサパーリわかりませんでした。」と
正直に言いましょう。

>>482 ｳｹﾀ

>>480
このみちは〜いつかきたみ〜ち♪（終わりはありません）

まだまだいろいろな概念が提案されてますね。
皆さんが注目してる最近のペーパーありますか？
（ご自分のでも結構ですが）

>>481
おれはOO派なんだけどさ、アンチの言う事で当たっている事もあるんだよね。
「クラスに収めただけで『OO できました！』ってのが多い」っていう部分なんかはそうなんだけど。

それに比べると構造化(プログラミング)は、部分毎に独立させて〜、
流れもしっかりしましょ。っていう、言語仕様が理解できると
理念もほとんど理解できるわけじゃん？

そう考えると オブジェクト指向プログラミングは先が長いよなぁ…って思う。
まぁ正直言って「差分プログラミング」みたいに、できれば無かった事にしたい概念とかのせいで、仕様自体がおかしい言語が多々あるっていうのも
原因の一つなんだけど。

ここらへんを考えていくと、「馬鹿が多いプロジェクトでは OO は怖くて使えない」は的を得ているんだよねー、残念ながら。

でも、だからこそ OO を普及させなきゃいけないんだよ？
だって、馬鹿でも OO を理解している世の中になれば、もはや
「馬鹿が多いプロジェクトでは OO は怖くて使えない」
は、成り立たなくなるんだから。
というわけで、今日も私は OO を布教をするのでした。

やっとＯＯＰＬで綺麗に書けそうになったんだけど、これしか無いかね？

クラスＡ，Ｂ，Ｃがあって、それぞれクラス変数の配列で複数持つ。
エージェントＡ−Ａ（Ａ同士の処理）、Ａ−Ｂ、Ａ−Ｃ、Ｂ−Ｂ、Ｂ−Ｃ、Ｃ−Ｃ
てな具合にクラスが増えるんです。
なんだかなー。

>>486
この話は、飯の種にしようと思ってるので詳しくいえませんが。
そのためのシステムを自分で作るか、もしくはあきらめてサブクラスを
増やすかのいずれかでしょうね。。。後者が中庸な方法と思います。

>>486
日本語を勉強してください。

だとあまりにもかわいそうなので、意味を汲み取ってみようと思う。
クラス変数といっているのはメンバーフィールドかな？
インスタンス二つが一組でなにかの処理をするんでしょうか？
だとしたら decorator パターンあたりを調べると勇気が湧いてくるかもしれません。

>>486へ確認
複雑なコラボレーションでクラスの再利用性が低下の？

日本語が使えないヒッキーバカオタクの見本市が始まりました。

やっとＯＯＰＬで綺麗に書けそうになったんだけど、こういうのしか無いかね？

クラスＡ，Ｂ，Ｃがあって、それぞれクラス変数の配列でインスタンスを複数持つ。
（クラス内で複数化は汚いのでやらない）
そうすると、エージェントＡ−Ａ（Ａ同士の処理）、
Ａ−Ｂ、Ａ−Ｃ、Ｂ−Ｂ、Ｂ−Ｃ、Ｃ−Ｃ
てな具合にクラスが増えるんです。
なんだかなーって感じです。

でどうよ？

複数の例は上にあった社員クラスの例でいいや。

>>491
やっぱりわからない。ダブルディスパッチがしたいの？

>>491
「Ａ−Ｂ」や「Ａ−Ｃ」は、それぞれコンクリートなコマンドクラスで、
そのコマンドクラスがそれぞれＡとＢ、ＡとＣを参照していると考えて
いいのですかね？

CHAIN OF RESPONSIBILITY か?

アホ設計をやっていそうなことだけは分かるな。
じゃなきゃ、こんなわけワカな説明になるはずがない。

あうあう、デザパタは嫌いじゃー

訂正：
デザパタヲタは嫌いじゃー。

>>497
オタじゃないよ。単につい最近読んだんで名前だけ使ってみただけだろ？
ピンとはずれな雰囲気がそこはかとなく。

>>491,496,497
そいつはともかく、もう一寸スマートに表現してくれ〜（ＴＴ

全然関係ないんだけど、高校生さんって COBOLスレで過激にCOBOLer批判してる高校生さん？

>>499
無理でしょう。491はOOの用語を使って説明しようとしているが、
491自身のOOへの理解が決定的に不足しているというか欠如しているため
説明が意味をなしていない。

っつーか491よ、無理にOOの用語なんか使わなくていいから、
ストーリー仕立てで何をしたいのか書いてみそ。

>>501
氏ね。（ストーリー仕立て）

>>491 みたいな奴が仕様書書くとすげぇ物が出来上がるんだろうなぁ…

攻撃的バカが約一名ムマ板を巡回している模様。

ただの荒らしだったのね。
パターン名が出てきただけで「デザパタヲタは嫌いじゃー」とか言うから
うすうすは感じてたけど。
(パターン名で意思疎通できるからデザパタって意味があるんですよ。)

>>494違うと思われ。
>>493コマンドの組み合わせによるマクロコマンド…ちょっと違うかも。
>>492多分、多分だけど、おそらく正解に一番近い。

っていうか、>>491が意味不明なので正解も糞も無いが。

つーか、実戦では、ＯＯＰＬじゃなくて、ＯＯＰが役に立つんだよ：ｐ

とりあえず、ＯＯ覚えるとデムパでヲタになるみたいだから、
なるべく近寄らないようにしようっと。

意思疎通の出来ない人がこんな所にも (￣ー￣) ﾆﾔﾘ

まぁ、なんつんだろう…
日本って、まだまだ平和だねぇ…

>>510
OOぐらいでぎゃーぎゃー騒いでナ、みっともね。

>>511
オマエガナー

　　　　>>1　　　>>1　　　>>1　　　>>1　　　>>1　　　>>1

　　>>1　　　>>1　　　>>1　　　>>1　　　>>1　　　>>1

　　　　>>1　　　>>1　　　>>1　　　>>1　　　>>1　　　>>1

　　>>1　　　>>1　　　>>1　　　>>1　　　>>1　　　>>1

　　　　　　　　　　　　　　‡



　　　 ┏━━┓　　　┏　━┓　　　┏━━┓　　　┏━━┓
　　　 ┃┏┓┃　　　┃　┓┃　　　┃┏┓┃　　　┃┏┓┃
　　　 ┗┛┗┛　　　┗　┗┛　　　┗┛┗┛　　　┗┛┗┛
　　 　　　　 　 　 　　　　†
　　　　　　　　ΞΞΞΞ凸

それ古いし面白くない

オブジェクト指向やらエージェント指向やらコンポーネント指向やら
それが必要なら覚えてやらぁ。けどな、オブジェクト指向は複雑多岐に
なるから、複雑なソフトウェア開発がさらに複雑になるのは事実だと
思うぞ。だから洩れはコンポーネント指向が本命だと思ってるがな。

言葉の混乱があるようなので．．．

コンポーネントをクラスにしたものはコンポーネント指向ではなく、
オブジェクト指向です。
M$がコンポーネント指向と名付けているものはCOM。
COMはOOとして機能が足りないため、
インターフェースもコードも膨れ上がったため、捨てられました。

COMが捨てられた理由にインターフェイスが
多くなりすぎたという理由はあるんですか？

>>517
インターフェイスが多くなりすぎたっつーか、
皆勝手にインターフェイスを定義してしまい、
かつその意味なんかもバラバラになってしまい、
コンポーネント間の互換性が確保できなかった、
って感じじゃない？

同意>>518
派生が無いために、ラップする度にインターフェースが増えるといった感じじゃないかな。
Excelのインターフェースは莫大なものになってる。

インターフェースが多いことだけでなく、煩雑で遅いということの方が
重要かもしれませんね。

なるほどね。

COMそのものは悪くないと思う >>309のいう
　入出力がプロパティで見えるという点では有用な技術だし
　アプリケーション間のインターフェースとしては非常にスマートだとも思う
　ただ、それをひとつのアプリケーション内部でのインターフェースとして使うと大げさになり
　多少、効率が悪いというだけ、
　しかし C# はそれをやろうとしているんだから、時代の流れはそんな効率がどうとかいう
　方向では動いてないんだと思う


Delphi/BCBのコンポーネントの機能はCOMに似てるけど、コンポーネントクラスをを先に単独で
コンパイルしてお、き設計時にコンポーネントの機能を動かしながら設計出来る点に妙味があり
より軽いアプローチだとは思う

COMとOOPの違いは、継承があるかないかです。
M$がCOMをOOPと宣伝出来なかった理由はそこであり、
M$が「VB-COMではオブジェクト指向の海を渡れない」という文で断言しました。

そういう意味では、C#はDelphiのコピーであり、
コード上の効率が悪いVB-COMが滅んだ、ということです。
「コンポーネントクラスをを先に単独でコンパイルしておき
設計時にコンポーネントの機能を動かしながら設計出来る点」も
C#にコピーされてます。

>>521-522
なるほど。そうですか。

Delphi,VB,C#に関するスレで一番興味深いのはこれですね↓
http://pc.2ch.net/test/read.cgi/bsoft/998629435/30-

>>522
継承というよりも、
それぞれのドメインで共通したインターフェイスを定義できなかったのが
繁雑化を生んだといえるでしょう。
つまり、extendsがなかったというより、implementsがなかった。
C#はその反省から、JavaのInterfaceをコピーしているわけで、
DelphiからというよりもJava(JavaBeans)からより多くを取り込んでいる。

特にコンポーネント供給側から見ると、例えばビジネスオブジェクトの
インターフェイス標準を画定できるかどうかが正否の別れ目になると思う。

なにげに優良スレ

最近 アンチ OO スレが、いつのまにかまともな OO 議論スレに
変わっちゃってる事が多いね。あっちでもこっちでも。

OO支持派って理論ばかり振りかざして、事実として
OOが使いにくいということは見てないね。

>>528
> 事実として
> OOが使いにくいということは見てないね。
確かに、お前がアホなのが「事実」と同程度
お前がOOは使いにくいと思っているのは「事実」だろうな

事実として使いにくい
と思ってる人が多い
と思う

ま、自転車みたいなもんだね。
乗れない人は居ないが、初めて自転車を見たという人はそんな危険で使い難いもの、
という印象を持つのでは。
一旦書いてしまえば、短いコードでも大きなコードでも、最小手順とわかる。

頑張って下さい。

>>531
あんた、ある意味、核心ついちまったな…。

OOで作られたOSってありますか？

>>533
お前はその台詞が切り札なのかと小一時間……。

あ、上の方で論破されてるじゃん。問い詰める必要もなかったって訳か。

Be ,,,

>>531
平地では最小手順かもしれないが、ここは「戦場」じゃ。
戦場で自転車など言語道断、徒歩でも流れ弾に当たるかもしれんのに．．．

# 自分のちっぽけな世界が他の世界でも通用すると勘違いしてる奴って
# 以外と多いな。
# やっぱ日本は基本的に単一文化、単一民族国家だからかな？

>>536問題はつげーん

最近独り言を”＃”で始めるキモイやつが減ったとおもったが
まだこんなところにいたか。
おまえくっせーくっせーperlerだろ！
WebPG板へ帰れ

自転車っつーより自動車だな。
使えれば激しく便利だが、DQNが使うとたちまち凶器に早代わり。
乗りこなせなくて使えねーとかほざいてるやつはまず教習所逝け。

/*
<!--
//>>538
//まあまあ許してやれよ。
-->
*/

>>536
すげー苦し紛れでやんの。
戦場と言いたいだけと (略)

Delphi型のコンポーネントが巧くゆくなら　C++クラス設計もそれにあわせたらいいと思う
と一瞬思った
　が、次の瞬間　それはやっぱり言語サポートが無いと無理なんだと判った

>>538
じゃあ、これならいいのか？
// #でのコメントはperlだけだと妄想している電波がまだいたのか
// 電波・お花畑板にお帰り

>>543
ちゅうか、君から電波でてんだけど (´д`;)

;;これなら許す

>>539
> 自転車っつーより自動車だな。
ああ、近くを散歩するには全然適さない鉄の固まりのことか？
いちいちエンジンかけたり切ったりするのがウザイんですけど。

# まぁ、遠くに行くのには便利なんだけどね。

>>546
近くを散歩したいならそれこそスクリプト系の言語使え。
おまえは登山にサンダル履いて行く気か？

>>542
published が無いと難しいかな・・

近くを散歩：スクリプト
コンビニ：えせOO（ちょろっとクラス化）
少し遠くにお買い物：OO

>>547
> 近くを散歩したいならそれこそスクリプト系の言語使え。
うん、OOが適さない状況の１つだね。

> おまえは登山にサンダル履いて行く気か？
それはOOがどんな場所でもどんな状況でも有効だと信じている
OO指向信者に言ってくれ(w

で、OO信者どもは戦場ではOOは有効だと信じてるの？
俺が思うにOOはまともな奴がつかえば、
戦場に行く確率を減らすことができる鉛玉に過ぎない。

>546
ｾｸﾞｳｪｲでも乗ってろ（ｗ

COBOL ― 電車
C++/Java ― 自動車
C ― スクーター
VB ― 自転車
Perl ― サンダル
Ruby ― 便所スリッパ

>>552
最後のオチにﾜﾗﾀ！

だからさぁ、ＯＯＰＬじゃなくてＯＯＰ（考え方）が大切なんだってばさ

考え方も大切だが、言語のサポートも重要だぞ。

二者択一じゃなくて、どちらも同じものだよ。

ＯＯＰの考え方は大切、それを表現するにはＯＯＰＬ使ってください、
ということでは。

>>548
つまりBCBが最強。

ってこと？

プロパティが無くてもコンポーネント指向はなんとか成立するけど
実行時型情報のサポートが無ければ難しいという事 >>557

戦場で自転車といえば、銀輪部隊という立派な実績が…

ソウデス。 OO トハ スナワチ愛。
OO ヲ シンジレバ。センジョウヲ ヘラスコトガ デキルノデス。

マズハ Bible... モトイ GoF ヲ オヨミナサイ。

>>560
ンな事言ってっから、デザパタ当てはめて OO 使いこなした気に
なる厨が増えるんじゃないか。Singleton と Command パターン
だけで OOP だって言う連中も居るんだぞ。

OOと言ったところで、段階的なものであって、
クラスベースOOPの次にはオブジェクトベースOOPが控えてたり。
自分で「やったーOOP出来たー」って喜べるなら良いジャン。

>>561
異端ト ニンテイシマス。ヒヤブリ デース。

>>550
やっぱり、できるだけ戦場に行かないようにするのが一番大事ではないかと思う。
最初から戦場に行くのを前提とするのはよくないよ。

>>564
自分で仕事を選り好みできる身分だったらね。

>>565
はやく力つけような。

デスマーチにいつまでもいると

　デスマーチ
　勉強する時間なし
　次の仕事も、デスマーチ

の無限ループにはまったまま、抜け出せなくなるぞ。

ドキュソがバカやって作り出した戦場にオブジェクト指向を
ねじ込むのは、やめたほうがいいとおもう。

アンタが責任者になって、仕様担当以外の前任者全員首にした
うえに、確定納期を先延ばしにすることについて、客先の説得
交渉をこなす覚悟があるなら、やってみてもいいかもしれんが。

開発プロセスどれつかってる？

>>568

勤務管理、進捗管理ぐらいしかできない我等の主任ＳＥ（４６歳）がやっていると思っているのは...
ウォーターフォールモデル

仕方なく上記ＳＥに付き従っているオイラ達は、自然と...
　　内部仕様書、設計書がないので、仕方なくペアプログラミング、
　　あちらを立てればこちらがたたずなので、仕方なくイテレーションを繰り返し、
　　スパイラル型モデルで開発しているよ。
　　進捗会議には上記ＳＥが期待するとおりに進捗を報告しているよ。

これが世代間の現実。

ここで書いてる連中は OO の本質的な欠点を分かって無さ過ぎだ！

ttp://myhome.hananet.net/~crazyghost/goto.htm

>>570
俺、三歩歩くと物事忘れる人かも……。
ここ数日、それ系の書き込み無かったし、MADOKA の方に気が向いてたから
これのことすっかり忘れてたよ。

つーか謎の中国語で気づいたんだけど、やっぱりびっくりした。

>>1
OO使ってりゃ、デスマーチにならずにすんだものを。。。

>>570
たしかにそいつに対して OO は無力だ。会社で皆に注目されちったよ。

あわわ…

ＯＯやるにはＣが最強と言う結論で

＊＊＊＊＊＊＊＊＊＊　糸冬　了　＊＊＊＊＊＊＊＊＊＊＊

めでたし、めでたし。

http://myhome.hananet.net/~crazyghost/ghost.htm

OOを導入して非OOよりもどれだけ予算や、工数、再利用性が
向上したかの資料ｷﾎﾞｰﾝ。またはその逆でもいいが。

VC++付属のC言語のgeneric.cとBCBでフォーム開くコードと印刷すれば歴然。
generic.cは1Kstep以上あるのに、BCBだと数行。

TForm1 *Form1 = new TForm1(this);
Form1->ShowModal();
delete Form1;

>>578
メソッドの中身はどうしたよ？

ShowModalメソッドは派生前のTForm（クラスライブラリ）にあるもの。

TFormを派生してTForm1とするコードが要るんだけど省略しちゃった。

だから　Delphi/BCBのコンポーネントスタイルなら戦場でも有効って　結論は出てるじゃない

しかしDelphiでもVCL使わないで generic.cをクラスで書くと
http://pc.2ch.net/test/read.cgi/tech/1009080085/87-88
　どう？　これを複数の人間が継承して実装してゆくの考えてみろよ

>>577
まったく同じ案件 OO と非 OO でやるなんてめったに無いから、
そんなに簡単に比較できるもんじゃ…

>>569

レビューは存在しますか？
UMLは使用します？

>>582
流れを読んでよ。
581はコンポーネントを使わない非OOコードが載ってるよ。

>>584
アホ。案件と書いてあるだろう

>>585
577では、「資料ｷﾎﾞｰﾝ」となっている。
コードを印刷すれば資料として一目瞭然という流れで来ている。

それに対して、582では、「同じ案件は無いから出来ない」。
誰も案件は要求してないし、出来ないという答えも欲しくない、資料が欲しいんだ。

従って、582には誰も期待していません。

>>584　非OOコードって事は　クラスを使っててもあのコードはOOじゃないって意見なんだよね？

>>587
みたところ、ほぼ非OOですね。
「TMiniWin」ていうクラスが入ってるけど、
メソッド４つ位で、順次実行べた書きと対して変わらないし。

「TMiniWin」というか、Delphiによって、コードは簡素化されてますね。
「procedure WMPaint(var Message: TWMPaint); message WM_PAINT;」
と書けるのはDelだけ。
本当は、メッセージを受けるコールバック関数で巨大なスイッチ文が現れるんだが。
VC++やBCBでは、メッセージマップとなるけど、C言語ではメッセージマップは使えないと思うんだけどどうかな？

>>588
　いちおう、WndProcやWMPaintを継承する仕掛けは用意してあるようだが
　しかしOOではないという

　どういうコードならOOなんだろう？
　それとも設計段階からOOで無ければいけないという意見？

俺非OO言語つかってたった数行で世界支配できるぜ！

int main(void)
{
sekai_shihai();
return (0);
}

コードレベルで、非OOのWin32API層、APIをラップするクラスライブラリのOOP層、
という意味で言ってます。

>いちおう、WndProcやWMPaintを継承する仕掛けは用意してあるようだが
継承する仕掛けはDelが持ってるのでそれを消すことは出来ません。

>しかしOOではないという
クラスライブラリを使わずにWin32API層でのコード、ということです。
クラスベースOOPではクラスライブラリは使えますが、
非OOPではクラスライブラリは使えませんので、
Win32APIコールか関数コールでプログラミングとなります。

>>589
　>VC++やBCBでは、メッセージマップとなるけど、C言語ではメッセージマップは使えないと思うんだけどどうかな？

C言語でもメッセージマップ構造体ツリーを木で管理して検索させればいいんじゃないの？

>>593
巨大なスイッチ文と変わってない。

メッセージマップをコンパイラが持ってるから便利なわけで。

>>1
漏れはOO、非OOを使用したプロジェクトどちらもやったことあるけど、
どちらも生産性は変わらんというのが実感。
非OOは処理手順に関してキーボード打ちながら悩むことが多いけど、
OOの場合処理手順よりもクラスの関係や、使い方で資料をあさって
キーボードから手を離して悩むことが多い。

>>593
言いたい事は、OOはクソだがOOが書ける言語は便利だという事かい？

みんな、OOを神格化しすぎてるんじゃないか？
語弊はあるだろうが、あんなもん構造化プログラミングの延長だ。

>>597
そういうアバウトなこと言われても。
構造化プログラミングの延長であることは間違い無いし、
OOP言語が無きゃ困るのも事実だし。

>>592
結局、OOP言語の機能を素直に使っただけではOOじゃないという結論？

構造化の場合は構造化言語を素直に使えば構造化が出来たのにねえ

>>597 のいう「構造化プログラミング」の指す物によっては
597の発言の評価が大きく変わると思うがどうか
順列、分岐、ループだけ使ってれば構造化だとか思ってないだろうな？

>>599
そうじゃなくて、OOP言語を使った場合は、
素直にクラスライブラリを使うことになりますが、
あえて使わないで構造化言語のように書く実験をしたのが581のコードとなる、ということ。

>>600
んなわけないじゃん。
それで構造化プログラミングだったら世にあるプログラム全部が構造化プログラミングじゃん。

>>601
ようするに、OOでは必ずクラスライブラリを作らないといけないという意味かい？
　　　それともクラスライブラリを使う事がOOだという意味？

>>599
>構造化の場合は構造化言語を素直に使えば構造化が出来たのにねえ
できないとおもうぞ。

構造化設計（モジュール設計）と
構造化プログラミングを一緒にするな。

構造化設計は一言で言ってしまうと
「モジュール強度を高くし、モジュール結合度を低くしろ」だ
これは現在のOOでも通用するテーゼ

>>605
ああ、それそれ。
スマソ。

>>603
クラスライブラリを使えるからOOは便利ってこと。
クラスライブラリが存在出来る理由も、OOだからなんだけど。

付属のクラスライブラリを使わずに、自作で同じようなものを作っても良いけど。
関数コールライブラリと違って、ラップしていくので、差分コードで振る舞いを変更できる。
そのため、関数ライブラリだとプロジェクト内部でしか利用出来なかったりするが、
汎用的なものとして存在。

>>604　素直に使う　の解釈の問題だろうとは思うよ
　 それなりによい構造化言語を素直に使えば　長くなりすぎたら素直に分割するし
　分割したらモジュールになるし、モジュール同士の結合もグローバル変数
　一杯作れば、そいつの参照がメンドクサクなるから　減らすように工夫するだろ？

理論家はいいから現役のシステム家に実際のところどうなのか
聞きたいよ。

>>609
だから、みんなコンパイラ付属のクラスライブラリを派生させて、開発してんの。

>>608
そういう工夫を思いつかないヤツがいるから困るんじゃないかな？
動けばオッケー！みたいな。
そういうことができないうちにOOだとか言ってるから、理解できないんじゃないかなぁ。

>>602
構造化プログラミングについて話してるにしても
> 世にあるプログラム全部が構造化プログラミング
じゃないぞ。たとえば goto 使ったら駄目だし。

>>611
> そういう工夫を思いつかないヤツがいるから困るんじゃないかな？
山のような Copy & Paste コードとか

if (flag == 1)
　　a++;
else if (flag == 2)
　　b++;
else if (flag == 3)
　　a += 2;

みたいなコードとか、世の中には腐るほどあるのは確かだ。（窓から投げ捨てたい）

>>610　付属のクラスライブラリが無ければどうするのよ？
だいたい、WindowsならMFC/VCLがあるが他の世界ではどう？

>>613
それは　よい構造化言語ではない為だと思われ

>>609
誰に、
何を

聞きたいのか明確に書けよ。単に現役のシステム家（屋）といったところで、範囲が
広すぎてまとまった話なんかできんだろ。

>>615
悪いのは言語ではなくてプログラマ。

馬鹿には、どんな言語を与えても無駄です。

>>612
そっか、gotoなんて忘れてた。

>>613
俺もそういうのをいっぱい見たよ。
やっぱり教育をしっかりしてないから、なのかな？

>>614
コンパイラ付属のクラスライブラリとはシステムコールの呼出しを並べたものであって、
それが無ければ同じ内容をべた書きしなきゃならなん、というだけ。
つまり、労無くして汎用的なものをクラスライブラリとして作成とか可能。

そうじゃない、業務とか、画面とかでも同じことは出来るが。

>>619
> コンパイラ付属のクラスライブラリとはシステムコールの呼出しを並べたものであって、
おいおい。

MFC, ATL/WTL あたりだと、たとえばウィンドウやメッセージループを抽象化して
扱うためのサポートが入ってる。単にべたに並べただけ、っつーのは違うだろ。

> つまり、労無くして汎用的なものをクラスライブラリとして作成とか可能。
何が「つまり」なのか意味不明だ。

>>620
クラスライブラリを使わなかった場合にも、呼出しは書かなきゃらならん。
だから、OOP言語でクラスライブラリに該当する部分と呼出し部分を書いても、
余計な労力を使わずに、クラスライブラリが構築できる。だから、「つまり」。
こちらは体験したことを書いてるんだから、分かろうとして読んでね。

>>613　ところで、そのコードの何が気に入らないの？
もしかして　switch使えって事？

>>621
二回読んだが、やっぱり分からなかった。

（もう説明しなくて良いですが）

>>623
え？判らないの？
まだ彼は　「使って極楽」　状態で　作って地獄を知らないって言ってるだけでしょ

>>624
あぁ、なるほどね。OO でプログラミングといった場合、

　1 再利用可能な汎用的なフレームワークを作る
　2 固有の問題を OO で分析してモデリングし、最終的に OOPL で実装する

というのは難易度も適用する分野も全く違うけど、それを混同してるのね。

俺は OO でプログラミングするといったら 2 の方を指すと思うよ。与えられたクラス
ライブラリを組み合わせたら出来ました、っつーのは Toy Program だけだし。

>というのは難易度も適用する分野も全く違うけど、それを混同してるのね。
その二つを混同してるんじゃない。
再利用可能なものをボトムアップで作れるし、
業務等の分析をトップダウンでモデリングも出来るのも知ってる。

>俺は OO でプログラミングするといったら 2 の方を指すと思うよ。与えられたクラス
ライブラリを派生するものOOPだろ。両方とも重要。

>>624
変数名が悪いのか　if　elseが悪いのか判らん。　はっきり述べてくれ。

>>625
> 1 再利用可能な汎用的なフレームワークを作る
うまく違いが説明できないが．．．
これって俺はコンポーネント指向で、オブジェクト指向とは
少し方向性が異なるものだと思っている。

>>626
しまった、ネタだったのか。

>>628
言葉の混乱は会話の混乱だから。
先ず、 >>516 を読んでね。

という事で 仕方ないからいちいち<<Delphi型の>>コンポーネント指向と付けましょう

そりゃイカン。
Delphi型のコンポーネント指向は、
クラスライブラリがDelphiコードで書かれてるんだから、
まんまオブジェクト指向。新しい考え作らないでよ。
VCLの中身は、デザパタであって2の面もあるし、1のような派生の面もあるし。

>>632
しかし>>309が書いてるように、普通のクラスライブラリとVCLとはあきらかに違うと思うぞ

使い勝手があきらかに違うだけ。

VCLのコンポーネントの内部処理は、内部に持ってるコンポーネントにやらせる、
っていうまさに2の世界。
だから、処理の継承はあまり使ってないよね。インターフェースの継承のための継承って感じで。
使う人はは、それを派生させるので1の世界。
で、ＯＫ？

>>634　それは利用側の立場にしかたっていないように思うぞ

それに、VCLの場合、継承によっても利用出来るけど、ポトペタで利用する場合イベントで
実装するという面は理解してる？

>>635
てゆうか、1と2と片方を取るという考え方が、片手落ちなの。
オブジェクト指向では両方出来るんであってね、
片方を優位にするのを、Myコンポーネント指向と呼んでも良いが、
オブジェクト指向以上のものではない。

とゆうより、某に滅ぼされたCOMライクなものと言ったほうが良かった。

>>634
使い勝手があきらかに違うなら、どこが違うが分析すべきでしょう
　VCLコンポーネントは使うのは非常に楽
　VCLコンポーネントを作るのは一般のクラス作成と同じ程度の労力

一般のOOで、誰かの自作クラスライブラリとかモジュールくらい使い難いものはない
　現実に、C++のクラスモジュールなんてネットで落ちてないし需要もないでしょ？
しかし、VCLコンポーネントなら専用サイトが出来るくらい人気がある

同じ用語を割り当てるには違いすぎるこの差は　どこから来るのか？　

>>636
両方利用するのは当然だが、それにしても

　与えられた汎用的なクラスライブラリを利用する

のと

　問題領域を OO でモデリングする

のは、必要な作業も適用する場面も全然違うから、区別しないと混乱の元だと
思うが。提供されるコンポーネントをブラックボックスとして使って、手続き指向
でプログラミングする、なんつーのもあるわけだし。

実際 Perl や C++, Java のように、手続き指向も OO もサポートしてますって
言語だと、そういった傾向は強いと思う。俺は Perl で組むときに OO のライブ
ラリは使うけど、自分のプログラムを OO で設計はしないなぁ。小規模で、使
い捨てのプログラムしか Perl で組まないからだけど。

>>638
> 現実に、C++のクラスモジュールなんてネットで落ちてないし需要もないでしょ？
COM コンポーネントは良く見かけるけど。

> 　VCLコンポーネントを作るのは一般のクラス作成と同じ程度の労力
一般のクラス作成っつーのが分からんなぁ。

上流工程における OO の肝は、問題を分析して、そこからオブジェクトを抽出し、
オブジェクト間の関係を考察するところだよ。それって汎用性を主眼に置いたコン
ポーネント作成とは全く異なる作業だから、比較しようがないと思うんだが。

>使い勝手があきらかに違うなら、どこが違うが分析すべきでしょう

これは後発だから、MFCより使いやすいというだけ。
JavaのSwingはVCLを参考にしたそうだし、C#のライブラリはJavaに似てるって。

>>640
だからぁ、
戦場になると　本日の戦果が重要になってくる
　短期的な成果をつみあげるスタイルでないとスケジュールが組めなくなる

戦場に放り出されて、
　さあいまから問題を分析しましょう
　さあオブジェクト間の関係を考察しましょう・・・・・でまにあうと思うか？

Delphiスタイルのコンポーネントは汎用性を考える必要はない
　兵隊はそれぞれコンポーネントを作って一つ問題を片付ける。
　ポトペタしての細かい実装は隊員の中の初心者の仕事
　と自然に、作業分担も出来てくる
　これは評価出来る

>両方利用するのは当然だが、それにしても
>　与えられた汎用的なクラスライブラリを利用する
のと
>　問題領域を OO でモデリングする
>のは、必要な作業も適用する場面も全然違うから、区別しないと混乱の元だと

区別してるよ。クラスライブラリを派生するのはボトムアップ、
モデリングやデザパタはトップダウンて書いてあるでしょ。

モデリングしたクラスも利用するときは、1のように使うんだよ。
片手落ちだと使い勝手が悪くなって、COMのように滅びるということ。

戦争は外交に失敗したＤＱＮ国がやるもの

>上流工程における OO の肝は、問題を分析して、そこからオブジェクトを抽出し、
>オブジェクト間の関係を考察するところだよ。それって汎用性を主眼に置いたコン
>ポーネント作成とは全く異なる作業だから、比較しようがないと思うんだが。

コンポーネントのライブラリ作成時にオブジェクトの関係を考察して作られてますが何か？

>>643
> クラスライブラリを派生するのはボトムアップ、
> モデリングやデザパタはトップダウンて書いてあるでしょ。
モデリングがトップダウン?　全く理解してないやん。

>Delphiスタイルのコンポーネントは汎用性を考える必要はない
>　兵隊はそれぞれコンポーネントを作って一つ問題を片付ける。
>　ポトペタしての細かい実装は隊員の中の初心者の仕事
>　と自然に、作業分担も出来てくる
>　これは評価出来る

これは違う。
Delphiのコンポーネントは自作したものがパレットに入る、としてて、
ネットに派生したものが無数にあるから便利。
パレットに入れずに、派生したものを動的に貼りつけても良い。

>>646
それはあなたが理解してないの。
オブジェクトの相関関係を定義するときは、
あるオブジェクトの中から見るので無く、全てを見渡す上の視点。
だからトップダウン。

>>647　おまえ・・・・業務でネットでひらったコンポ使ってるのか？・・・・・

>>648
俺用語の「トップダウン」だったのか。だったら、そう書いてくれよ。

まあ Delphi を VB コンポを VC++でCOMに置き換えてもいい話だな

えーーー。
Delphi使っててフリーコンポーネント使ったこと無い人居るの？

>>651
それだと、オブジェクト指向にならない。コンポーネント指向。 >>516
だからVBとCOMは滅んだの。

>>652
自分で使った事はあるが、　いくらデスマーチ中でも　そんなひらったコンポは使わんぞ
そりゃまあAPIヘッダ程度は確認して利用したりはするが

┌─────────────┐
｜　　もえちゃんを救うため　　　　│
｜　皆様に協力をお願いします。　　　　　　　　＼　　ｵﾅｶﾞｲｼﾏｰｽ!!　　／
｜
　　 ∧＿∧　　／￣￣￣￣￣￣￣￣￣￣￣￣＼　 ∧＿∧　 ∧＿∧　∧＿∧
　　（　´∀｀）＜　心臓移植手術のための善意の｜ （´∀｀　） （´∀｀　）（´∀｀　）
　　（つ＼　丶　＼　募金をお願いしまーす。 　 　｜（　　　　） （　　　　）（　　　　）
　　｜ ｜［三］　　＼＿＿＿＿＿＿＿＿＿＿＿／ 　｜ ｜　|　｜ ｜　|. ｜ ｜　|
　　（_＿）＿）　　　　　　　　　　　　　　　　　　　　　　　（＿（＿_）（＿（＿_）（＿（＿_）

http://www2.gateway.ne.jp/~moe-moe/

http://cgi.members.interq.or.jp/hokkaido/asato/upload/jam3ddr/OB000988.jpg

オブジェクト指向を

　小さなコンポーネントを拾い集めてきて、組み合わせること

と思ってるやつが数人いるのか。確かに犬小屋程度なら板と釘とペンキを拾って
きて組み合わせればできるけど、ビルを建てようと思ったらパーツ云々より先に、

　まずは、どんなビルが必要なのか（分析）
　どうすれば、そのビルを建てられるのか（設計）

をした上で、そのための部品を調達するなりオーダーメイドで用意する必要があ
る。いくら納期が厳しく火を噴いてるプロジェクトだからといって、基礎工事や設計
書を作らずに工事を強行したら、途中で

　ある部分と別の部分がスムーズにつながらない
　基礎部分の強度不足判明、継ぎ足し

なんてことを繰り返して、結局は余計な時間がかかるだけだぞ。挙句にポシャっ
たプロジェクトもいくつか見たけど、末期状態だと

　全体像を誰も把握してない
　朝令暮改
　朝の仕様に従って組んだら、夕方には仕様変えやがる
　テストしようにも、別の部分が　仕様どおりに動いてない

なんてことになって、チームのやる気は低下、人間関係はボロボロで悲惨だった
よ。（俺は、もう二度とかかわりたくない）

スレから脱線する話ではありますが、

戦場であっても守るべき規則や仁義はあります
APIのヘッダファイルなら著作権は基本的にありませんが
日本では著作権は放棄出来ない権利です。
ですから、いくらフリーだと言われているライブラリでも、
企業が使う以上著作権者へのコンタクトは必要でしょう

>>657　だから戦場ではオブジェクト指向は使えないんでしょ？

>>659
657 の話は、オブジェクト指向とは一言も書いてないけど。

>>647
そうか？
汎用的っていう言葉もあいまいだが、
Delphiのコンポは汎用的に書かなくても問題ないと思う。
単純にデータや処理単位でカプセル化するだけでも
>>642みたいにOOの利点を有効に利用出来ると思うんだが｡

>>659
いや、オブジェクト指向かどうかに関わらず場当たり的な対処は結局は首をしめると
言いたかった。Delphi のコンポーネントで OK なんつーのも、目先のことしか見てな
いだろ、と。

ちなみに、最後にかかわったデスマーチは言語は C で、通信関係の何かでした。

>>659
OO以前に分析、設計が大切ということでよろしいか？

そもそも戦場といっても、ちゃんとオブジェクト指向の設計、開発を行っているプロジェクトならば
世界大戦にはならないんじゃないかと思ってみたり。

火を噴いたプロジェクトで、
　データ構造だけはしっかり決めて、
　つぎは人員の配置
　コンポーネント作成部隊と、フォーム単位部隊に分割


　コンポーネント部隊には最初に中身無くてもプロパティとイベントだけは定義させて
　フォーム作成部隊を平行して作業させる。

というのでなんとか鎮火した事はあったな
　まあ、コードはいわゆるオブジェクト指向ライクなものではないし
　メインテナンス性のかけらも無いものになって、後で一人でメンテナンスするう奴は苦労
　するんだろうが、
　納期は守られた

>>664
だな。

実際WinのGUIの設計とかになるとDelphiなんかのほうがスマートに設計＆コーディング出来るし、
単純処理？にOO使ったり、設計途中でむりやりOOをはめ込んだりすると
泥沼にはまる危険性がある上に利点が少ない。

>>664　その”ちゃんと”ってのが問題なのよ。
チーフがしっかり設計出来るやつじゃないとか、俺様流の奴が多いとか

オブジェクト指向の設計段階で貴重な時間食いつぶして火を噴いたりさ

ユーザから要求された出力フォーム見りゃ、オブジェクト指向とか言わなくても
必要なデータベースや入力項目は普通わかるだろ？
どんどん作業した方がトータル早いなんて事も多いよ

>>667
それって、あんたが設計してることにならん？

>>667
そうやったほうが速いのはわかるが、そうやって作ると
つっこみどころ満載の実装になるんでわ？

で、そーやって作っておいても、OOの方が改造、修正が楽ちんだし。

ただいままでのまとめ
　１、OOP言語は便利だから戦場でも使える
　２、コンポーネントは戦場でも使える
　３、OO設計は戦場では使えない

>>670
中々良いまとめだね。
OO設計の失敗例ってのは実際存在する。

クラスライブラリ自体も設計されて作られたものだけど、
VCLみたいにラップがうまくいってLinux対応まで出来るものもあれば、
MFCみたいにアンチOOPを作るくらいに失敗してて
さらにMFCのMAC版はクラス階層が異なるんだって。これじゃCOMじゃん。
M$クラスライブラリの意味知ってんのか？

>>671
いくら贔屓目に見ても、Kylix は実用レベルじゃないだろ。

それから Borland マンセー、MS バカとたたく場所じゃないんだから、MFC の
ことは忘れとけ。

OO 設計は初期段階からプロジェクトに織り込んでゆくもの。
火がついたからといって、今まで非 OO 設計で組み上げて
きた開発物を簡単に OO 設計に置き換えられるわけがない。

それから、OO は簡単に開発できる魔法の設計と思い込んでいる
人達が何人かいるけど (俺の周りに)、別段実装量が減るわけで
はない (むしろ手数は増える)。開発物の内部構成が明確になる
だとか、開発クラスの個数やパフォーマンスネックになりそうな
部分といった、プロジェクトのスコープに利点があるもの。実装量
減らしたければ柔軟性を犠牲にしてウィザード系のツール類を使い
まくってくれ。

>別段実装量が減るわけではない (むしろ手数は増える)。

これは有り得ない。
まさか、ここで言ってるOOはCOMじゃないよね？

>>674
いや、モデルに従うために手続き型に逃げないで
冗長なコードを書くことはよくあるよ。

全体の実装量が減っても、局所的には増えてるような場面は、いっぱいあるね。

>>676
同意。

継承ベースで組まずに委譲にする場合とか、転送用のコードを書き並べることに
なるし。

>>675-376
自分とこでは無いな。

>>677
継承しちゃダメなの？

>>678
> 継承しちゃダメなの？
…おいおい

実装継承は必要ならしても良いけど、

1. 単一継承
2. Mixin

ぐらいに限定しておかないと、継承元と派生クラスががっちり結びついてしまうから
後で変更が厳しくなるぞ。

>>679
> ぐらいに限定しておかないと、継承元と派生クラスががっちり結びついてしまうから
> 後で変更が厳しくなるぞ。

だね。
これがOOの欠点といえば欠点か。
で、独立(汎用)性を維持させようとしてコーディングすると冗長になることがよくある。

実際には使い捨てでぱぱっと実装した方が速い場合もあるがな。

とある統計：1994

1.着手したプロジェクトの約３０％が完成にキャンセルされた
2.完成したソフトウェアの７０％以上が予定していた全機能が実装出来なかった
3.計画予算と実費用の比率は平均189％である。
4.計画開発期間と実際の比率は平均で222%である。

俺が大学一年の頃からすでに…。

オブジェクト指向を選択したプロジェクトが実際に失敗するのは
　自由度が大きすぎるからという面もあると思う
　自由度が大きすぎるからその組み合わせ爆発は尋常でなくなり、ついには破綻するのであろう

　比べて、関数であれば、入力、出力数は限られている
　　　（まあ理論的には引数１００個とか出来ない訳じゃないが）
また、コンポーネントは、プロパティエディタなどが、その自由度の適度なブレーキとなって
いるのではないだろうか？


たとえば、>>581が出した短いサンプルコードを見た >>588　の
＞メソッド４つ位で、順次実行べた書きと対して変わらないし。

という意見から見ても、オブジェクト指向のクラスは、多くのメソッド（入出力）を持つ
複雑なものとして設計されている事が読み取れる


プログラミングは、あれも出来る・これも出来るという状態から制限を加えてゆく行為なのだと思う
オブジェクト指向を取り入れるとしても、OO的原則論より　簡単、簡潔をまず優先するべきかと

>>683
> 比べて、関数であれば、入力、出力数は限られている
完全に相互に依存関係がない関数に分割できるならともかく、現実には何らかの
状態を共有することになるわけで、既に議論が破綻してる。

>>600
あと多分岐選択を忘れてるよ
http://hpcgi1.nifty.com/mizukix/text/textdisplay.pl?file=6-5.txt
【構造化プログラミング】
　ダイクストラ（E．W．Dijkstra）らによって提唱された．
　プログラムの基本制御構造の５つのものだけを用いてプログラミング
　せよという指針を持つ。

【基本制御構造】
　連接，選択，多分岐選択，前判定繰返し，後判定繰返し

【構造化定理】
　入り口ひとつ、出口ひとつのプログラムは３つの制御構造の組み合わせで
　すべて表現できるという定理。３つの制御構造とは、以下のものである。



>>684 とりあえず >>683は関数としか言っていないんだから　
　関数型プログラミングパラダイムの事かもしれんと

結局オブジェクト指向のやろうとしてる事は

「入り口ひとつ、出口ひとつのプログラム」　じゃイヤンという事じゃないのかな

その面では構造化プログラミングと対立する概念の部分もあるかもね

>>686
そもそも構造化プログラミングとオブジェクト指向じゃ、語ってる対象が違う。

　構造化プログラミングは、関数／手続きに分解が終わった段階で、その中を
　どう記述するかという話

　オブジェクト指向は、問題をどのようにモデリングするかという話

別に OO で分析／設計して、個々のメソッドは構造化プログラミングにしたがって
書くことは不可能じゃないよ。厳密にやると例外も投げられなくなるからアレだが。

>>683
自由度の大きさとOOとは関係ないと思われ。
むしろ、OOは制限の多いパラダイムだと思われ。

オブジェクト指向分析・設計が戦場でダメな理由

１）開発サイクルにおいて分析により多くの労力を費やす事＝実コーデング時間の不足
２）スパイラルモデルやラウンドトリップモデル　＝　最初の設計が疎かになり易い　また工程管理が難しい
３）問題領域の分析から入るため、実装仕様の肥大を招き易い

>>689
1 と 2 は矛盾してると思われ。

3 はありがちな話だが、それを防ぐためのスパイラルモデルでもある。汎用性は
そこそこに、適宜リファクタリングせよ、っつーのも小／中規模だとわりと実用的。

長年ＳＥをやってきた経験上から言わせてもらうと、
設計なんぞやらせると、設計を盾に変更に難色を示すプログラマー例が多いので
私は設計なぞさせません。

>>691
変更の可能性のあるポイントを事前に示唆しないお前が悪いんじゃん。

つまんないネタだ・・・

そんなやつでも長年ＳＥが出来るって、なんていうんだ…　あ、あれかな？

「日本はまだまだ平和だ」

最近見たな「前者のSE」「後者のSE」。なかなか核心を突いた文章だった．
あれのダメな方だろ。

>>691

長年SEやってて実戦OOはいつ習得したんだ？
そういうSEでまともなOO設計できる奴なんか見たこと無いぞ。

理屈を言うな！
仕事は根性だ！

>>697

たぶんそれは691の口癖だろうな。
設計のマズさを突っ込まれるとつい出るという。

SE って何が仕事なんだろう。

>>697
文系だよね。
理系だったら理屈より他のものを優先させたりしないでね。

>>700

黙れリア厨。
社会に出れば理屈や道理なんか優先順位の下から数えた方が早いんだよ。

>>701
そうでもないぞ。

もちろん組織の間の力関係とかで道理が通らないこともあるが、こと開発に
関しては

　無理を通すとデスマーチ

になるだけだから。分かってるところは、あまり無理をしない。

>>702

じゃあ聞くが、デスマーチが一向に減らないのは何でだ？
691みたいな糞SEがのさばってる証拠だろ。

>>703
そりゃ、あなたの立ってる位置が悪すぎ。

デスマーチに関わらなくても食っていける程度には、まっとうな仕事はあるぞ。

>>704

いまどき食えるだけで満足なの？
とか言ってみるテスト。

>>705
むしろ、デスマーチにはまってるときこそ「食えるだけ」っつー気がするな。
起きて、食って、コード書いて、仕様変更に泣いて、飯を食って、コード書いて、
テストして、家に帰ると午前様。

本を読む時間はおろか、２ちゃんねるで遊んでる暇もありゃしない。

>>706
>起きて、食って、

の後に「会社行って」が無いのがやけにリアルだな。
体験記か？

世の中には、デスマーチの指揮をとるのが、楽しくてしかたがない、エラい方もいらっしゃる。
嬉しそうにさしいれもってくるなっつーの…

>>690
矛盾していない
　分析に時間をかけるが最初の設計に時間をかけないのはよくある話し
　分析と称してはグダグダ会議を繰り返し時間を潰し
　スパイラルだといいながらまだ動きもしていない状態で仕様変更

一夜明けたらトンデモな結論でてるな。

>たとえば、>>581が出した短いサンプルコードを見た >>588　の
>＞メソッド４つ位で、順次実行べた書きと対して変わらないし。

短いサンプルコードって１Kstep以上あるじゃん。
こんなのクラスライブラリで3行だよ。

>>709
それって、OO分析・設計が駄目な理由というよりは、
駄目な分析・設計したらこーなった、
って話にしか聞こえないんだけど。

例えば構造化分析・設計でも、
ヘッポコな分析・設計すれば
同じような戦場が簡単に発生するわな。

結局は糞Sﾖが存在する限りOOなんぞ危なくて使えんわという結論？

>結局は糞Sﾖが存在する限りOOなんぞ危なくて使えんわという結論？

だめなやつはなにをやってもだめ。
従来の非OOの設計のほうが危険度が少ないつーだけ。


で、よろしいか？

>>713
よろしいが、だめなやつを減らす努力をしないと何も変わらん。

OOPは誰でも使いこなせるクラスライブラリは出来た。
OOPは使わないと損。

OO分析（OOAだよね）が簡単という話はあまり聞かない気がする。
（でもOO分析とスパイラルアプローチは関係無いよね）

OOだとコーディングが楽になるが、設計の負荷が増える｡

つーことは、優秀なSEが低脳なPG使えばいいってことか？

コーディングが楽になったのは事実だけど、
楽なまま終わったんじゃなくて、機能の積み上げが激しくなったね。
もうOOP駆使してもう古い言語やクラスライブラリの無い世界には戻れないって感じ。
その世界にSﾖは入れないよ。

Web系はちょっと違うかもしれないけど。

>>713
で非OO設計とは何かというと　画面と印刷物の希望だけ渡されて　あとは口頭で聞いて仕上げると

プログラマにもオブジェクト指向設計の知識が要求されるようになってきたんじゃないか？
10年前のようなコーダーはもう生き残れないね。
SEも口先だけではどうにもならなくなってきたんじゃないか。

>>719
オブジェクトの関連は考えてないとトンデモクラスがイパーイできるからそうだね。

オープンソースとの共存を考えると、膨大なコードを読む能力がこれから必要になるね。
膨大なコードとOOPのカプセル化はピッタリなんだけど、オープンソースはC言語かな。

WEB系は違うと聞いてふと思った。
WEB系ってASPとかJSPも含めて
ファイルのサイズはそれなりの大きさになるけど
それを大規模あるいは中規模と勘違いして
OOは大規模には向かないとか言ってたりして・・・
昨今はWEB系が流行りだけどさ。
JSPを例にあげたOO的設計では、
仕様が変わらないTOMCAT以下は、インターフェースでラップして
.jspは使い捨て、という認識で・・・
ejbもフレームワークができてるんで
ejb使ったり、作ったりするのが
OOかどうかは怪しいよ。

そんな勘違い君がいない事を願う。

>>720
甘いと思う
OOPでオープンソースを作ったとすると問題はクラスライブラリの互換性
特にGUIにクラスライブラリを使われてしまうと 合成が出来なくなる。

そういや、別に設計されたクラスライブラリ同士をどう合成するかってのは難しい問題かも

別々のクラスライブラリ同志を合成は出来ないでしょう。

あるクラスライブラリを派生したもの同志なら出来るけど。

>>722
具体例をあげてくれよ
どういうケースで問題があるのか。

クラスライブラリ同士を合成するってどういう意味だ？

フレームークを合成するだったらネタだとしか思えないけど。

WEB系はコーダーって言うんだよ。
プログラマーとは言わない。

>WEB系はコーダーって言うんだよ。 プログラマーとは言わない。

なんかそうみたいだね。WEB系って最先端のイメージだったのに。
これからのWEB系はどうなるんだろう。

>>726
そうなん？
おれんとこじゃコーダーって聞いたことないぞ。

>クラスライブラリ同士を合成するってどういう意味だ？

だから、BCBのTComboBox->ItemsをSTLのVectorに移したり出来ないよね。
BCB同志だったら、TComboBox->ItemsをTStringGrid->Cols[0]に代入とか出来るじゃない。

ドカタが自分でそうよばないのと同じだよ

Web 系は設計事務所と土建屋が明確に分かれているドカタ仕事です。

しかし今面白いのはWeb系

で、Web系ってなんなのよ？

>>728
なーんだ、自分のコーディングの技術がないだけじゃん（ｗ
調てこい、ボケ！！

>>728
大いにウケタ（ｗ

>>732
いまだと .net なのか?

一昔前は IIS + VBScript, JSP とか Apache + Perl が流行ってたけど、あれは面
白いかっつーとそうでもない気がする。全体像を設計するのは楽しいけど、コーディ
ングは単調だし。

>>733
超お願い。技術教えて下さい。
今までVCLばっかりやっててSTLに挑戦しているところだ。

>>735
まずはプログラミング言語 C++ と Effective STL 読みましょう。

>>735
おまえ７２８か？
STLとか言って言い訳してんじゃねーよ。
まずOOわかれ。
それからSTLだよ。
何でSTLが必要（便利）なのかわかってから使え。

>>737
STL は OO じゃないと思うけど。あれは Generic Programming でしょ。

（仮想関数を一切使わんし）

テンプレートベースのＯＯ？

>737
どうも勘違いしてるみたいだけどSTLは使えるよ。
728に書いたのは、VCL同志では、TStringsから派生した文字列セットは、
まとめて移動できるけど、STLには移動できずにループでまわしてセットしなきゃ
ならんのじゃないの？ってこと。

>>740
STLでできることは全てOOでできる。
でもSTLで書くと、うまくかけるケースがある。
それが何かわからないまま、STLを乱用するのはよくない。
Javaが最初にSTLを実装しなかったのはそのためだと「思う」。
Javaでgenericsが使えるようになるのはいつだっけか？
楽しみだ。

つまり、あえてSTLする必要は無いってこと？

今はJavaはSTL使えるのでしょうか？

>>742　自分で好きなプリプロセッサ作ればいいんじゃない？

>>742
まだ。Generics のサポートは Java 1.4 で入る予定だったが、間に合わず次に
持ち越しになってる。

>>741,742,743,744
わざわざ作る必要ないだろ！gccが使える環境なら

　%cpp -P foo.java > temp ; mv temp foo.java

でCのプリプロセッサが使えるだろ。。。誰か、本番で
使ってみるチャレンジャーおらんかな？

>>745 Cのプリプロセッサじゃ STLモドキは無理だろ

EPPを使おう
http://staff.aist.go.jp/y-ichisugi/epp/j-index.html

言語コンパイラと一緒にしてないのはSUNのミスだね。
プリプロセッサの数だけJavaの方言が出来てしまう。

アホか
一緒に配布したら誰でも使うようになるだろうが。

そうそう．バカがプリプロセッサを喜んで使うと周りが迷惑する．
確かCプログラミングの「教科書」でとんでもないマクロを使いまくって
いたのがあったと記憶している．
Java処理系と一緒に配布しないのは正解．

>>749
はあ？

だからJavaはヘッダーファイルというものを否定してるんでは？
プリプロセッサが入っちゃうとヘッダーファイルが出来ちゃう。

アンチプリプロセッサは放置しといて、
gccがなくてもVCがインストールされてればCL.EXEで行けることが判明。

#includeマンセー

#ifdefマンセー

だからぁ、Cのプリプロセッサじゃ STLは作れないって

templateなんていう中途半端なものよりちゃんとしたパラメタ多相型を言語
に導入するほうがずっといい．だから次期Javaまで待て．待てなければGJや
Pizzaを使うと幸せになれる．

次のバージョンのC#にはテンプレートが入るよヽ（´∀`）ノ

Genericsだったらもうダウンロードできるだろ？

SunのGenericsは弱すぎ
関数型言語にどっぷりつかってきたのでPizzaがいい

>>760
それ、危険な考え方じゃない？

>>755
よくわからんが、正確にはVCじゃなくてVC++を使用。＞CL

>>752
> プリプロセッサが入っちゃうとヘッダーファイルが出来ちゃう。
おいおい…

>>763　STLを内蔵させればSTLについてはあるという事に出来るけど

自作のジェネリックライブラリを作った場合は、何らかの方法でソースで指定する必要が出るでしょ？

>>764
何が言いたいやらさっぱりわからん。
俺がアホなのか？

>>765
俺も分からんから、気にするな。

"ジェネリック"ライブラリのジェネリックってただの名称じゃないのか？

>>765
だから、自作のテンプレート関数を書いたとするよ。
それをいちいちコピペするんじゃ　テンプレート関数にする意味ないでしょ？
テンプレート関数がどこにあるか指定する必要が最低あるでしょ？
それはJAVAの文法だと先頭に宣言する必要があって、やっぱりヘッダーファイルと呼ぶんじゃないの？

>>768
それって、上にいくつか出てる Java の Generics の実装を見た上で言ってるのか?

>>768
やっぱりわからん。
Javaをよく知らんのか？

>>768
STLがヘッダーファイルだから、
テンプレートが入ると必ずincludeしなきゃならない、
と思ってるんだＮＥ！

>>768
コンパイラも新しいのが必要になるんだから、
-templatepathとかオプション追加すれば
いいんじゃないの？

>>768
もういいから JavaWorld の特集読んで出直してきてよ

>>773
768じゃないけど、そういう言い方は嫌だな。

勉強不足な俺が悪いんだからもういいですが

import　で、テンプレートを指定するか、別の宣言になるか判らないけど、インポート宣言が必要になるだろうし
STL程強力なライブラリを実現するためには、
そのインポートされるライブラリは完全にはコンパイルされない状態でないと難しい筈
つまり、ライブラリだけを差し替えて動かすためには　どこかで再コンパイルが必要になる筈だと
思ったわけです。　それが解決されているならいいです

2chでJavaの標準ヘッダー作ったらどうよ？お前等も少しは貢献しないとな！
#define BEGIN {
#define END }
#define IF if (
#define THEN ) {
#define ELSE } else {
...
誰か草案まとめてくれ。。。

次>>777が>>1の結論を出す！

おまえじゃん

正直、長いこと C++ やってるとだんだん template 使わなくならない?
だから俺 Java 始めたときテンプレートなくても変な気しなかったけど。

# 使うと作るはまた別か。あの頃に STL があったら使ってたかも
# しれんが。

>>779
templateキーワード自体はめったに使わない（ｗ
がSTLなんかは頻繁に使う。

>>779
いや、むしろよく使うようになるけど。

「作る」方にはアルゴリズムなどを自分で書く機会は少ないけど、Mixin を書いたり
Facade には使うけどな。template 使った Facade は、こんな感じね。

template<
　　class TWindow,
　　class TDisplay,
　　class TSoundDev,
　　class TScript
>
class DemoPlayerBase
{
　　// 中身実装いろいろ
};

typedef DemoPlayerBase<MainWindow, DirectX7Display,
　NullSoundDev, DemoScript> DemoPlayer;

もちろん template 使わずに WindowBase, DisplayBase, SoundDevBase みたいな
抽象基底クラスを作ってそれを継承してやってもいいんだが、こっちの方が潰しが
効く。

>>781　コンパイルに相当時間かかりそうな・・・

>>782
DemoPlayerBase のサイズによるけど、ふつーは

- Facade 部分は、各モジュールをつなぐ接着剤のように使う
　メッセージの転送が中心の、小さなコードの断片
- Facade でまとめる各モジュールの実装は *.cpp に書いておいて、Facade
　をコンパイルするときに見るのはヘッダだけ

としておくから、大して問題にならんよ。それに最近のマシンは十分に速いし。

あの、そろそろスレ趣旨に戻さへん？

>>784
っつか、ネタ切れなんでは。

俺もSTLほとんど使わないな。
作っても一回しか使わないようなのをSTLにしても
意味ないもん。

>>786
「STL にする」の?　「template にする」なら文意が通るけど。

ゴメソ>>787

ポリモーフィズム ⇒ 向光性
テンプレート ⇒ 厨楽聖
コピペ ⇒ 生姜区政

>>789
つまってない、それ。

♥

いやー、Javaにプロプロセッサ入れてファイル分けライブラリに移行しただけで
再利用率７０％逝きそう。
もう無理してクラス使わなくてええわ。

ぷろぷろ萌え。

>>792 CPP, m4, JPP, EPP どのあたりつこーてはるんでしょ？

LISPとか、Perlの様なスクリプト言語みたいに
プリプロセス用コードをJavaならJava自身で書ければいいんじゃないかと。
現状「プログラム作るためのコード」しか書けないじじゃん。
「プログラム作るためのコードを作るコード」を書ける様になれば、
ファイルをどこに置くかなんて問題は一蹴されるかと。

VC++のcl.exeですだ。

あ、プロプロになてる。

>>795
LISPとPERLはよく知らないんだけど、
具体的にどんな事ができるの？
792はいったいどういう事したの？

defmacro(lisp)とかeval(perl)だと思われ。

再利用率って
そんなに同じようなプログラム何度も書いてるのかな？

>「プログラム作るためのコードを作るコード」を書ける様になれば、
アルゴリズムの方が問題になるよ
つーか、プリプロセスってどういう意味。

>>800
＞アルゴリズムの方が問題になるよ
なんの話？
＞つーか、プリプロセスってどういう意味。
前処理

>>800
同じようなプログラムになるように構造を考え、設計するの。

フーリエ変換のコードを作るためのコードは
書けないと思われる。

>>802
普通の構造化と何が違うの？

構造化は記述レベルの整理整頓の話。
設計レベルの話とは全然違う。

設計はOOでいいんじゃないの？
抽象クラス作っておいて、それ継承すれば
同じような構造の巨大な関数を
構造化できる。

ＯＯで設計してたんじゃ日が暮れちまうよ

ＯＯでもいいけど、クラス型言語は邪魔なだけ。

多態が便利なだけ

頭のいい、明日にも新らしいオブジェクト指向の言語を発表しそうな、
スーパープログラマーの方ばかりが参加されていそうな、このスレですが、
私のような年寄りバカPMが現場で大事にしている４つのことがあります。

１．OO分析はほぼ失敗する。
お客さんが相当に自分の業務について把握しており、頭にモデルを
もっておられればいいですが、そんな経験ないです。
結果、的確でないオブジェクトを作ってしまうことが多く、手戻りが
よく発生します。実験ではうまくいきますが、それでできたつもりに
コンサルやベンダーも客もなってしまってることが多いです。
例外をすべて捨てれば、ビューティフォーにできますよ。ケッ

２．OOプログラミングは推奨できることがある。
すでにJAVAなどの世界でいわれているフレームワークのような
もの（そんな立派なもんじゃないです）を持っていて、今回やる
プロジェクトに、はまればいい感じになります。
そうでない場合、いくらオブジェクト作成部隊にメソッドと
プロパティの定義だけを渡したとしても、みなさんのように頭の
いい人間に仕事を頼んだことがないせいでしょうか、いつも仕様
変更を起こしてしまいます。それは耐えられないので共通の
オブジェクト作成の時間をいかに短くできるかがキーだと思って
います。

３．ディメンジョンの違い
計算機固有の事情と、アプリの事情は別々のディメンジョンで
考えるようにしています。つまりオブジェクトもふたつの
ディメンジョンをもつということです。
ここに書かれているような頭のいいプログラマーの方はすべて
OOでできる素晴らしい能力（なんせOSもOOで作れると断言され
てますよね）をお持ちでしょうが、バカな現場では細かく分けて
考えないと理解できないです。

４．人材
このスレにあっという間に集まるような超生産性高く、全知万能
スーパープログラマー（推定年収2000万円）の方を集めることに
成功したことはないです。したがって、OOでシステムを作る時も
利用すべきオブジェクトとインターフェースは全部レビューします。
したがって、ポリモアフィズムなんてことは期待せず、すべて
別のメソッドとします。それでも、クソコードを書く輩が当初は
非常に多いです。まさか、私にやんわり書き直しを命じられた人が
このスレにはいないでしょうね。

以上、頭のいいOOを完全にご理解されているであろうスーパー
プログラマーの皆さんへ、現場からの報告でした。
でも私はこの方法でしっかり金を稼いでいます。

>>810

どう見てもあんたに使われるPGがかわいそうだ。
OOでウォーターフォールやられたらそりゃ辛いわ。
「手戻り」って言うな。「イテレーション」って言え。

>>810
> なんせOSもOOで作れると断言されてますよね
既に実装があるじゃん。

1に関してはOOがわかってないだけだろ？

OOの必要性は、「クライアントは馬鹿である」だぞ！！

>810

このスレはアホばかりですよ。
見識を疑います。

�@要求分析→�A設計→�B実装→�C試用→�D実用
っていう教科書的やり方はＯＯに限らず巧くいかない。
�@の段階では大抵のクライアントは「自分が何をしたいのか良く判ってない」
場合が非常に多いから。
んでもって、ＯＯは仕様変更に非常に弱いという欠点を持ってる。

�@ＧＵＩサーフェスだけ作る→�Aクライアントに見せて欲しい機能を確認
→�B中身を作る→�C確認→�D次のサーフェス→�@
という方法の方がいいかもしれん。
クライアントが何をしたいのかは�Aで初めて判る
（クライアント自身も初めて判る）

>>812
どうせクラスで書いただけだろ。
ＯＳを完全にＯＯで組むなど原理的に不可能。

>>816
> ＯＳを完全にＯＯで組むなど原理的に不可能。
どういう「原理」から導けるの、それ?

オブジェクト指向はオブジェクトが適切に定義できないと使えない。

しまった、ネタだったのか…

>>812
すでに実装があるじゃんってどれのこと指していってる？

>>820
812 がどれを指してるのかは知らんが

http://directory.google.com/Top/Computers/Software/Operating_Systems/Object-Oriented/

なんてのは見つけた。

>>821
リストの中にある「java」ってなんだよ（藁

?JAVAOSって名前くらいは知ってるでしょ?

外国のＯＳヲタって凄いね。（藁

ＪａｖａＯＳは何で書かれているのですか？

>>821 ｸｽｺ
なんか聞いたことも見たこともないようなのが
沢山あるね。見てみるよ、ありがと。

ところでgoogleのwebdirectoryって使えるんだね。

とにかく、検討してやるからソースだせソース！

ＪａｖａＯＳがＯＯで書かれているのは確かなのか？妄想か？

>>825
ポインタが示されてるんだから、後は自分で検索すれば？

>>810,>>815 ネタだとは思いますが、、、
(1)要求分析レベルでは、実世界の物/概念に対応したオブジェクトを抽出し、
　そのオブジェクトを Javaなら Interface、C++なら 抽象クラスにして、
(2)設計レベルでは、実装用のクラス設計をする、

というあたりは、基本として覚えといてください。
(1)ではユースケース図で、アクター(人)と システム の相互作用を簡単に記述し、
　それを詳細化していく、「ユースケース駆動」使うのが、RUPでもXPでも常識でわ？
＃漏れは体で覚えました(泣

>>815 さんはちょっと違うことをいってるんでしたっけ(プロトタイピング手法でしょうか)

まんこ

飢えてるんですか？かわいそー

>>829
バーカリンク先が全部ＯＯで組んだＯＳというならお前の負け。
氏ね！

>>830
知っているだけの単語を並べて見たんですか？藁

ここにもかわいそーな人

>>835 って優香、>>810,>>815 あたりに
　まっとうなレスついてないのってネタ？

>>837
810 も 815 もネタでそ。

ネタって言ってる奴はＯＯ馬鹿か煽り屋。

煽り屋は、名前空白の約一名と認識してます（ｗ

>>834
勝ち負けを競っていたのか…。良いからとりあえず、リンク先のドキュメントを
読んでくれよ。

ＯＯで組んだＯＳがあると主張した側に証明義務があります。
せめてどのＯＳがそうなのか示すべきです。
それもしないのは馬鹿で煽りだからです。

どーもお騒がせしました(汗

ところで、>>830 変？

>>841
リンク先を示しても分からないと韜晦されたのは Kusakabe 以来だよ。鬱だ。

>>843
へー　じゃあＪａｖａもＯＳなんだ　へー。
お前はＯＳとは何かから調べなおせ。

結構いっぱいありますね、ＯＯＯＳ
＃ふぉろー、と。

Apertos - http://www.csl.sony.co.jp/project/Apertos/index.html
　Reflective Object-Oriented OS from Sony Computer Science Lab.

Paramecium - http://www.cs.vu.nl/~leendert/paramecium.html
　Simple, flexible, adaptable, extendable OS used to explore
　tradeoffs between user processes and kernel boundaries.
　Services provided by objects named in a per process name space.
　Supports parallel programming.

Moscow - http://www.web-sites.co.uk/jules/moscow/
　Main ideas based on OO architecture of languages like C++,
　mainly involves automatically generating virtual method tables
　at load- or run-time. Applications then become, at a basic level,
　object libraries that can be reused or altered individually.
　Patch objects can replace parts of existing applications,
　for high user flexibility and configuration.

Object Oriented Operating Systems - http://www.cs.arizona.edu/people/bridges/os/oop.html
　Short, annotated, alphabetically sorted list and links,
　part of larger system.

PEACE: Process Execution And Communication Environment - http://www.first.gmd.de/peace/peace.html
　An OS family with truly object-oriented design developed
　at GMD FIRST. Emphasis: performance, configurability, portability.

SOS: SOMIW Object-Oriented Operating System - http://www-sor.inria.fr/projects/sos/
　Most interesting research results: simple, generic,
　powerful object model; the concept of Fragmented Objects
　to structure distributed abstractions; developed flexible
　naming service, dynamic linking package, library of
　application oriented communication protocols.

The Evolution of OS Design - http://freshmeat.net/articles/view/237/
　Object Operating System, OOS, pronounced ooze: attempt
　to create a new OS architecture, designed to use a filesystem
　to do many tasks usually done via various means.
　Design philosophy much inspired by Unix and Plan 9,
　but does many things uniquely, trading compatibility
　for simpler design. [Freshmeat]

Athene - http://www.rocklyte.com/athene/
　Next generation, commercial, kernel independent,
　all object and component based computing environment
　and OS that users can design to their specifications.
　Backend is built to run in almost any environment.

Unununium Operating Engine - http://uuu.sourceforge.net/
　Claimed as a radical new approach to OSs: no kernel,
　self-modifying cells (objects); single-address-space,
　useful where memory and CPU power is limited, and maybe for AI.
　Written in self-modifying, modular assembly language. [Open Source, BSD]

Renaissance - http://www.cs.purdue.edu/AnnualReports/95/AR95Book-120.html
　Multiprocessor OO OS purely designed and implemented in
　object-oriented techniques, to give application programs
　transparent access to system and remote objects distributed
　in a network of machines. OO programming is an ideal approach
　for building distributed systems. Runs on Sun SPARC,
　Encore Multimax multiprocessor.

ShagOS - http://www.csh.rit.edu/~shaggy/shagos.html
　Portable object-oriented microkernel OS, dynamically
　loaded device drivers, fully redesigned and rewritten
　many times in C++, runs on VAX, x86. Ongoing experiment
　in using O-O paradigm as framework for full OS,
　with distributed computing as main aspect in most design decisions.

Objex - http://www.objex.org/
　Like GNU project, aims to develop full OS of
　Free and Open Source software. Unlike GNU, it aims to
　build a modern system combining all new advances in
　computer science, not a Unix-like system.
　To include kernel, full developer tool suite, utilities,
　graphical user interface (likely Berlin).
　Object-oriented, fully distributed (with CORBA), etc.

OGMA: Sound Foundation for Object-Oriented Operating System - http://decef.elf.stuba.sk/~urbane/Download/OgmaSVOC.pdf
　To create an OO OS, we need just a few mechanisms provided
　by a microkernel; we are creating one that gives mechanisms
　useful to implement such a system: single address space,
　persistence management, user level scheduling.

Atoms Project - http://atoms.sourceforge.net/
　Goal: define a framework for a new open computer system
　incorporating the best features of current OSs,
　database management systems and distributed networking.
　Just beginning.

O3ONE - http://www.o3one.org/
OZONE object-oriented OS uses the best parts of VMS, Unix,
　Windows NT. Almost everything in the kernel is an object
　(threads, processes, devices, files, event flags, more)
　to which one can assign logical names. [Open Source]

GO! - http://www.soi.city.ac.uk/~gel/go/default.html
　Component-based OS, runs natively on IA32 (Intel 80386+) based PCs.
　Uses novel protection mechanism which allows increased
　decomposition of OS, and unrivaled performance:
　protection overheads almost 1,000 times lower than
　standard commercial OSs.

Iguana Project - http://www.dsg.cs.tcd.ie/%7Ecoyote/
　Investigating use of object-orientation,
　computational reflection, and metaobject protocols (MOPs)
　to support dynamic customizing of (system) software.

>>844
他のOSの介在無しで直接Java環境を実装したら
そのJava環境の実装はOSと呼んでさしさわりないと思うが。

よーしやっと示したな。
後で言い逃れされるからはっきり示せといったのだ。

>>848
自分はOSをOOで実装できないとする根拠は何も言わないクセにね。
ま、煽り屋だから仕方ないがな。
ところでこのスレでも君のような主張をした煽り厨が論破されてるようだが
君はちゃんと目を通したのかな？
っつーか、ひょっとして同一人物？ (藁

まずApertosは1996年を最後に研究を止めているようだ。
資料もリンク先から消されているんで対象外だな。

独自クラスが充実してるよりも、独自関数ライブラリが充実
してたほうが開発が楽という実感はボクのモウソーですか？

>>849
とっくに書いただろ。
リンク先を読んでもいない馬鹿を相手にしてもしょうがないので止めるわ。

Microsoftの.NETベースの次世代OSは当然OOで作られるんじゃないの？

>>851
クラスより関数が再利用しやすいってのはモジュールよりねじのほうが使い回しがきくってのと同程度の問題だと思う。

>>852
は？ひょっとして>>818の
> オブジェクト指向はオブジェクトが適切に定義できないと使えない。
のことを言ってるのか？ これが根拠になると本気で思ってるのか？

せめて、OSの実装では何故オブジェクトが適切に定義できないのか
その根拠を示してみろよ。
もちろん、「俺には定義できないから」は根拠にならんからな(藁

「オブジェクトとは，日常生活に見られる物体を、ソフトウェア・プログラミング上でモデル化して表現したものです」

ところが コンピュータ上の資源は日常生活に見られるものではない

>>856

で？

少人数先鋭が前提のOS開発と、
われら凡人プログラマがやる業務系OOは
ものとして別な気がするのですが。
OSがOOで開発できるという事実が
うちらになんの関係があるのでしょうか？？
実際にOSを作っている人ならいいけどさ。

おもしろそうだからソースコードを
見てみようとは思うけど、それはなんつーか、
おあそび。

>>856
ワロタ。
だとすると「ロケット」とか「人工衛星」なんてのもダメだな。
アンチOO厨には「オブジェクト」すら「オブジェクト」にできないわけだ。
つまり、厨にオブジェクト化できるのは「煽り」ぐらいなもんだっつーことだ。(藁

>>859
0点

>>860
ナミダメニナテルヨ。ゲンキダシテ。

>>859
つまらない挙げ足とり。

最近は、OSそのものがユーザサービスを提供してしまう場合も出てきている
たとえば、Windowsをインストールすればインターネットが覗けて、メールし
たりFAXしたりも出来てしまう。

しかし、オペレーテングシステムの役割は基本的には
「アプリケーションプログラムに実行環境やサービスを与えること」であり
メモリ、ストレージ・ファイル管理、種種の入出力の管理、そして、アプリケーションの実行
に関するサービスが主な目的のはずだ

これらを　いわゆるオブジェクト指向的なスタイルで提供する事は出来るが、
それはOOP言語を便利に使ってるのと同じ事ではないか

それを　オブジェクト指向の言うオブジェクトだと呼んで良いのであれば
WindowsAPIもオブジェクト指向で書かれている事になる。

時には　OOP言語を便利に使ってるだけではオブジェクト指向ではないといい
そして時に、OSのように人の生活から離れたものでさえオブジェクト指向設計だという
あまりにも節操がない

オブジェクト指向云々を朗々と喋りだす奴はたいてい　この　ダブルスタンダード野郎だ

いわく　オブジェクト指向はそんなものじゃない
いわく　それはOOP言語を便利に使ってるだけ

そして任せて失敗すれば、「オブジェクト指向をちゃんと使いこなせなかった皆が悪い！」

>>863
OSが管理すべき資源などをオブジェクトと捉えてモデリングすることは
OOPLを使って実装する事とは別に意味のある事だ。
メモリ管理然り、デバイス管理然り、プロセス管理然り。

アンチOO厨は、
時には 全てOOPLで実装されていなければオブジェクト指向ではないといい、
そして時に、人の生活から離れたものはオブジェクト指向で実装できないと言う。
あまりにも節操がない。

>>864
そっか。864は
「オブジェクト指向をちゃんと使いこなせなかった皆が悪い！」
と、何回も何回も繰り返し言われ続けて、まだダメダメなんだね。
ヨチヨチ、イイコダカラ、ゲンキダチテネ。

誰か上のOSどれか一つでも解析してみたか〜？

>>866

オブジェクト指向設計を使いたいといい
そして仕事をする権限を与えられたら、それを使って成果を出す責任をはたすべきだ
という簡単な話をしたいだけだ

その責任として、守るべきはユーザの満足だ。それは納期であり、結果である筈だ。

納期が事前に提起されいて、それを理解した上でスタートしたはずなのに
問題をより複雑にし、仕様を膨れ上がらせ、何度も試作をくりかえし、そして・・・

まあ、そういう奴ばかり相手にしてしまう俺がバカって結論だな

>>868
> まあ、そういう奴ばかり相手にしてしまう俺がバカって結論だな

ふーん、問題なのはOO技術じゃないってことはわかってんだね。

> 納期が事前に提起されいて、それを理解した上でスタートしたはずなのに
> 問題をより複雑にし、仕様を膨れ上がらせ、何度も試作をくりかえし、そして・・・

ま、OOだろうがなかろうが、よく聞く話だわな。で？

Boochがｷﾓｲからやだ

Iguana Project はリンク先が無い。
バーカ。

GO!もリンク先無し。
氏ね！>>845
読んでもいないのに何をえらそーに！

OO って既に古典やん。

ShogOSは1997年で活動停止。

とりあえず OSリンク貼っつけたのは漏れです。
リンクが切れているつう苦情は、
プロジェクト責任者もしくはGoogle までどうぞ。

つーかリンク切れのやつはぐぐればいっぱい見つかる。

つーか犬がメジャーになったころにほとんどの
プロジェクトが終わっているような・・・

整理するとこんな感じでわ？

・オブジェクト指向でOS作ろう、って試みは 80年代から継続的にあり、
　いくつかの成果が出ている　＝ Googleリンク

・他方、商用OSの主流は ここ10年で
　・UNIX/POSIX系か、
　・MicroKernel系か、
　・リアルタイム組み込み系
　つうあたりに集約されてしまていて、
　今更新規OSつくる意義って、
　一部の組み込み機器/専用機周りにしかなくなりつつある。

・逆に、この10年で重要度が増したのは、
　・ネットワーク・サービス
　・コンポーネント (異議あるかもしれない)
　・プラットフォームのソフトウェアAPI化 (NeXTSTEP, VMware含んで)

でわ？

INUテナンデスカ？

ところで、OS が作れると何がどうなんだろう。

INU=linux
うに板では常識です

>>880
特になにも変わらない。ＯＯ信者のオナニー。
OZONE objectのソース見たけど、
「変数と関数を集めたものがオブジェクトなり」という意味以上の何者でもない。

インターネット/ネットワーク・サービスと マイクロカーネルと 分散オブジェクト技術(藁 で、
オブジェクト指向な新規ＯＳの必然性激減 て事で、おけー？

お前ら MJ とか AspectJ とかどう思うんですか。

お前ら fj とかどう思うんですか。

万能戦艦マイティージャック（円谷プロダクション）？

>>884 マルチパラダイム・デザインてドメイン分析の本みると、
　そのあたりを束ねて、一般的な概念としてまとめようとするのが、
　近年の研究開発動向なのかなーなどと思いました。
　＃まだ全然読み進んでいないけど

まいてぃーぼんじゃっく

これか。
http://dolphin.c.u-tokyo.ac.jp/~kazu0/aspectj-primer/primer-fornewcomers/

マッチポンプというか、自分で問題作っといて、
「新たな解決手段を（・∀・）ﾊｯｹｿ」
ってやってるだけじゃん。
クラス型言語使わず、全部グローバルで組めば解決。

>>864
私、OO ﾏﾝｾｰ君ですが…、
それは「昔、自分がやっちゃった事を繰り返さない為の自戒」をみんなに公表してあげてるのでは？

＞オブジェクト指向はそんなものじゃない
＞それはOOP言語を便利に使ってるだけ

私は初め OOPL に振り回されてアフォなソースを大量に書きました。

＞失敗すれば、「オブジェクト指向をちゃんと使いこなせなかった皆が悪い！」

そして、大失敗しました、私がちゃんとオブジェクト指向を使いこなせなかったからです。
OO に対する理解が深まってくると、その頃書いたソースは全て消し去りたいです。まったく OO を使いこなせてないですから。
もっと OO を理解しましょう。OO 否定派だとしたら道は果てしなく遠いですが。

>>889
読み方ひねすぎ。

http://aspectj.org/documentation/papersAndSlides/PARCForum-2000.ppt

ここら辺が分かりやすい(古いけど)。

>>889
あなたの理論でいくと、人間はアフリカの大地で猛獣の影に怯えながら
文明を持たずに生きていく事が理想だという事になりますね。

これからアンチ OO を「原始人」と呼ぶのをこの板のローカルルールにしませんか？

>>890
OOPL 覚えたてのプログラマがやる駄目コーディングってあるよね。
片っ端からクラスにまとめようとするとか。
片っ端から継承ツリーにおしこもうとするとか。
初学者は OOPL で[できること]と[やるべきこと]を混同しがち。

>>856
どこから引用してきたのか、典拠を示して欲しいところだが。

>>894
継承って、なるべくしないほうがいいと思うんだけど。
なるべく委譲にするようにした方が…
多態を使うことを前提とする部分に限って、閉じた世界の中で
継承を使うこともある、という程度にして欲しい。

何の存在意義もない継承ツリーの途中のクラスが大量にあって、
（たんなる分類用のツリーの1ノードくらいのイメージで、クラス
作ってやがるバカがいるのよ、うちに。）いやになる。

>いやになる。

レビュー時に潰せYO!

>>897
うちのメインアーキテクト。逆らうと（特に理屈で逆らうと）
逆切れされて首になる。鬱だ…何でそんな奴が技術職やってんだろ…

さっさと辞めて吉

オブジェクト指向が広く定着しないうちに次のプログラミングスタイルの
パラダイムは来ると思う。
オブジェクト指向を支持する人には悪いけど。

>>900

もっと良いものがあるならそれでもいい。
OOP使用者はCOBOLERやバカVB厨じゃないんだから、いいものが
あれば取り込んでくだけだ。

900の言い草は、具体性がないので単なる負け惜しみのように
聞こえるが。

>>900
そのパラダイムはオブジェクト指向を理解してる事を前提にしているという罠。

>>902
OO だって以前のパラダイムを無視してるわけじゃなくて、データ抽象やら構造化
やらの成果を取り込んで出てきてるわけだし。Post OO が OO の成果を取り込ま
ないことは考えにくいな。

ちょっと前の ACM Communications で Post OO の最右翼である AOP の特集やっ
てたけど、あれでも

　Q: AOP は OO を置き換えるものか?
　A: 全く違う。

っつーよーな問答があった。

実際 Generic Programming にせよ AOP にせよ、OO の成果をとりいれつつ、それで
は解決しない部分（たとえば Crosscutting とか) に対してどういう統一的な視点／解
決策を出せるかって話になってるよね。

OOで書かれたOSがないから
OSはOOでかけないって言う理屈はないよね。

OOってのはコーディングスタイルなわけだから
どういうプログラムが書ける書けないってのはないよ。
適している、適していないっていうのはある。
適していない例ってのは、例えば
このAPIってどんな機能なんだろ？っと確かめるテストプログラム。
まあ、こんなのはグローバル変数使いまくりの・・・って感じでよい。
なぜなら、頭の中で全ての変数が管理できるし、
OOでやってると時間がもったいないからね。

OOPLってのはOOっていうコーディングスタイルを
取りやすくしてる言語でしょ。
CでもOOができるって意味はわかるかな？
ただ、オブジェクトっていうメソッドとプロパティーをリンクさせる
概念とか、
オーバーライド＆継承（インターフェース）みたいに
関数ポインタを使いやすくしてくれる機能とかがあるC++は
より、OOっていうコーディングスタイルをとりやすい。

だから、C++で書いたOSが
virtualの使い方が誰もが納得できる合理性を持っていて、
メソッドとプロパティーのリンクも合理的であればOOスタイルのコーディング
と見て取れる。

実際にある物をイメージして設計するのがOOじゃない。
関連あるデータを概念化して設計するのがOO。
構造化との違いは
構造化は同じパターンのプロセスをまとめる事（関数化）しか興味がない。
一方で、OOというのは同じようなデータをまとめて扱う事に興味がある。

エージェント指向ってどうなんだろ？
昨日本屋でエージェント指向っていう
薄くて小さな本があって、前半がOOについて書かれていて
後半がAO（エージェント指向）についてって感じだったんだけど。
結局その本には具体的なことが何も書かれてなくて・・・
なーんだ詐欺本じゃんって思った。

俺がOO身に付けたのは、結局JAVAやって
あーなるほど、そういう設計の仕方があるのかって感じで
すごい人のソースコード読んだから理解できたんだけど・・・
AOに関しても、そういうコードがあればいいんだけどな。

>>900
おれもそう思う。
OOの問題点なんかも見えてきたし・・・
とりわけ抽象化の手法はOOが全てじゃない事は確かと思う。

>>905
エージェント指向は大雑把に２通りあると思う。
ひとつは実行状態付きシリアライズが可能なモバイルエージェントと呼ばれるもの。
もう一つは人間の代行作業用途に主眼を置いたインテリジェントエージェントと呼ばれるもの。
前者の研究よりは後者の研究の方が今はさかんらしい。
MIT や Stanford のページに行くとそれっぽいのが色々あるよ。
どちらにしても OOP の次とかいう代物じゃないと思う。
むしろ、オブジェクト間の協調動作を重視した OOP の一応用って感じ。
１エージェントが１オブジェクトでパラレルに協調動作
って具合のイメージで概ね通るし。

>>900
オブジェクト指向を支持するっていうより
勝手に身についた技術だよ。
こうやって書けば、きれいに書けるっていう。

OOの問題点って、君まだOOわかってないのよく言うね。
君の場合、抽象化よりも
アルゴリズムの知識が乏しすぎて
ライブラリー使ってるだけな人なんじゃない？
コーダーにはたぶんOOいらないよ。

>>908
へんな煽りする子だね。(^^;

>>908
現行の言語の、OOPL の水準での問題点は明らかにあるよ。
AOP なんかで取り扱われるクラス横断型の処理の実装のしにくさなんかがそう。
ただ、それが OO や OOP の水準に由来するものであるかどうかは判然としない。
複数モジュール横断型の処理、と言い換えれば、
これがそんなに書きやすくないってのは OOPL 特有の問題でもないと思うしね。

>クラス横断型の処理
これってどんなもんですか？

>>911
意味は、たとえば単一継承しか許さない言語で
既に特定の異なる継承ツリーに収まってしまっている複数のクラスを対象に
いずれにも同一の処理を実装したい、というような場合のコードを指す。
AspectJ のチュートリアルなんかだと
メソッドの呼び出し前後のデータロガーを作りたい時なんてのが例示されてる。
うまく使えば、様々なクラスに共通するが継承ツリーには押し込めない前処理・後処理を
別モジュールに切り出して一元管理できる。