【結論】オブジェクト指向は戦場では必要なし 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は近いうちに消えゆく技術となることでしょう。
0002逝って良しの１
NGNG0003デフォルトの名無しさん
NGNGOOﾏﾝｾｰ
0004デフォルトの名無しさん
NGNGつか、ちゃんとラジオ体操には行って来たか?
宿題は涼しい午前中にやっとけよ。
0005デフォルトの名無しさん
NGNG第2の途中でふけた。
0006デフォルトの名無しさん
NGNGラジオ体操は数十年前から全く進化しないのはいかがなものか？
0007デフォルトの名無しさん
NGNG0008逝って良しの１
NGNG下手にいじると故障や病気になる人が出てきます。
0009逝って良しの１
NGNG創れない。
素人がＯＯＰＬ使えたからと言って出来るようになるものではない。
0010デフォルトの名無しさん
NGNG自分の手でゼロから書き直すはめになった経験がなんどもある。
0011デフォルトの名無しさん
NGNGDelphiでコンポーネントとか自作して当然再利用してるが、
自分ではオブジェクト指向してるとは思わない。
あくまでもOO言語を便利に使っているだけ
OO言語の機能は便利で使うが、オブジェクト指向はキライ
0012デフォルトの名無しさん
NGNGバカがプロジェクトを戦場にしてるんだ。
それどころか凝集度・結合度すら理解していない奴ら。
ローカル変数や関数すら分からない奴ら。
ろくな設計をしなかったために、テスト段階になって火が噴いて
挙げ句の果てに「やっぱり設計に時間をかけられない」なんて逝ってる奴ら。
0013デフォルトの名無しさん
NGNG0014デフォルトの名無しさん
NGNG約 200 レスごとに 1 イテレーションです。
0015デフォルトの名無しさん
NGNG0016デフォルトの名無しさん
NGNG0017デフォルトの名無しさん
NGNGそれがいいんだよねー。
で、みようみまねでBuilderパターン適用して作っちゃうとか。
こんなカスなことができるオブジェクト指向が大好き！
0018デフォルトの名無しさん
NGNGオブジェクト指向も罪なもんだ。
0019デフォルトの名無しさん
NGNG>私の独自の調査においては、OOで開発すると効率が悪く
>バグコードが侵入しやすい傾向があるという調査結果が出ています。
この調査の詳細が知りたい。
仕事でオブジェクト指向やC++なんて何のメリットもない、って人はかなりいるんだけど、
そういう人ってその理由を論理的に説明してくれない（できない？）から、
OOマンセーな僕としては、是非その詳細を知りたいのです。
0020逝って良しの１
NGNG>>9 再利用と OO とは関係ないだろ
ヽ(｀Д´)ﾉ ｻﾗｼｱｹﾞﾀﾞﾞｺﾞﾙｱ
0021デフォルトの名無しさん
NGNGオブジェクト指向が戦場で必要ないかどうかよりも
糞PGをまず先に何とかして
0022逝って良しの１
NGNGＣでダメダメだった奴は時流に乗ってＯＯで１発スターダムにのし上がろうと
しても無駄という事です。
ＢＡＳＩＣでダメダメだった奴はＣでもダメダメだったし、
Ｃでダメダメだった奴はＯＯＰＬでもダメダメ。
「そうか！俺がダメなんじゃなくてＧＯＴＯが悪かったんだ！」
なんて言語のせいにしてる時点でだめ。
0023デフォルトの名無しさん
NGNG>仕事でオブジェクト指向やC++なんて何のメリットもない、って人はかなりいるんだけど
>そういう人ってその理由を論理的に説明してくれない（できない？）から、
「悪魔の証明」だもの。あたりまえだろ。
0024デフォルトの名無しさん
NGNG> 仕事でオブジェクト指向やC++なんて何のメリットもない、って人はかなりいるんだけど、
> そういう人ってその理由を論理的に説明してくれない（できない？）から、
> OOマンセーな僕としては、是非その詳細を知りたいのです。
例えば、サイクリングや山登りをチームで行ったとしましょう。
その場合、チームの速度はチームの中で一番遅い人の速度になります。
プログラミングもチームで開発を行う場合はチームの中で
一番スキルの低い人にあわせる必要があります。
そして、他の方法よりもオブジェクト指向やC++はスキルが必要です。
もし、そのチームが全員オブジェクト指向やC++を理解していない場合、
メリットよりもデメリットの方が高いです。
0025デフォルトの名無しさん
NGNGそういう時の正解は、ヘタレを切ること。プロジェクト管理の鉄則だな。
0026デフォルトの名無しさん
NGNGそんな必要はないよ。
俺は技能が低い奴が混じっていたら スクリプト作ってスクリプト触らせてる。
OOが好きとかいう奴にはOO風スクリプトにして満足させてやってる
>>25
技能に応じた仕事をさせて責任と報酬をバランスするのがプロジェクト管理の鉄則だよ
0027デフォルトの名無しさん
NGNG大抵の場合、報酬はプロジェクト管理の埒外で決められているという罠。
0028デフォルトの名無しさん
NGNG> そういう時の正解は、ヘタレを切ること。プロジェクト管理の鉄則だな。
君のプロジェクト管理は楽そうでいいね。
で、人数が不足した場合、どうするの？
0029デフォルトの名無しさん
NGNGそれぞれに山を設定して、それぞれの山に同じ時期に到着出来るように
配分してやれって事だな
0030デフォルトの名無しさん
NGNGまあ、オチケツ。
「人月の神話」を持ち出すまでもなく、ヘタレがいるとマトモな奴等の負担になるんよ。
ヘタレを外して結果として人数が足りなくなるのなら、ヘタレがいたらもっと人数が足りなくなる罠。
そんぐらいなら少数精鋭でやったほうが傷が少なくてすみぞ。
0031デフォルトの名無しさん
NGNG> そんぐらいなら少数精鋭でやったほうが傷が少なくてすみぞ。
それはチーム人数に対し、ヘタレの人数が十分に少ない場合、
例えばチームのほとんど全員がヘタレだった場合、どうするんだい？
尻尾をまいて逃げるが君の正解かい？
0032デフォルトの名無しさん
NGNGチームのほとんど全員がヘタレなのに爆進し続けてデスマーチにするのが得意な人ですか？
0033デフォルトの名無しさん
NGNGありませんよ。
だって切ればいいだけのことですもの。
0034デフォルトの名無しさん
NGNG0035デフォルトの名無しさん
NGNG> だって切ればいいだけのことですもの
そして誰もいなくなった．．．
0036デフォルトの名無しさん
NGNGそれで誰もいなくなるような所なら、なくなってしまったほうがマシ。
0037デフォルトの名無しさん
NGNGサポート役をサポートするためにそのマトモなプログラマの労力が割かれてしまう罠
0038デフォルトの名無しさん
NGNG> それで誰もいなくなるような所なら、なくなってしまったほうがマシ。
チームが存在すれば各人のスキルには差があるのは当然。
スキルが一番低い奴を切っても、次に低かった奴が１番低い奴になるだけ、
スキルが低い奴を切ってもやはりチームにはスキルが低い奴がいる。
そんなこともわからんの？最近の学生って
0039デフォルトの名無しさん
NGNG能力ないのに、気張るＤＱＮＰＧはあかんが、
正直な話し、マトモＰＧが沢山いたら、日本はサブイよ。
ＰＧ職人に傾向すればするほど、精神面が働かなくなるのだ。人間味が無くなる。
0040デフォルトの名無しさん
NGNGオブジェクト指向は「一つの方法」であって、「全て」であったりメインではない。
それが判らずに、先にオブジェクト指向ありきな人はやっぱり普通のチーム開発の適性がない。
単にオブジェクト指向なプロジェクトのチーム開発で歯車として巧く動けた
というスキルがあったとしても、やっぱりプログラマとしては適性が無いのだと思うよ
もちろん、全員が同じツールを使う方法としてはオブジェクト指向に見るべき面がある。
しかし、能力差がある現実を埋める方法としては
VC+VBとか、onVBAとか、>>26のいうonスクリプトとかがやっぱり優れているよ
0041デフォルトの名無しさん
NGNG君は相対評価でしか人の技量を測れないのか？
まあ学生のうちはそれでもいいのかもしれんが、
社会人になったら使える人間と使えない人間をちゃんと区別できるようにならないとね。
0042デフォルトの名無しさん
NGNG> 社会人になったら使える人間と使えない人間をちゃんと区別できるようにならないとね。
取りあえず、読解力の無い人間は使えない人間に区別した方がいいね。
0043デフォルトの名無しさん
NGNGそうだね、>>38の読解力の低さは目に余る。おそらく真っ先に切られる人間だろうな。
まあ、>>38にもきっと自分にあった職種がみつかるでしょ。ソープの呼び込みとか(藁
0044デフォルトの名無しさん
NGNG人間がまともなら、出来る仕事させればいいんだからさ
004538
NGNG> そうだね、>>38の読解力の低さは目に余る。おそらく真っ先に切られる人間だろうな。
> まあ、>>38にもきっと自分にあった職種がみつかるでしょ。ソープの呼び込みとか(藁
ちなみに社会性の低い人間は使える人間だと思いますか？
0046デフォルトの名無しさん
NGNG俺なら仕事出来ない奴をいつまでもプロジェクトに入れておくぐらいなら
人間性に問題があってもちゃんと仕事できる奴を残すな。
情実に流されて編成すると、全員不幸になるよ。
それぐらいなら人間性があるけど仕事できない奴は早目に見切りをつけてあげるのがお互いのため。
切られた奴も、人間性はあるんならいつか自分にあった職種がみつかるだろ。
0047デフォルトの名無しさん
NGNGただし、こんな所で簡単にフレーム起こすような奴は、ちゃんと仕事出来る筈がない。
そういう奴は、条件によって仕事出来るだけの奴
0048デフォルトの名無しさん
NGNG0049デストラクター
NGNGで実際の開発経験があるやつなんているの？
0050デフォルトの名無しさん
NGNG全く使えない手法ではないんだし、ただペラペラしゃべるうちに、万能的に昇格してしまうだけで
0051デフォルトの名無しさん
NGNGあれは、肩書き大卒が生活する手段なんだから、あまりつっこんじゃダメ！
0052デフォルトの名無しさん
NGNGとした場合クラス設計までが戦略にはいるかいな。
戦略が間違っていたら戦術が修羅場になるのは当たりまえで、
別にＯＯ自体の問題ではない罠。
クラス設計を戦場で見なおさないとしたら、戦略ミスということかな。
0053デフォルトの名無しさん
NGNGクビになる奴には漏れが後にメンテナンスする羽目になる
ためぜひフラットに作っていただきたい。
0054デフォルトの名無しさん
NGNGもちろん報酬もね。募集かければすぐ人材が来るような環境
がうらやましいね。
0055デフォルトの名無しさん
NGNG札幌か？
Javaマスターとかやってる割には
まともにできるやつがいねーよ。
0056_
NGNG再利用可能なのはコンテナ・GUI部品とか抽象度の高い物だけ。
現実のコーディングで抽象度が高い部分はほんの一部。
まー漏れはライブラリ->00, 実際のコード->構造化って使い分けてるけどね。
0057デフォルトの名無しさん
NGNG0058デフォルトの名無しさん
NGNG開発できないからオブジェクト指向やっていんだから
あまりつっこんじゃだめ
0059デフォルトの名無しさん
NGNGデーター抽象化が分かってない。
0060デフォルトの名無しさん
NGNGとりあえず俺は継承がしたいのだ。
0061デフォルトの名無しさん
NGNGはあ？2ちゃんで何いってんだか…
煽りにもなってないよりは、ちゃんと煽りになってるほうが遥かにマシだろ(藁
0062デフォルトの名無しさん
NGNGデザインパターンはまだまだ先の話じゃ馬鹿
0063逝って良しの１
NGNG>>59
すぐそうやって誤魔化す。
0064デフォルトの名無しさん
NGNG0065デフォルトの名無しさん
NGNGだから今後俺しかさわらないと思われるコード（趣味）はclass使わないでやって、
ソース出す時にはclass使ってる。
とりあえず、必要な時だけ使えばいい物なのに
常に使えって言う奴も全く使えないっていう奴もバカじゃねーか？
0066デフォルトの名無しさん
NGNGまあね、それはいえてるな。
dirty hackで済ませたい所はわざわざclassにする必要はないし、
きちんと形を整えておきたい部分はclassにしたほうがいい。
まあ、俺っちの場合は趣味のコードもclassにするけどね。
もっともこれはそれこそ個人の趣味の問題だから、どうでもいいけど。
0067デフォルトの名無しさん
NGNG0068デフォルトの名無しさん
NGNGオブジェクト指向言語を使う事ではなく、 オブジェクト指向設計の事
俺も class 使うけど、それはあくまでも 便利な機能として使うのであって
オブジェクトを志向などしてるつもりは全くない。
0069デフォルトの名無しさん
NGNGオブジェクト指向言語のどんな所が便利？
その便利さを生かすためにはどんな設計(脳内設計も可)がいいと思う？
0071デフォルトの名無しさん
NGNGクラスは構造体より少し便利だね。コンストラクタが書けるのが特にね
継承も便利だね。
隠蔽は特に便利と思わないな。
設計は普通に構造化で設計してるよ。 トップダウン＋ボトムアップでね
0072デフォルトの名無しさん
NGNGクラスは構造体よりもどんな所が便利？
コンストラクタも単体では構造体の初期化関数と一緒でしょ？
メソッドは書かないの？
0073デフォルトの名無しさん
NGNG構造体ポインタを返す関数と一緒といえば一緒だから。
例外とペアで初めて便利になったって事だな
そりゃクラスを使うんだからメソッドも書くし、virtual にもするよ。
構造体で関数ポインタのメンバ持つよりは楽だからさ
0074デフォルトの名無しさん
NGNGまあ、構造体に関数ポインタ持つと、その構造体の実体ごとにポインタ分のメモリ消費されるからね。
でも、それだけなら構造体とは別にその構造体を操作するための関数書いても同じだよね。
丁度、CのFILE構造体をfopen(), fread(), fclose()等で操作するみたいにさ。
でも、わざわざvirtualにすると何が嬉しいの？
単純な関数呼び出しよりもvtable参照する分だけ遅いよね、virtualにすると。
ひょっとしてpolymorphismなんていうOO臭い事してるわけ？
あと、例外とペアでというけど、普通に関数内で例外を受けるのと何が違うの？
それがオブジェクトのメンバ関数だと何が嬉しいの？
ひょっとして状態をオブジェクト毎に設計してるなんていうOO臭い事してる？
0075デフォルトの名無しさん
NGNGでもそれだけじゃオブジェクト指向設計じゃないよ
Cのfopen/freadやqsortと同じレベルの構造化設計をOO言語でやってるだけ
だってオブジェクト分析してないもの
0076はじめて②
NGNG今レポートを書いてます。
皆様意見をお寄せください！
0077デフォルトの名無しさん
NGNG0078デフォルトの名無しさん
NGNGでも継承と多態は使ってるわけでしょ？わざわざvirtualにしてまで。
その時点で構造化設計の埒外に出てると思うけど。
つまり、少なくとも脳内ではオブジェクト分析の少なくとも一部はやっていると思うよ。
それが本に書いてある方法論の通りでなくてもね。
逆に本に書いてある通りに分析・設計をやってる人って、本当にわかってるとは思えないんだよね。
方法論ってのはプロジェクト毎に改良したり作り直したりするもんだと思うよ。
たぶん君はそれを脳内でやっていると思われ。
0079デフォルトの名無しさん
NGNG0080PE6
NGNG0081デフォルトの名無しさん
NGNG大丈夫、「キミのコードはオブジェクト指向じゃない」って言われてるから間違いなくそうじゃない
まず、継承と多態を使えば構造化設計の埒外ってのはどうかと思う。
オブジェクト＝機能＋データ を主眼に設計するのがオブジェクト指向だろ？
継承も多態も機能の表現方法にすぎない
0082デフォルトの名無しさん
NGNGふりだしに戻ってるし・・・
0083デフォルトの名無しさん
NGNGttp://www.s34.co.jp/cpptechdoc/article/oo/
>これまでのプログラミング言語では、あるシステムを記述していく場合、
>いわば何もない状態から始めなければなりませんでした
とか
>たとえばデータベースの場合、最初にデータのフォーマットを決めてし
>まったとします。そのデータ構造にアクセスするような仕組みを今まで
>のソフトウェア・システムで書いたとすると、そのカラム数を変えたくなっ
>たときに、その部分を変更すると、そのデータをアクセスしているソフト
>ウェアをすべて書き換えなければならなくなりました。
とか
あまりにもお馬鹿な・・・こんなのが蔓延してるからイヤンだよ
0084デフォルトの名無しさん
NGNG分析/設計結果が本当に構造化になっているのかよく考えてみろ。
0085デフォルトの名無しさん
NGNG構造化設計は
簡単に言うとトップダウンやボトムアップを使って小さな構造の集合として大きなプログラムを作りましょうという事
だから普通に使ってるのでは？
0086デフォルトの名無しさん
NGNGオブジェクト指向設計とどう違うの？
0087デフォルトの名無しさん
NGNG構造化設計は 機能から設計する事かな
0088デフォルトの名無しさん
NGNGちぇ、しくじったか(藁
ところで、継承や多態も機能の実現形態だというのは、まあそれならそれでいいけど、
構造化分析/設計では継承や多態をどう表現するの？
とりあえず表現できないことには分析も設計もやりようがないよね。
0089デフォルトの名無しさん
NGNG単に機能を分解して小さくした機能のうちの一つにすぎない
それが表現出来ないなんていえば、関数ポインタさえ表現出来ない事になってしまう
差分コーデングは構造化設計手法での表現は難しいけどね
0090デフォルトの名無しさん
NGNGいや、だから多態ということは、扱うデータによって実際に使われる手続きがかわるでしょ？
で、その使われる手続きの候補は関数内で閉じる構造化と違って、その関数の外に後からどんどん足していけるわけよ。
classを継承したらoverrideするかもしれないし、そのまま使い回されるかもしれない。
これを構造化設計で的確に表現できる？
0091デフォルトの名無しさん
NGNGＯＯだろうがそうじゃなかろうが、操作の対象の種類によって動作が違う
場合は、それぞれの動作を定義しなくちゃいけないのは同じ。
ただ、ＯＯの場合は、デフォルトの動作を定義出来るのがらくちんだし、
間違いが少ない、ってことだろ？
0092デフォルトの名無しさん
NGNGのもメリットの一つだと思うんだけど。ただ昔の設計は今見ると赤面ものだったりする罠。
可読性が高く使えるクラスなら喜んで使わせてくださいな。という感じ。
0093デフォルトの名無しさん
NGNGいや、構造化設計では手続きの中で分岐しているのが根本でしょ。
だからこそ多重ネストして構造化するわけで。
ところが多態の場合は、その手続きの外で分岐している。
しかもその分岐先は不定で、いつでも追加できる。
よって、いつまでたってもその「分岐」は定義できないわけよ。
もしその「確定できない分岐」を仮想的な手続きで囲んでしまうと、
その手続きはいつまでも定義できない。
これは構造化設計では致命的な問題でしょ。
0094デフォルトの名無しさん
NGNGトップダウン設計の時には「ここにこんな処理する」って書いておいて
その部分の実装は後で考える事にする。 そこは仮想というか非常に大まかなイメージね
そして、ボトムアップで必要そうなそれぞれの手続きを組んでみて、
ああ、この部分の詳細は関数ポインタか多態でいいな って間に入れてゆくだけ
なんで致命的とか思うわけ？
0095デフォルトの名無しさん
NGNGええ？それじゃあトップダウンの時とボトムアップの時で手続きの実体が別々になっちゃうでしょ。
別々どころか1対他対応だよ、それじゃ。粒度も違うし。
トレーサビリティが低すぎないか、それ？
そもそも、それではどの機能がどの機能を利用して実装するのか全然明かにならないじゃん。
0097デフォルトの名無しさん
NGNG細かい部分がわからん。
0098デフォルトの名無しさん
NGNGというわけで、やっぱり君は構造化設計とOO言語の間の溝を
脳内設計で埋めているんだよ、きっと。
さっさと改宗しなされや (藁
0099デフォルトの名無しさん
NGNG0100デフォルトの名無しさん
NGNGその勢いでOO言語処理系の設計をしてしまいなさい。
きっと幸せになれます。(藁
0101デフォルトの名無しさん
NGNG■ このスレッドは過去ログ倉庫に格納されています