トップページ⇒tech
854コメント333KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001うつつつつNGNG
前スレがめでたく止まったようなので、その3
引き続きOO厨とアンチOO厨の血で知を笑う戦いきぼ。

その1 http://pc.2ch.net/test/read.cgi/tech/1011997945/
その2 http://pc.2ch.net/test/read.cgi/tech/1013266554/

0554デフォルトの名無しさんNGNG
理解してないと思いたいのですね:)
0555デフォルトの名無しさんNGNG
大規模プロジェクトをOOでやるのは危険です。
その理由は以下に↓
0556デフォルトの名無しさんNGNG
なっちありがとう
0557デフォルトの名無しさんNGNG
http://pc.2ch.net/test/read.cgi/tech/1012484747/
0558なっち怒ってます(○ ´ へ ` ○) NGNG
なっち怒ってます(● ´ へ ` ●)
0559 NGNG
>>543
激しく同意
0560デフォルトの名無しさんNGNG
>>553
>アンチは教育してやれば理解するようになるが、
>XP信者は永遠にプロセスを理解することは無理だな。

XPってのはOOを理解した上での原点回帰だと思うが、その口ぶりだと553はOOを理
解せずにXPやってる現場ってのをどこかで見てきたようだな。
非常に希少な例だと思うんで紹介してもらえないか?
0561デフォルトの名無しさんNGNG
>>560
つーか、XP自体がプロセスを極端に調整した例だということを
理解してないようですな。
XPをちゃんと運用するためにはソフトウェア工学、特に方法論を
教科書憶えただけでなくしっかり身につけている人が必要で、
その上でその極端な例としてのXPを実行するもんだと思うのだが。
型無しと型破りの違いだな。
0562デフォルトの名無しさんNGNG
XPやってる奴って、ゴシック様式の建築物みたいなOOの方法論に
嫌気がさしてやってるもんだと思ってるけど。オレモナー(藁
0563デフォルトの名無しさんNGNG
訂正
×XPやってる
○XPに興味もってる
0564561NGNG
>>562
うん。そういうゴシック様式というか、セレモニー的な部分を
極端に減らしているのがXPだよね。
で、その分、リファクタリングやユニットテストで補なっているわけだし
ストーリーとユースケースも深い関係がある。
上に挙げた用語はどれもソフトウェア工学の用語だし、その背後にある
相互関係や危険サインや監視の仕方や対処法なんかを理解する必要がある
と思うけど、どうよ?
0565デフォルトの名無しさんNGNG
>>564
RUP、つーかラショナルが嫌なんだよね。結局プロセス実行するには
ツール買わせるように出来てる。この辺りの巧妙な手口は正直好かん。

理論としてはヘーゲルの「歴史」を想起させるぐらい立派な
ものを目指してるのかもしれないけどさ。その裏にある動機が
いやらしい形で見えてくるのがキショイ。
0566561NGNG
>>565
あ、それは俺もある (藁
なんだよ、そのRはよぉ、って。

その一方で、プロセスってのはそのまま適用するものじゃなくて
各プロジェクト毎に改変して応用すべきものだとも思うんだよね。
だから、あんまり1つの方法論にベッタリなツールも嫌いだったりする。
俺にとってはツールに期待するのはUMLであってRUPじゃないんだな。
0567デフォルトの名無しさんNGNG
>>567
一応教科書読む限りじゃ、プロセスはプロジェクトにテンプレートを
与えるものっていう位置付けになっていて、ツールはプロジェクト
じゃなくてプロセスに対応するものという位置付けになってる。
だからツールはかなりの汎用性を持たせてあるんじゃないかな?

おれはRationalナントカなんて触ったこともみたこともないから
詳しいことはしらないw。教科書読んだだけのヘタレだから。
ただ一つ言えるのは、RUPなんていったところで彼らが仕様を無償で
公開してるのは方法論のモデリングに関する成果だけで、実務を
遂行するにあたり必要となるツールに関してはおそらく特許で
ガチガチになっているものと思われます。危険です。
彼らの言うプロセスとはイコール、ツールのことですw。


この濡れ衣を脱がせる人、なんか書き込んでください。
0568デフォルトの名無しさんNGNG
上の567は>>566の間違い
0569デフォルトの名無しさんNGNG
http://acd.nabunken.go.jp/Nabunken-Doc/chousa/international/Angkor/sites/PreRup/PreRup.html
0570デフォルトの名無しさんNGNG
>>567
>ツール
というか、RUP にすら満足に使えない
0571デフォルトの名無しさんNGNG
必要かどうかは別として

結果として出したプログラムのレベルは
OOできない人=アンチ<<<<<<<<<<<<<<<<<OOできる人
だと思うけど、どう?
0572デフォルトの名無しさんNGNG
>>571 そのプログラムのレベルって何で測るの?
0573デフォルトの名無しさんNGNG
>>572
if文のネストの深さで
0574デフォルトの名無しさんNGNG
>>571
必要かどうかは別として

「レベル」とか「○○>>>××」とか言ってる奴は
厨房だとだと思うけど、どう?
0575デフォルトの名無しさんNGNG
>>574
プログラムには、実装・設計とも良し悪しはある。みんな平等ということはない。

ただ、

 プログラマをOO派・非OO派に色分けしたときに、このスレで出てきたプログラ
 ムでそれぞれの能力を測る
 
ことには全く意味がないし、そんなことをして喜んでるのは厨房だと思う。
0576デフォルトの名無しさんNGNG
>>573 つまり OOできる人ほどネストは深いと?
0577grrrrrrrrr....NGNG
>>576 ソフトウェア・メトリクスの勉強汁
0578 NGNG
俺より頭がいいやつは全員氏ね
0579デフォルトの名無しさんNGNG
おとなしく学歴板にかえんな
0580デフォルトの名無しさんNGNG
非OOで書いたレベルの高いプログラムキボーン
0581 NGNG
>>577
cccc以外の使いやすいメトリクスツールを紹介してくれ。
0582デフォルトの名無しさんNGNG
BSD
0583デフォルトの名無しさんNGNG
>>581
http://osb.sra.co.jp/Smalltalk/ObjectOrrery/Japanese/manual/index.htm

>>エセsmalltalker
http://www.sra.co.jp/people/aoki/Jun/Main.htm
0584デフォルトの名無しさんNGNG
>>582
どのバージョンの?

4.4BSD 以降だと VM の設計なんかは、言語こそ C だがかなり OO っぽい
と思うぞ。newconfig とか new-bus も然り。
0585デフォルトの名無しさんNGNG
>>580
PC88板アルフォス(by森田)
0586デフォルトの名無しさんNGNG
>>583
エセSmalltalkerって誰のことだ?
春になってきたのかなぁ…
0587デフォルトの名無しさんNGNG
>>567
ラショナル製品を買えないほどの貧乏会社で
働いてるんだね。プ
0588デフォルトの名無しさんNGNG
あんなの予算おりるか?
まあ、予算取ることはできても活用できなそうで乗り気にならない。
0589デフォルトの名無しさんNGNG
>>588
必要経費
0590デフォルトの名無しさんNGNG
>>589

不必要経費の間違いじゃネーノ?
買ったはいいが死蔵してる会社って結構多いぞ。
0591デフォルトの名無しさんNGNG
俺の私的メモ

ラショナル製品を導入後、継続して活用していますか?
・はい 5%
・いいえ 95%
0592デフォルトの名無しさんNGNG
つーかさ。
OOはプログラマなら誰でもかかる一種の麻疹みたいなもんなんだよ。
命を落とすほどの病気じゃないから、そう、目くじら立てるなって。
0593デフォルトの名無しさんNGNG
>>592

そう思わないと精神の安定が保てないCOBOLERさんですね。
構造化を1週間分処方しておきますので、薬局で受け取ってから帰宅して下さい。
理解できるまで来なくて結構です。
0594デフォルトの名無しさんNGNG
>>590
>買ったはいいが死蔵してる会社って結構多いぞ。

うちもだ (w

Rationalのツールを買って死蔵している会社の人は正直に手を挙げよう。
あ、ちゃんと使いこなしている人の数も知りたいな。
0595デフォルトの名無しさんNGNG
高くて買えないが統一プロセスの好きなやつ。
ラショナル製品を一通りそろえてもらって、
セミナーまで受けたのにさっぱりなやつ。

どっちが真実を現してる?
0596デフォルトの名無しさんNGNG
OO理解出来ないし難しいし挫折したから、役に立たないものだと
思い込みたいんだよね。
わかるよその気持ち。

あまりわかってないうちに、OOに対して役に立たないと
いう早計な判断を下してしまった人も多そうだね。
0597デフォルトの名無しさんNGNG
>>596
ラショナル製品使いこなしてる人発見!

単純に工数が減ったのかどうかと顧客の満足度が知りたい。
0598デフォルトの名無しさんNGNG
設計なんて出来やしないのにRational Rose買いたがってる上司に
IIOSSくれて止めたよ(それだって猫に小判状態)。
そんな金あったら俺の給料あげてくれ。
0599デフォルトの名無しさんNGNG
IIOSSはJavaに特化されて手むかつく。
0600デフォルトの名無しさんNGNG
RUPやOOを信用してない人がこんなにいるのか、ってあるいみ
カルチャーショックですね。もしかしていきなり大きなこと
やろうとして失敗してしまってるんでしょうか。身近な簡単な
ことの積み重ねで、いいのに。日本人の得意なカイゼンでぜんぜん
おっけーですよ。

ワインバーグも、新しいことは必ず失敗するので、新しいことは
一つだけにとどめておくように薦めてますね。それに新しいやり方
というのは、3回目ぐらいにようやく成果がでるくらいの気持ちで
いるのがいいのでは。

あと結局道具じゃないっすよ。人ですね。
UMLだってコミュニケーションの道具に
すぎないんだから。状況に応じて、相手にあわせて、工夫はしないと。

今、3人のチームで仕事してますが、
RoseもVisioもつかってなくて、無印良品のらくがきちょうとホワイトボードが
一番役にたってる。
0601デフォルトの名無しさんNGNG
>>600
反復は実践してる?
0602デフォルトの名無しさんNGNG
>>601
仕事によります。仕様が綺麗に固まってる、固められるものなら長めです。
そうでないときは、2週間ぐらいを1iterationにすることが多いです。
今はお客さんが経費削減、経済状況の変化等々で、どうしても固まらないことが
おおく、1week単位に近くなることもあります。

今は小人数なので、あまり、重いことはしてません。XPに近いです。ペアプロも
してますし。
0603デフォルトの名無しさんNGNG
それはあんまりすごくないよ。
0604デフォルトの名無しさんNGNG
>>603
それより、君のすごい話キボーン
0605590NGNG
なんか言葉足らずだったみたいで誤解してる人がいるようだけど、俺が590で書い
た「死蔵」ってのはOOに挫折って意味じゃなくて、>>600が書いてるみたいに紙や
ホワイトボードを使ったミーティングで十分こなせるような規模の仕事が大多数で
、Rational製品を使うメリットが無いって事。
日本のソフトウェア受発注構造では厳格に管理されたプロセスよりも、仕様変更に
耐えられる機動力の方が要求されてるんだよな。
0606デフォルトの名無しさんNGNG
OOPLで工数が減るかは知らないが。
OOPLで非OOなコーディングをすると
工数が増えることだけは実感した26歳の春。
0607デフォルトの名無しさんNGNG
>>605
というかちゃんと管理できる人間がいない……
0608デフォルトの名無しさんNGNG
クラス宣言の情報 >>>>> UMLの情報 >>>>> UMLから読み取れる情報
UMLの冗長さ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> クラス宣言冗長さ
(オブジェクト指向はクラスベースだけじゃないが)
0609デフォルトの名無しさんNGNG
>>608
そりゃ、実装が一番詳細な情報だからな。

ただ木を見て森を見ずとか、実装の詳細に溺れる可能性も高い。
0610デフォルトの名無しさんNGNG
UMLなんてナニが重要なオブジェクトで、そいつがだれとどうか変わってるか、
そいつを変更するには、誰の了解を得なければいけないかがわかれば十分。

というわけでUMLからコードに落としたり、コードからUMLを生成したりすんのは
バカ。

そんな機能を売りにしてるツールは....
いやもっと、そんなもの買おうとする方が...

0611デフォルトの名無しさんNGNG
UMLのクラス図ってC++やJavaのキーワード、classとは直接の
関係はないんだよね?
0612デフォルトの名無しさんNGNG
>>611
少なくともトレーサビリティは大事だと思うが。
0613デフォルトの名無しさんNGNG
>610
どうい。ツールを売る方は金儲けから製品作ったんだろうが。

コードジェネレータによるコードが冗長で読み難い(←コード書いた人の考えが読み取れないんだよね)
という問題を解決するために、
クラスによる差分プログラミング開発(これがOOPかどうかは別にして)が行われるようになったんだよね。
だから、UMLによるコードジェネレータという考えはなんか外してると思った。
0614デフォルトの名無しさんNGNG
>>611
どのレベルのクラス図か、による。

分析段階で作ってるクラス図だと、動的分類/多重分類あたりまえなので、
C++ や Java のような静的分類/単一分類前提のクラスには一対一には
対応しない。
0615デフォルトの名無しさんNGNG
>>614
とりあえず、メモさせて頂きました。
元ネタはどこからですか?
0616デフォルトの名無しさんNGNG
>>615
UML モデリングのエッセンスとか、アナリシスパターンあたり。
0617デフォルトの名無しさんNGNG
distill本かanalysis本ですね。分かりました。
あまぞんにちゅもんしまう。
0618デフォルトの名無しさんNGNG
>614
最終的に実際にクラスになるものとそのメソッドを考えた方が
簡単ということは無いの?
実装上の問題も無いし。
0619617NGNG
というか同じことどっかで聞いたんだけど、
なに読めばいいのかわすれちったんだよね(w
0620デフォルトの名無しさんNGNG
>>610,>>613
その手の言い切りが、技術の進歩をおくらせるんだよな。
0621デフォルトの名無しさんNGNG
>>620
そうかもな。

だがこのみちで飯を食う以上、最終的に金にならないと判断できたものは
それ以上使わなくても良いだろう。
UMLという記述言語は取り入れるがそれを取り巻くツールを使うかどうかは
全然別問題だしな。

0622デフォルトの名無しさんNGNG
>>618
場合によるな。

経験上、問題領域を素直にモデリングする場合には、動的分類/多重分類を
使った方が楽。どうも、その方が人間が物事を把握するフレームワークに近い
ような気がするんだわ。

じゃあ、常に「分析、設計、実装」レベルでクラス図を三種類作るかというと、そ
うでもない。そもそも図は

 コア部分だけ
 図に書いたほうが理解が深まる部分だけ

書けば十分だから図を書かない場合も多いし、結果的にいきなり設計レベル
図を書いて終わりってこともある。
0623デフォルトの名無しさんNGNG
>>621
>UMLという記述言語は取り入れるがそれを取り巻くツールを使うかどうかは
>全然別問題だしな。

OMGが推進してるMDAについてはどう思う?

0624デフォルトの名無しさんNGNG
まだ評価前
0625デフォルトの名無しさんNGNG
OOは少人数でしか使えん。
大人数でOOプロジェクトをまとめようとすると
宗教と同じで、戒律を作って各PGに守らせるよ
うにしないとだめ。つまり現実的な開発方法と
は言えない。
0626デフォルトの名無しさんNGNG
そして最初に戻る…
0627デフォルトの名無しさんNGNG
OOの話題は シロウトというかクチだけ野郎でも口が出せるからなあ・・・

バランス木とかコルーチンとか実装の話になると黙るのに、そこだけ元気なもんで会議が踊る
0628デフォルトの名無しさんNGNG
>> バランス木とかコルーチンとか実装の話
それ自体OOと関係があるのか?
0629 NGNG
「ソフトウェア部品の再利用は夢なのか? 」
@ITがついにこんなリンクタイトルで記事掲載
http://www.atmarkit.co.jp/fjava/devs/interview01/interview01.html
0630デフォルトの名無しさんNGNG
>>629
このおっさんが言ってるの再利用部品とはコンポーネントのことだね。
0631デフォルトの名無しさんNGNG
>>628
バランス木 ・ オブジェクトをどう管理するのか
コルーチン ・ フィルターのようなオブジェクトをどう実装するか 
0632デフォルトの名無しさんNGNG
つーかさ、OO信者は早く得意のOOを駆使してOS作れや
無理だろうけどな(w
0633デフォルトの名無しさんNGNG
Windowsがそうですが?
0634 NGNG
まとめ
1)オブジェクト指向は失敗した。
  今後は以下OOが失敗した以下の2点を目標にすべきである。

2)生産性の向上
  この点について、Java等の一連のOOPLが失敗した最大の原因は
  ユーザーライブラリを無視し、セミナー屋やマスコミを動員して
  すでにあるソフトウエア資産の破棄に無理やり誘導したことである。

  教訓として、ソフトウエア資産の破棄を迫るような言語は今後は
  一種の詐欺と見なして良い。

2)再利用性
  「まず言語構造・設計構造ありき」などという言語・構造原理主義を捨てて
  再利用性を目標にすべきである。
0635デフォルトの名無しさんNGNG
>>633
WindowsはVisualBasicで作られてます。
0636 NGNG
>>634
コンポーネントってこと?
0637 NGNG
>>636
社内で使える物を作ろうとするとコスト高になるから違うな。
0638デフォルトの名無しさんNGNG
OOPL導入するときって、損益分岐点の見積もりがむつかしー。
0639デフォルトの名無しさんNGNG
どういう理由で?
0640 NGNG
難しくないよ。
導入しても生産性上がらないから、導入コスト分だけ無駄。
従って損益分岐点は存在しない。
0641638NGNG
>>640
あ…
納得。
0642デフォルトの名無しさんNGNG
OOPL使ってるからといってOOしてるわけでもないという理屈なら
OOPL入れたからといって OO しなければならない訳ではない

OOPLは好きだし使うけど OO嫌いな人もいるだろし
0643638NGNG
たとえば、

OOPL使いはじめたとして、ある程度わかってるヤツが解ってる範囲で使うのは、いい。
わかんないヤツが、従来の方法のまま、使うのもいい。
困るのは、解ってないのに、自分はもう極めたような勘違いして暴走しるようなやつ。
そういうやつの足の引っ張り力って、結構強いから、損益分岐点の遠のいていく速度が加速するんだよね。

俺に、そういうやつを説き伏せる力が無いのがいけないんだろうけど、
でも、こういうヤツに限って、周囲からはスゴイって評判だったりするんだ、往々にして。

グチになちたな、マ板逝こう…
0644デフォルトの名無しさんNGNG
コルーチンの話が出てるけど、OOの一つの課題と思ってる事があるんだ。
つまり、メッセージを送るって事は、送ると受けるという2つのオブジェクトがあるという事

例えば、データを入力する機能を持ったオブジェクトの実装では
A)InputDataというメソッドを呼び出して貰う
B)データが出来る都度 PutDataを呼び出す(最終的に外部のオブジェクトが呼ばれる)
という大きく分けて2つの方式があるけど、この2つの方式は切り替えられない。
もちろん、最初から設計してあれば、同期スレッドを使う事で可能だけど、スレッド切替
は比較的重い処理だから現実には選択肢にのぼらない。

