トップページ⇒tech
972コメント280KB

【結論】オブジェクト指向は戦場では必要なし 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は近いうちに消えゆく技術となることでしょう。
0237デフォルトの名無しさんNGNG
ttp://www.artlex.net/gonta/jpn/objprog/c1_3.html

>オブジェクト指向設計は、トップダウン方式でもボトムアップ方式でもありません

あれ? こんな事言ってる人もいるよ?
0238デフォルトの名無しさんNGNG
>>236
ん、了解。まずは口火を切ってみようか。

設計とはシステムをある方法で表現したものである。
構造化設計の場合、主にDFDなどでシステムを表現する。
OO設計の場合、主にUMLなどでシステムを表現する。

ここまでで反論どうぞ。
0239デフォルトの名無しさんNGNG
あ、ちなみに反論するときは理由も付けてね。
できれば自分で思っている設計の定義を書いてくれると建設的になる。
0240194NGNG
じゃ自分のソフトウエア設計の定義:
 ,要求される性能,機能に基づいて機構や構造を定める
  これに必要な ツールやライブラリ、そしてスタイルの選定
  人員、工程、などの計画を立てることも含む。

  設計内容は文章や図で示す事もある、口頭で伝える事もある
0241194NGNG
>構造化設計の場合、主にDFDなどでシステムを表現する。
 について、
 DFD:データフロダイアグラムは 分析の時に使う
 構造化設計時には機能面に絞って設計する為に、
 分析時にはデータフローで分析する事がより重要となる為
0242デフォルトの名無しさんNGNG
>>238
UMLつってもいろんな図があるよね。全部設計用と思っていいの?
0243逝って良しの1NGNG
設計つうのは、モノを作る前にやるというタテマエがあって、
でも実際にはモノを作ったあとにやるヤシだろ。
0244デフォルトの名無しさんNGNG
>>243 やれやれ、皮肉いや格好イイとでも思ってるのかねえ
0245デフォルトの名無しさんNGNG
>>244
ま、ほら、そいつはアレだから。
0246デフォルトの名無しさんNGNG
OOが駄目とか言ってる奴はいっぺんxUnit使って開発やってみろ。
目から鱗落ちるぞ。

OO出来ないと駄目とか言ってる奴は「リファクタリング」読んでから自分のソース見直してみろ。
恥ずかしくて穴に入りたくなるぞ。
0247逝って良しの1NGNG
なんだか知らんが俺が天然でとっくの昔に発明してるに決まっている。
0248デフォルトの名無しさんNGNG
とっくに煮詰まってんじゃねえか
sageろやハゲ
0249デフォルトの名無しさんNGNG
>>231
ヴァカ?それとも白痴?
0250デフォルトの名無しさんNGNG
>>242
UMLは記法の総集編みたいなもの。
多くは分析に「も」使うし、設計に「も」使う。
具体的にどの記法を用いるかは、開発方法論によって異なる。
0251デフォルトの名無しさんNGNG
>>237
ユースケースを洗い出してクラス図を描く(改良する)ところはボトムアップ的だし、
クラス図からコラボレーション図で詳細を詰めていくところはトップダウン的なわけで、
OO分析でもOO設計でも、トップダウンとボトムアップを何度も繰り返すのが普通だ。
0252デフォルトの名無しさんNGNG
>>251
で、コーディングに入ってると、不幸を招くプロジェクトに様変わりだ。
0253デフォルトの名無しさんNGNG
>>252
なんか最近分かってきたよ。今までみたいに「天才が設計して莫迦が
コード書く」やり方だと、確かに >>251 までやって「じゃ、あとお前の
仕事ね」でいつまでたっても完成しない & 実装漏れ、仕様誤解だらけ。
UML とか OO とかってのは設計〜開発〜テストまで一人でやる職人プロ
グラマが使うものであって、COBOLER みたいなリーマンプログラマが
使うもんじゃない。
0254デフォルトの名無しさんNGNG
>>253

ハァ?
0255デフォルトの名無しさんNGNG
>>253
「設計が天才でコード書きがバカ」なんていうプロジェクトより、
「設計がなにも出来ない能無しで、コード書きはコードしかかけ
ない」プロジェクトの方が圧倒的に多いな。

