【結論】オブジェクト指向は戦場では必要なし 5
■ このスレッドは過去ログ倉庫に格納されています
0001あたたたた
NGNGを理解する労力が大きく、目的まで達成するのに時間がかかる。
他人のソースを見るにも複雑でときほぐしにくい。
ちゃんと整備されたドキュメントがなければ粗大ゴミソース。
またオブジェクト指向が○○に優れているとかいう話も、あくまでちゃ
んと設計され、ちゃんと実装されたクラスがあるという前提での話。
実際は世の中にどれだけの糞SEや糞PGがいることか。。。
よってオブジェクト指向は戦場では使いものになりません。
前前前前スレ http://pc.2ch.net/test/read.cgi/tech/1011997945/
前前前スレ http://pc.2ch.net/test/read.cgi/tech/1013266554/
前前スレhttp://pc.2ch.net/test/read.cgi/tech/1013875413/
前スレhttp://pc3.2ch.net/test/read.cgi/tech/1021468476/
私の独自の調査においては、OOで開発すると効率が悪く
バグコードが侵入しやすい傾向があるという調査結果が出ています。
また実際の現場での有効性に疑問をもっているという人は
全体の75.3％にも達しました。移行のことからOOはその有効性
に疑問があると言わざるをえません。
OOは近いうちに消えゆく技術となることでしょう。
0232194
NGNGだから 戦場では必要ないなんて言われるのさ。
0233デフォルトの名無しさん
NGNG0234デフォルトの名無しさん
NGNGあなたの周りの人間は、コミュニケーションに苦労していることでしょう。
0235デフォルトの名無しさん
NGNG> 設計の意味することがみんなばらばらだから
じゃあ、「設計」って何？
0236デフォルトの名無しさん
NGNG君の思っている設計を書いてみ。いろいろ反論されるから。
0237デフォルトの名無しさん
NGNG>オブジェクト指向設計は、トップダウン方式でもボトムアップ方式でもありません
あれ？ こんな事言ってる人もいるよ？
0238デフォルトの名無しさん
NGNGん、了解。まずは口火を切ってみようか。
設計とはシステムをある方法で表現したものである。
構造化設計の場合、主にDFDなどでシステムを表現する。
OO設計の場合、主にUMLなどでシステムを表現する。
ここまでで反論どうぞ。
0239デフォルトの名無しさん
NGNGできれば自分で思っている設計の定義を書いてくれると建設的になる。
0240194
NGNG,要求される性能,機能に基づいて機構や構造を定める
これに必要な ツールやライブラリ、そしてスタイルの選定
人員、工程、などの計画を立てることも含む。
設計内容は文章や図で示す事もある、口頭で伝える事もある
0241194
NGNGについて、
DFD:データフロダイアグラムは 分析の時に使う
構造化設計時には機能面に絞って設計する為に、
分析時にはデータフローで分析する事がより重要となる為
0242デフォルトの名無しさん
NGNGUMLつってもいろんな図があるよね。全部設計用と思っていいの？
0243逝って良しの１
NGNGでも実際にはモノを作ったあとにやるヤシだろ。
0244デフォルトの名無しさん
NGNG0245デフォルトの名無しさん
NGNGま、ほら、そいつはアレだから。
0246デフォルトの名無しさん
NGNG目から鱗落ちるぞ。
OO出来ないと駄目とか言ってる奴は「リファクタリング」読んでから自分のソース見直してみろ。
恥ずかしくて穴に入りたくなるぞ。
0247逝って良しの１
NGNG0248デフォルトの名無しさん
NGNGsageろやハゲ
0249デフォルトの名無しさん
NGNGヴァカ？それとも白痴？
0250デフォルトの名無しさん
NGNGUMLは記法の総集編みたいなもの。
多くは分析に「も」使うし、設計に「も」使う。
具体的にどの記法を用いるかは、開発方法論によって異なる。
0251デフォルトの名無しさん
NGNGユースケースを洗い出してクラス図を描く(改良する)ところはボトムアップ的だし、
クラス図からコラボレーション図で詳細を詰めていくところはトップダウン的なわけで、
OO分析でもOO設計でも、トップダウンとボトムアップを何度も繰り返すのが普通だ。
0252デフォルトの名無しさん
NGNGで、コーディングに入ってると、不幸を招くプロジェクトに様変わりだ。
0253デフォルトの名無しさん
NGNGなんか最近分かってきたよ。今までみたいに「天才が設計して莫迦が
コード書く」やり方だと、確かに >>251 までやって「じゃ、あとお前の
仕事ね」でいつまでたっても完成しない & 実装漏れ、仕様誤解だらけ。
UML とか OO とかってのは設計〜開発〜テストまで一人でやる職人プロ
グラマが使うものであって、COBOLER みたいなリーマンプログラマが
使うもんじゃない。
0254デフォルトの名無しさん
NGNGハァ？
0255デフォルトの名無しさん
NGNG「設計が天才でコード書きがバカ」なんていうプロジェクトより、
「設計がなにも出来ない能無しで、コード書きはコードしかかけ
ない」プロジェクトの方が圧倒的に多いな。
下の場合、コード書きは自分の責任を全うしているが、設計者
連中は首にすべきゴミ。
0256デフォルトの名無しさん
NGNGそう、スキル格差のある開発に導入したところで失敗する。結局、設計の
最初から話に参加していないと、読めない書けない作れないで終わって
しまう。だからコーディングフェーズにだけ派遣を大量確保して力技で
進める様な銀行開発では使えない。
逆に、完全なブラックボックスを一人で作りきれるだけのスキルを持った
連中の間で使うには非常に便利なものだ。自社内開発などは結構こっち
のケースも多いだろう。
0257デフォルトの名無しさん
NGNGふーん、じゃ、誰が設計すんの？(藁藁
0258デフォルトの名無しさん
NGNGつーか、だからこそUMLのUはUnifiedのUなんだよな。
「誰でも」統一された記法を使うことも大事だが、
「どのフェーズでも」統一された記法を使うことはもっと大事。
0259デフォルトの名無しさん
NGNG構造化設計でそれに対応するものはなに？
0260デフォルトの名無しさん
NGNG通常は分析段階からクラス図を描いていって、
シーケンス図やユースケース等といっしょに練っていきます。
ある程度それが練れてきたら、設計にはいります。
設計でもクラス図を改良/詳細化していきますが、
分析段階と違って、コンポーネントやパッケージを意識し、
コラボレーション図などによってクラス図の構造や振舞いを検証し、改良していきます。
もちろん、主に使う図の種類や描く順番や評価方法など、
それぞれの方法論によって異なります。
UMLはあくまで記法にすぎないので。
0261デフォルトの名無しさん
NGNGOOや構造化手法に限らず、設計の方法論の大抵はトップダウンとボトムアップをすると思うのだが。
0262デフォルトの名無しさん
NGNGは、 C++ より Cが好き そしてアセンブラが好き
0263デフォルトの名無しさん
NGNGそんなことはない。
0264デフォルトの名無しさん
NGNG俺は丁度逆だ。
システム依存なんていやんな感じだもん。
0265逝って良しの１
NGNGつうか非依存で書けやｺﾞﾙｱ。
0266デフォルトの名無しさん
NGNGども、素人です。
アセンブラでもそんなことできるの？
0267デフォルトの名無しさん
NGNGアフォの相手はアフォの片棒をかつぐことになります
0268デフォルトの名無しさん
NGNG了解。一つお利口になりました。
0269デフォルトの名無しさん
NGNG0270デフォルトの名無しさん
NGNG8080とSPARCに同じアセンブリソースからアセンブルできるのかよ。
ついでに68030と8086の場合はどうだ？
0271デフォルトの名無しさん
NGNGそれでも C程度には可能だよ
0272デフォルトの名無しさん
NGNGアセンブリ言語である以上、機械語と1対1対応してないとアセンブリとは呼べないと思いますが、
それでも可搬性のあるコードが書けるのですか？例えば、8080と8086ではどうでしょう？
エンディアンが同じなので、可搬性のあるC処理系を実装することは可能ですが、
可搬性のあるアセンブラは存在可能ですか？
0273デフォルトの名無しさん
NGNGそれから機械語と1対１対応してないアセンブラなんて沢山あるよ
論理左シフトと算術左シフトは同じバイナリになるとかさ
0275デフォルトの名無しさん
NGNGCよりこっちが可搬性もある上、記述の柔軟性は高く、しかも効率もいい のに何でC? と思ってたんだよ
0276デフォルトの名無しさん
NGNGC はともかく、アセンブラで書くところは
普通システム依存するところだとおもうが・・・
0277デフォルトの名無しさん
NGNG8080と8086でか？そりゃすげーな。
それでちゃんと8086のセグメントレジスタとか使えるのか？(藁
0278デフォルトの名無しさん
NGNGまあ、そういう例外的なニーモニックがあるものも結構ありますね。
でも原則的にはアセンブリと機械語は1対1の関係ですよね。
というか、アセンブリ言語は機械語の別記法として定義されるものですよね。
>>274
誰が移植の話をしたんだよ。
同一ソースコードからそれぞれの機械語を生成するアセンブラおよび共通アセンブリ言語を定義できるかって話なんだよ。
0279デフォルトの名無しさん
NGNGO O は 消 え る 運 命 に あ り ま す 。
0280デフォルトの名無しさん
NGNGいや、ただの煽りでは説得力がないんですが。
0281デフォルトの名無しさん
NGNG雑誌の海運財布のCMみたいなもんな。マジレスすんな。
0282デフォルトの名無しさん
NGNG0283デフォルトの名無しさん
NGNGOOのおかげですごく開発が楽にﾅﾀｰﾖ。
OOは仕様変更にも強いし、
開発期間も短縮できたよ。
これからはOOで開発が一番だね。
0284デフォルトの名無しさん
NGNGお前は本当にOOが一番だと思っているのか
それともアンチが餌まいてるのか？
後者なら氏ね。前者でも氏ね。
0285デフォルトの名無しさん
NGNG取りあえずBASIC程度は書けるようになってから物言ってくれ。
0287デフォルトの名無しさん
NGNG0288デフォルトの名無しさん
NGNG正気か？
あるものを再利用するなら効果的だが
無いものを作るのは面倒だ。
0289デフォルトの名無しさん
NGNG必ずともそうとはいえない。
インスタンスが複数あるものはOOの方が便利。
0290デフォルトの名無しさん
NGNG実際に開発効率いいのか？
習得しやすいのか？
後のPGの引継ぎがスムースにできるのか？
仕様変更に柔軟なのか？
複数人での共同開発がしやすいか？
コストが抑えられるのか？
0291デフォルトの名無しさん
NGNGOOもそうだが構造化についても同じ疑問があるな。
実際に開発効率いいのか？
習得しやすいのか？
後のPGの引継ぎがスムースにできるのか？
仕様変更に柔軟なのか？
複数人での共同開発がしやすいか？
コストが抑えられるのか？
0292デフォルトの名無しさん
NGNGまず、非OOでそれらが達成できていると言うことを証明してくれ。
0293デフォルトの名無しさん
NGNGじゃ、OOは？
0294デフォルトの名無しさん
NGNG「いやいや、後手の方が有利だからさ。」
仕掛けてくると言うことはよっぽど自信があるんだろう。
それくらいハンデくださいよ。畑山さん。
そう言うファイトクラブ生達。
0295デフォルトの名無しさん
NGNGどっちでもいいなら構造化でいいじゃんって結論はやめてね。
どっちでもいい かつ 構造化が自分の周りで普及しているから構造化がいい ならいいけど。
0296梅宮
NGNGたいしたことないっすね。
0297デフォルトの名無しさん
NGNGその場合の結論は好きな方を使え。が正常だろう。
0298デフォルトの名無しさん
NGNG>どっちでもいいなら構造化でいいじゃんって結論はやめてね。
じゃあ構造化に比べてOOを導入する利点ってなんだよ。
PGオタの最後の砦ってか？（ｗ
0299デフォルトの名無しさん
NGNG他の方法は別のプロセスを作るくらいしかないんだけど、それはコストが大きすごるから
0300130
NGNGC++のようなハイブリッド言語ならすべてをクラスにする必要はないし
GtkのようにC言語でオブジェクト指向設計をすることもできる。
オブジェクト指向設計とはオブジェクトそのものをイメージし
それを（クラスベースの言語であれば）クラスとして定義することをいう。
よくあるおかしな設計は
構造体を定義して関数を構造体の中に入れるというもの。
この方法はソース上ではデータと機能がカプセル化されているかもしれないが
頭の中ではデータと機能がバラバラになっている。
OOマンセーは頭の中でオブジェクトそのものをイメージできる。
>>153
デザバタ・レベルの抽象化を非OOPLでやるともっと冗長になる。
あと、どうでもいいことだけど
C++のTemplateとデザパタのTemplate Methodは関係ない。
0301デフォルトの名無しさん
NGNG理解しやすさ × ○
設計の大切さ ◎ ○
わかっている人が作ったときの
開発効率 ○ ◎
仕様変更への強さ ◎ ○
わかっていない人が作ったときの
開発効率 × ◎
仕様変更への強さ × ◎
結論、
わかっている人が作ると OO の方が効率がよく、
わかっていない人が作ると構造化の方が効率がよい。
しかも、理解のしやすさは 構造化の方が容易なのでへたれプログラマーには
構造化がお似合い。
0302デフォルトの名無しさん
NGNG書き直し。
0303デフォルトの名無しさん
NGNG書き直し
0304デフォルトの名無しさん
NGNG0305デフォルトの名無しさん
NGNGクラスを構造と言ってしまえば正しいでしょう。
0306デフォルトの名無しさん
NGNG>OOは構造化を含んでるってのは正しいの？
正しい。
構造化で脳みそが硬直してる奴にJAVAなんかをやらせると一つのクラスの中に
全てを押し込んで作りやがる。
「こうしないとグローバル変数作れなかったんですよ。」
「氏ね。」
0307デフォルトの名無しさん
NGNGその設計は構造化してないような・・・
OO言語を使っていてもOOしてないのと同じく
構造化言語を使っていても構造化してない奴は大勢いる
0308デフォルトの名無しさん
NGNG構造化プログラミングと構造化分析/設計は別物だと思ふ。
0309デフォルトの名無しさん
NGNG後者は不要
0310デフォルトの名無しさん
NGNGいや、オブジェクト指向分析/設計のオブジェクトは、
オブジェクト指向プログラミングでのオブジェクトと概念的には同じもの。
一方、構造化分析/設計のいう「構造化」と
構造化プログラミングのいう「構造化」は別物。
0311デフォルトの名無しさん
NGNGどう別物なのか説明しなくちゃ
構造化プログラミングの構造化はダイクストラの 全てのプログラムは以下の構造に分類出来る の構造の事
構造化設計の構造は、その構造化プログラミングにどう落とすか それはトップダウンとボトムアップだ という事で
「構造化プログラミングに適した設計」 を略したもの
じゃこう言い換えよう
オブジェクト指向プログラミング言語は有用だが オブジェクト指向プログラミングは不要
0312デフォルトの名無しさん
NGNGやっと結論が出てきたという感じだな
OOを一生懸命勉強した人、お気の毒に。
0313デフォルトの名無しさん
NGNG自作自演ご苦労。
0314デフォルトの名無しさん
NGNG教養として知っていて、手法の一つとして利用すれば十分に役立つのも確かだ。
しかし、設計の場にオブジェクト指向を持ち出す輩は、「指向」しようとする
それは、イランのよ テンプレート覚えて自作の文字列クラス作って使わせようとする輩と同じくらい迷惑なのよ
0315デフォルトの名無しさん
NGNG／＊
しかし、設計の場にオブジェクト指向を持ち出す輩は、「指向」しようとする
それは、イランのよ テンプレート覚えて自作の文字列クラス作って使わせようとする輩と同じくらい迷惑なのよ
クソ自作文字列クラス−＞仕様知らない−＞理解しなければいけない−＞面倒くさい−＞しんどい−＞イラン
OO−＞理解できない−＞理解しなければいけない−＞面倒くさい−＞しんどい−＞イラン
0316デフォルトの名無しさん
NGNG0317デフォルトの名無しさん
NGNGだから自作自演したんですか？
0318デフォルトの名無しさん
NGNGって知ってるけど教えてくれ。それが構造化設計とどのように関係するのか。
0319デフォルトの名無しさん
NGNG0320デフォルトの名無しさん
NGNGボトムアップ：
関数なりクラスなり作りまくってそれを組み合わせて完成。
トップダウン：
おおざっぱにmainを書いてそれにどんどん肉を付けていく。
0321デフォルトの名無しさん
NGNG0322デフォルトの名無しさん
NGNGボトムアップ：
よりシステムに密着した実装をしやすいが、設計物自体が無駄になることも
トップダウン：
いるものを必要になってから作るから無駄はでないが、鬼のような性能はのぞめないかも
0323デフォルトの名無しさん
NGNGまた仕様変更があるといくら優れたPGでも
最初からクラス設計しなおさないとあかんしな。
0324デフォルトの名無しさん
NGNG構造化プロラミングはその通りだが、構造化設計に関しては全然違うだろ。
構造化分析/設計における構造化は構造化プログラミング言語で実装しやすくするためのものではなく、
あくまでシステムの要件から機能を分解していき、また、機能の合成をすることでシステムの機能や構成をモジュール化していくもの。
実装をどのような言語でやるかとは全然関係ない。
0325デフォルトの名無しさん
NGNG仕様変更があるといつでもクラス設計しなおさなければならないって言い方だな。
クラス設計しなおさなければならないくらい仕様が変更されても
構造化なら設計しなおさなくてもいいと？
0326デフォルトの名無しさん
NGNG歴史的には、 プログラミングについては構造化プログラミングが出て改善された、しかし設計手法をどうしようと
という事で生まれたもの。
そうじゃないというなら、 その構造化設計の 「構造化」 の由来を説明してみてよ
0327デフォルトの名無しさん
NGNGなぜ最初からやりなおし？普通に見直すだけだろ？
0328デフォルトの名無しさん
NGNGシステムの要件からオブジェクトを分解していき、また、オブジェクトの合成をすることでシステムのオブジェクトや構成をモジュール化していくもの。
こうすると、構造化分析/設計のことオブジェクト指向分析/設計のこと、それとも意味不明な文章？
0329328
NGNG0330デフォルトの名無しさん
NGNG0331デフォルトの名無しさん
NGNGプログラミング言語の構造化は、制御構造を構成的に定義したもの。
分析/設計の構造化は機能分解と機能合成であり、それは機能を中心にした還元主義といってもいい。
別の言い方をしよう。
プログラミング言語の構造化は、構造化がゴールではない。あくまで安全な制御構造の構成が目的。
一方、構造化分析/設計の構造化は、機能を構造化し表現することがゴール。
■ このスレッドは過去ログ倉庫に格納されています