当然使う方は Aの方式が楽で 作る方はBの方式が楽。圧縮とかの処理だと圧倒的にAが
難しくなるから、みなついBの方式で実装したがる。

あ長文になりそうだから、結論だけ書くと、
 つまりは、メッセージを送る方式の実装と メッセージを受ける方式の実装が継承により
切替られるような仕掛けが OOPLに必要ではないかという事
0645デフォルトの名無しさんNGNG
長文きぼー
0646デフォルトの名無しさんNGNG
>スレッド切替は比較的重い処理だから現実には選択肢にのぼらない。
んなこたない
スレッド使った場合のオーバーヘッドの
全処理に占める割合をどのくらいに見積もってるんだ?
0647644NGNG
>>645 と言われて 喜んで書いたら叩かれそう

>>646 たとえばストリームのような1バイト単位のデータ送受で単なる
  コルーチン切替ならメモリアクセスに隠れてしまう程度の負荷
  だけど同期スレッドだとそうはいかない。
0648デフォルトの名無しさんNGNG
1バイト単位って・・・
お前fiber使ってみたいだけちゃうんかと(略
1kバッファリングすればオーバーヘッド1024分の1に減るだろ。
リアルタイム圧縮の話をしてるのか?
0649 NGNG
>>646
切り替えは重い。これ常識。
0650デフォルトの名無しさんNGNG
>>649
プロセッサや OS アーキテクチャにもよるけどな。
0651644NGNG
>>648
 そんな・・・・1KByte単位にバッファリングするなら 途中にFIFOオブジェクト経由して
 やればスレッドも不要、だいいちバッファリング出来るような処理なら >>644 分類A
 に書き換えるのもそんな手間じゃないよ
0652デフォルトの名無しさんNGNG
ちょと思いつきで書くのでつっこまれるだろーが

CORBA使ったやつとかだとOO使った大規模ってことにはならないかな?
にたよーなのでOSってわけではないがGNOMEとか
0653デフォルトの名無しさんNGNG
>だけど同期スレッドだとそうはいかない。
話がめちゃくちゃ・・・・
■ このスレッドは過去ログ倉庫に格納されています