下の場合、コード書きは自分の責任を全うしているが、設計者
連中は首にすべきゴミ。
0256デフォルトの名無しさんNGNG
>>253
そう、スキル格差のある開発に導入したところで失敗する。結局、設計の
最初から話に参加していないと、読めない書けない作れないで終わって
しまう。だからコーディングフェーズにだけ派遣を大量確保して力技で
進める様な銀行開発では使えない。

逆に、完全なブラックボックスを一人で作りきれるだけのスキルを持った
連中の間で使うには非常に便利なものだ。自社内開発などは結構こっち
のケースも多いだろう。
0257デフォルトの名無しさんNGNG
>>255
ふーん、じゃ、誰が設計すんの?(藁藁
0258デフォルトの名無しさんNGNG
>>256
つーか、だからこそUMLのUはUnifiedのUなんだよな。
「誰でも」統一された記法を使うことも大事だが、
「どのフェーズでも」統一された記法を使うことはもっと大事。
0259デフォルトの名無しさんNGNG
クラス図作成は分析?設計?
構造化設計でそれに対応するものはなに?
0260デフォルトの名無しさんNGNG
>>259
通常は分析段階からクラス図を描いていって、
シーケンス図やユースケース等といっしょに練っていきます。
ある程度それが練れてきたら、設計にはいります。
設計でもクラス図を改良/詳細化していきますが、
分析段階と違って、コンポーネントやパッケージを意識し、
コラボレーション図などによってクラス図の構造や振舞いを検証し、改良していきます。

もちろん、主に使う図の種類や描く順番や評価方法など、
それぞれの方法論によって異なります。
UMLはあくまで記法にすぎないので。
0261デフォルトの名無しさんNGNG
ところで、>>252は>>251のどこを見て「不幸を招くプロジェクト」になると思ったのだろうか?
OOや構造化手法に限らず、設計の方法論の大抵はトップダウンとボトムアップをすると思うのだが。
0262デフォルトの名無しさんNGNG
>完全なブラックボックスを一人で作りきれるだけのスキルを持った連中

は、 C++ より Cが好き そしてアセンブラが好き
0263デフォルトの名無しさんNGNG
>>262
そんなことはない。
0264デフォルトの名無しさんNGNG
>>262
俺は丁度逆だ。
システム依存なんていやんな感じだもん。
0265逝って良しの1NGNG
C,アセンブラだってシステム依存無しに書けるよ。
つうか非依存で書けやゴルア。
0266デフォルトの名無しさんNGNG
>>265
ども、素人です。
アセンブラでもそんなことできるの?
0267デフォルトの名無しさんNGNG
>>266
アフォの相手はアフォの片棒をかつぐことになります
0268デフォルトの名無しさんNGNG
>>267
了解。一つお利口になりました。
0269デフォルトの名無しさんNGNG
>>266 マクロアセンブラを使って、ニーモニックの違いを吸収させるとかね
0270デフォルトの名無しさんNGNG
>>269
8080とSPARCに同じアセンブリソースからアセンブルできるのかよ。
ついでに68030と8086の場合はどうだ?
0271デフォルトの名無しさんNGNG
>>270 その例だと C でも可搬性のあるコードは一部しか書けない

それでも C程度には可能だよ
0272デフォルトの名無しさんNGNG
>>271
アセンブリ言語である以上、機械語と1対1対応してないとアセンブリとは呼べないと思いますが、
それでも可搬性のあるコードが書けるのですか?例えば、8080と8086ではどうでしょう?
エンディアンが同じなので、可搬性のあるC処理系を実装することは可能ですが、
可搬性のあるアセンブラは存在可能ですか?
0273デフォルトの名無しさんNGNG
>>272 だからマクロASM なら可能

それから機械語と1対1対応してないアセンブラなんて沢山あるよ
論理左シフトと算術左シフトは同じバイナリになるとかさ
0274逝って良しの1NGNG
>>270
Z80→68000
Z80→286
ならやった。
>>272
仮想マシンコードでやるのだ。
0275デフォルトの名無しさんNGNG
だから Cの出始めはマクロアセンブラのライブラリを抱え込んでた所は
 Cよりこっちが可搬性もある上、記述の柔軟性は高く、しかも効率もいい のに何でC? と思ってたんだよ
0276デフォルトの名無しさんNGNG
>>265
C はともかく、アセンブラで書くところは
普通システム依存するところだとおもうが・・・
0277デフォルトの名無しさんNGNG
>>273
8080と8086でか?そりゃすげーな。
それでちゃんと8086のセグメントレジスタとか使えるのか?(藁
0278デフォルトの名無しさんNGNG
>>273
まあ、そういう例外的なニーモニックがあるものも結構ありますね。
でも原則的にはアセンブリと機械語は1対1の関係ですよね。
というか、アセンブリ言語は機械語の別記法として定義されるものですよね。

>>274
誰が移植の話をしたんだよ。
同一ソースコードからそれぞれの機械語を生成するアセンブラおよび共通アセンブリ言語を定義できるかって話なんだよ。
0279デフォルトの名無しさんNGNG
な ん だ か ん だ 言 っ て も 
O O は 消 え る 運 命 に あ り ま す 。
0280デフォルトの名無しさんNGNG
>>279
いや、ただの煽りでは説得力がないんですが。
0281デフォルトの名無しさんNGNG
>>280
雑誌の海運財布のCMみたいなもんな。マジレスすんな。
0282デフォルトの名無しさんNGNG
Brew ってどうよ? 誰か使ってる?
0283デフォルトの名無しさんNGNG
俺OOバリバリに使って開発してるけど、
OOのおかげですごく開発が楽にナターヨ。
OOは仕様変更にも強いし、
開発期間も短縮できたよ。
これからはOOで開発が一番だね。
0284デフォルトの名無しさんNGNG
>>283
お前は本当にOOが一番だと思っているのか
それともアンチが餌まいてるのか?
後者なら氏ね。前者でも氏ね。
0285デフォルトの名無しさんNGNG
>>284
取りあえずBASIC程度は書けるようになってから物言ってくれ。
0286284NGNG
>>285
BASICは書けるから問題ないな。
0287デフォルトの名無しさんNGNG
OOはやっぱ開発効率一番だね!
0288デフォルトの名無しさんNGNG
>>287
正気か?
あるものを再利用するなら効果的だが
無いものを作るのは面倒だ。
0289デフォルトの名無しさんNGNG
>>288
必ずともそうとはいえない。
インスタンスが複数あるものはOOの方が便利。
0290デフォルトの名無しさんNGNG
結局OOの利点ってなんだ?
実際に開発効率いいのか?
習得しやすいのか?
後のPGの引継ぎがスムースにできるのか?
仕様変更に柔軟なのか?
複数人での共同開発がしやすいか?
コストが抑えられるのか?
0291デフォルトの名無しさんNGNG
>>290
OOもそうだが構造化についても同じ疑問があるな。
実際に開発効率いいのか?
習得しやすいのか?
後のPGの引継ぎがスムースにできるのか?
仕様変更に柔軟なのか?
複数人での共同開発がしやすいか?
コストが抑えられるのか?
0292デフォルトの名無しさんNGNG
>>290
まず、非OOでそれらが達成できていると言うことを証明してくれ。
0293デフォルトの名無しさんNGNG
>>292
じゃ、OOは?
0294デフォルトの名無しさんNGNG
>>293
「いやいや、後手の方が有利だからさ。」

仕掛けてくると言うことはよっぽど自信があるんだろう。
それくらいハンデくださいよ。畑山さん。

そう言うファイトクラブ生達。
0295デフォルトの名無しさんNGNG
たとえどっちでも大差ないって結論になっても、
どっちでもいいなら構造化でいいじゃんって結論はやめてね。
どっちでもいい かつ 構造化が自分の周りで普及しているから構造化がいい ならいいけど。
0296梅宮NGNG
結論から書くとOOでも
たいしたことないっすね。
0297デフォルトの名無しさんNGNG
>>295
その場合の結論は好きな方を使え。が正常だろう。
0298デフォルトの名無しさんNGNG
>たとえどっちでも大差ないって結論になっても、
>どっちでもいいなら構造化でいいじゃんって結論はやめてね。
じゃあ構造化に比べてOOを導入する利点ってなんだよ。
PGオタの最後の砦ってか?(w
0299デフォルトの名無しさんNGNG
インスタンスを複数作る場合には 構造化でも クラス的なものを作る事になってしまう
 他の方法は別のプロセスを作るくらいしかないんだけど、それはコストが大きすごるから
0300130NGNG
すべてをクラスにするというのは設計のこと。

C++のようなハイブリッド言語ならすべてをクラスにする必要はないし
GtkのようにC言語でオブジェクト指向設計をすることもできる。

オブジェクト指向設計とはオブジェクトそのものをイメージし
それを(クラスベースの言語であれば)クラスとして定義することをいう。

よくあるおかしな設計は
構造体を定義して関数を構造体の中に入れるというもの。
この方法はソース上ではデータと機能がカプセル化されているかもしれないが
頭の中ではデータと機能がバラバラになっている。

OOマンセーは頭の中でオブジェクトそのものをイメージできる。

>>153
デザバタ・レベルの抽象化を非OOPLでやるともっと冗長になる。
あと、どうでもいいことだけど
C++のTemplateとデザパタのTemplate Methodは関係ない。
0301デフォルトの名無しさんNGNG
              OO   構造化
理解しやすさ        ×    ○
設計の大切さ        ◎    ○
わかっている人が作ったときの
開発効率          ○    ◎
仕様変更への強さ      ◎    ○
わかっていない人が作ったときの
開発効率          ×    ◎
仕様変更への強さ      ×    ◎

結論、
わかっている人が作ると OO の方が効率がよく、
わかっていない人が作ると構造化の方が効率がよい。

しかも、理解のしやすさは 構造化の方が容易なのでへたれプログラマーには
構造化がお似合い。
0302デフォルトの名無しさんNGNG
>>301
書き直し。
0303デフォルトの名無しさんNGNG
>>302
書き直し
0304デフォルトの名無しさんNGNG
OOは構造化を含んでるってのは正しいの?
0305デフォルトの名無しさんNGNG
>>304
クラスを構造と言ってしまえば正しいでしょう。
0306デフォルトの名無しさんNGNG
>>304
>OOは構造化を含んでるってのは正しいの?

正しい。
構造化で脳みそが硬直してる奴にJAVAなんかをやらせると一つのクラスの中に
全てを押し込んで作りやがる。
「こうしないとグローバル変数作れなかったんですよ。」
「氏ね。」
0307デフォルトの名無しさんNGNG
>>306
 その設計は構造化してないような・・・
 OO言語を使っていてもOOしてないのと同じく
 構造化言語を使っていても構造化してない奴は大勢いる
0308デフォルトの名無しさんNGNG
>>307
構造化プログラミングと構造化分析/設計は別物だと思ふ。
0309デフォルトの名無しさんNGNG
オブジェクト指向プログラミングと オブジェクト指向設計も別物で

後者は不要
0310デフォルトの名無しさんNGNG
>>309
いや、オブジェクト指向分析/設計のオブジェクトは、
オブジェクト指向プログラミングでのオブジェクトと概念的には同じもの。
一方、構造化分析/設計のいう「構造化」と
構造化プログラミングのいう「構造化」は別物。
0311デフォルトの名無しさんNGNG
>>310
 どう別物なのか説明しなくちゃ 

  構造化プログラミングの構造化はダイクストラの 全てのプログラムは以下の構造に分類出来る の構造の事
  構造化設計の構造は、その構造化プログラミングにどう落とすか それはトップダウンとボトムアップだ という事で
  「構造化プログラミングに適した設計」 を略したもの


じゃこう言い換えよう

オブジェクト指向プログラミング言語は有用だが  オブジェクト指向プログラミングは不要

0312デフォルトの名無しさんNGNG
「オブジェクト指向プログラミング言語は有用だが  オブジェクト指向プログラミングは不要 」

やっと結論が出てきたという感じだな
OOを一生懸命勉強した人、お気の毒に。
0313デフォルトの名無しさんNGNG
>>312
自作自演ご苦労。
0314デフォルトの名無しさんNGNG
オブジェクト指向言語の持っている機能は 便利だし、使いこなせるようになると非常に有用
教養として知っていて、手法の一つとして利用すれば十分に役立つのも確かだ。

しかし、設計の場にオブジェクト指向を持ち出す輩は、「指向」しようとする
それは、イランのよ テンプレート覚えて自作の文字列クラス作って使わせようとする輩と同じくらい迷惑なのよ
0315デフォルトの名無しさんNGNG
>>314
/*
しかし、設計の場にオブジェクト指向を持ち出す輩は、「指向」しようとする
それは、イランのよ テンプレート覚えて自作の文字列クラス作って使わせようとする輩と同じくらい迷惑なのよ

クソ自作文字列クラス−>仕様知らない−>理解しなければいけない−>面倒くさい−>しんどい−>イラン
OO−>理解できない−>理解しなければいけない−>面倒くさい−>しんどい−>イラン

0316デフォルトの名無しさんNGNG
他人−>理解できない−>理解しなければいけない−>面倒くさい−>しんどい−>イラン
0317デフォルトの名無しさんNGNG
>>316
だから自作自演したんですか?
0318デフォルトの名無しさんNGNG
ボトムアップとかトップダウンってどういうことよ。
って知ってるけど教えてくれ。それが構造化設計とどのように関係するのか。
0319デフォルトの名無しさんNGNG
そっかOOってダメなんだ・・・(´・ω・`)
0320デフォルトの名無しさんNGNG
>>318
ボトムアップ:
関数なりクラスなり作りまくってそれを組み合わせて完成。

トップダウン:
おおざっぱにmainを書いてそれにどんどん肉を付けていく。
0321デフォルトの名無しさんNGNG
そっか人間ってダメなんだ・・・(´・ω・`)
0322デフォルトの名無しさんNGNG
>>318
ボトムアップ:
よりシステムに密着した実装をしやすいが、設計物自体が無駄になることも

トップダウン:
いるものを必要になってから作るから無駄はでないが、鬼のような性能はのぞめないかも
0323デフォルトの名無しさんNGNG
OO導入してSE/PGが糞の場合コストが高くなりそう。
また仕様変更があるといくら優れたPGでも
最初からクラス設計しなおさないとあかんしな。
0324デフォルトの名無しさんNGNG
>>311
構造化プロラミングはその通りだが、構造化設計に関しては全然違うだろ。
構造化分析/設計における構造化は構造化プログラミング言語で実装しやすくするためのものではなく、
あくまでシステムの要件から機能を分解していき、また、機能の合成をすることでシステムの機能や構成をモジュール化していくもの。
実装をどのような言語でやるかとは全然関係ない。
0325デフォルトの名無しさんNGNG
>>323
仕様変更があるといつでもクラス設計しなおさなければならないって言い方だな。
クラス設計しなおさなければならないくらい仕様が変更されても
構造化なら設計しなおさなくてもいいと?
0326デフォルトの名無しさんNGNG
>>324 それは結果論で
 歴史的には、 プログラミングについては構造化プログラミングが出て改善された、しかし設計手法をどうしようと
 という事で生まれたもの。

 そうじゃないというなら、 その構造化設計の 「構造化」 の由来を説明してみてよ
0327デフォルトの名無しさんNGNG
>>323
なぜ最初からやりなおし?普通に見直すだけだろ?
0328デフォルトの名無しさんNGNG
ちょっと>>324の言葉を借りて。

システムの要件からオブジェクトを分解していき、また、オブジェクトの合成をすることでシステムのオブジェクトや構成をモジュール化していくもの。

こうすると、構造化分析/設計のことオブジェクト指向分析/設計のこと、それとも意味不明な文章?
0329328NGNG
モジュール化じゃなくてコンポーネント化とした方がいいかな。
0330デフォルトの名無しさんNGNG
オブジェクト指向設計も同じだな OOが先に出来て、後から追いかけてきた
0331デフォルトの名無しさんNGNG
>>326
プログラミング言語の構造化は、制御構造を構成的に定義したもの。
分析/設計の構造化は機能分解と機能合成であり、それは機能を中心にした還元主義といってもいい。

別の言い方をしよう。
プログラミング言語の構造化は、構造化がゴールではない。あくまで安全な制御構造の構成が目的。
一方、構造化分析/設計の構造化は、機能を構造化し表現することがゴール。
0332デフォルトの名無しさんNGNG
>>330
それを言うのなら、プログラミングが先に出来て、システム分析/設計は後から追いかけてきた。
0333デフォルトの名無しさんNGNG
>>332 じゃまあ その下らない議論は そのせんで軟着陸させましょう

では本題に戻って 結局オブジェクト指向は
指向・志向がイカンのじゃないの?
そんな所に拘るなよってカンジ
0334デフォルトの名無しさんNGNG
構造化分析/設計の機能が、具体的にどのようなものか。
データはどうなるのか、オブジェクト指向だとそれがどのように
変化するのか気になるな。
0335デフォルトの名無しさんNGNG
>>328
違います。
オブジェクトの分解や合成は、あくまでオブジェクトを見直す時に用いる操作であって、
それ自体が設計の中心になるわけではない。

構造化設計では機能の分解や合成が中心的活動なのとは対照的。
0336デフォルトの名無しさんNGNG
構造化分析 --> データとデータの流れに注目
構造化設計 --> 主に機能に注目
■ このスレッドは過去ログ倉庫に格納されています