オブジェクト指向を大いに語るスレ

作りました。
いくつか潮流ができることが予想されるので、
スレの流れを見て分割するかどうか各自判断してください。
必要と判断した方は適切な処置をお願いします。

２！！

マンセー

オブジェクト指向逝って良し！
http://mentai.2ch.net/test/read.cgi?bbs=prog&key=995110531

オブジェクト指向は、現実の概念をそのままコンプーターに取り入れるという馬鹿げた発想。公私混同もいいところです。

たった今悟りが拓けました！
万物はオブジェクト指向だった！

オブジェクト指向は保守性に優れているというが、実際どうだろうね？
「ああ、ここでこのステータスが見えれば１行で修正終わるのに」と思っても、クラスの設計がそれを許さないようになっていたら、多大なる修正が必要となる。
そういうと決まって「それは設計が悪い」という話になるが、何もかも想定して設計出来る訳がない。それこそ「そんな仕様変更アリかよ！」と怒鳴りたくなるような修正が来るなんてザラじゃないか。

確かにオブジェクト指向はハマれば能力を発揮するが、現場でそこまでじっくりと設計出来る事は少ないんだから、上手くハマる状況の方が少ない気がする。机上の空論になりつつあると思うんだけどね。
ちなみに、オレはオブジェクト指向は「頭のいい人が設計したモノならマンセー」。ただ、あまりに頭の悪い設計が多くて、何度も泣いたよ。

作ったらまず消して、それから思い出せ。思い出せなければその設計はクソだ。

本来なら、こういう話題は技術板だよな……。

>>9
ほんとは学問カテゴリにオブジェクト指向板があるべきとは思いますが。
技術板は違うかと。

>>7
「ああ、ここでこのステータスが見えれば１行で修正終わるのに」
って修正できたとして、その修正が正しいかどうか確認したりテストしたり
するのは大変じゃない？

ＣＯＢＯＬが一番じゃワイ。

これじゃ前スレの方がよほど有益じゃねぇか・・・。

DBが実際の物事に連結してないとかなりつらいね。
OO的思考のできないDB設計者とはやりずらいしやりたくない。

>>7
「運転手が飲酒しているので車が自動的にブレーキを調整をする」
的な仕様変更はまいる。
飲酒してたら車に乗らない、そもそもそれ自動的オブジェクトの
仕事じゃない、などなどＯＯを盾に断りたい。

○＝自動的
×＝自動車

ｳﾂﾀﾞ

>>7は無知

>>15
そういう抽象的な例えしか出来ないのがオブジェクト指向なのですね。

>ＯＯを盾に断りたい。
それは、あなたの願望ですか？

ヘミ猫風のレスを付けてみました。

18は頭がおかしいっぽい。

ヘミ猫氏のまねをしただけで、漏れは頭可笑しくないぞ！
http://teri.2ch.net/test/read.cgi?bbs=mac&key=994973323&ls=100

>>20
>18は頭がおかしいっぽい。
そう言う事にしたいのですね。

>>15
そんなのが通用する客が多い世界だと思っているのか？
もっとものすごい変更や仕様をさらりと言う。
それがこの業界の客じゃないか？

などとネタにマジレスしたりして……ＯＯが通じないぐらい狂ってるのがこの業界じゃないかと。

>>11
いや、昨日そういうバグの修正を頼まれたんで。オレが作ったものじゃないから余計腹が立って。
「このクラスで何故このステータスが見えないような設計してやがるんだ？」
と言いたくなるような非道い設計だった。
で、たった１行の修正で済むのに、クラスの設計から見直してやらないといけないってのがどうにもこうにもムカついて愚痴っただけ。

>>17
いや、だからどう無知なのか言わないとさ。
君みたいに相手に用件を伝える能力が不十分なのって、この業界じゃゴミ扱いなの。僕よりモノを知っている君は、それぐらい知ってるよね？

オブジェクト指向を大いに愚痴るスレ？

>>23
XPみたいに「変化を擁護する」っていう考え方が無いオブジェクト指向開発の
プロジェクトって実際のところどうなんですかね。自分はまだ
オブジェクト指向な開発現場に携わったことがないんですが。

事前の分析/設計で全てが決まってしまうとどうしてもそういうことが発生するよね。
「それは設計ができない人間の問題」じゃ片付かないと思ってるんだけど。

>>25
XPは現実にはどうなんでしょう？
1日2交替勤務の奴隷制度かとおもった。

仕様変更はあくまで仕様変更。
クラスに関連づいた業務単位、実物そのものの定義が間違っていなければ
それをどう扱いたいか、みたいなことは業務のレベルでの変更にとどまる。
そしてそれは多くの場合継承、多態で解決できる。

あ、逝ってよしの１だったっけ。
ま、あんたには何言っても無駄なんだってわかってるよ。

↑は＞２３へのレス

>>25
同意。２３はダメダメSE（自分のことか）に文句いってるだけで
OOに矛先向けてもダメだよ。
そのSEの馬鹿さと、多くの開発で取られている手法を
一緒くたにしても叩かれるだけだよ。

↑のはまちがい。同意取り消し。

XPはオブジェクト指向と相反するものでもなんでもないよ
むしろ前提としてあるのはOO開発。

>>30
「オブジェクト指向と相反する」っていう意図は全くなかったんですが。
どこらへんを読んでそう感じたのでしょう?

質問なんですが、ほんとにXPの前提にOO開発は必須なんですかね。
このへんが自分のなかで整理できてないんですが。

>>30
追加。
23さんはOOに矛先向けてるわけじゃないと思う。
OOの開発スタイルを問題視してるんじゃないかと思って
25の発言したんですが。

了解。
＞XPみたいに「変化を擁護する」っていう考え方が無いオブジェクト指向開発の
プロジェクト

の区切り方で読み違えたよ。

＞32
OOは開発スタイルには言及していないと思うよ。
OOの開発スタイル、という定義はいささか乱暴だし携わったことがないならなおさら
そもそも設計ですべてが決まるとは少なくとも私は思ってない。
客の言うことなんて話半分だけどね。
でも承認はきっちり取るよ。そこからは別案件だからね

>>27 おれじゃないよ

>>35 そういうプログラム書くと止まるよ

>>35
たしかに。
スタックオーバーフローだな。

じゃ、仕様変更の話します？

OOで設計したものが根底から覆されるような仕様変更ってたとえば
どんなの？

自分はまだそういう経験はない。「仕様変更は（ﾟдﾟ）ｳﾏｰ」と思ってるよ。

経験者の各論で話したいね。極力具体的に。

>>34
スマソ。今度は僕が区切り間違え。
OOの開発スタイル→OO開発のスタイル

ん〜。これでも変かな。言いたいのは「一回決めたら変更したらだめよ」
ってのはナンセンスなんじゃないかってこと。
要求やら規模やら何やらで、そんなの無理だっていう状況があることも
理解してるつもりですが。

日本でオブジェクト指向の話するなら青木さんのことを忘れちゃいけないよ。

http://www.sra.co.jp/people/aoki/IntroductionToOOAOOD/chapter3/Chapter3.htm
>オブジェクト指向のソフトウェア開発では，次のことを大前提して，
>この大前提に対処するための開発過程を考える。
>
>　　(1) 利用者の要求仕様は永遠に確定しない。
>　　(2) 開発者の設計仕様も永遠に確定しない。
>　　(3) ソフトウェアは完成することがない。

ゲームは別だけどね

観念的なはなしだと煽るやついるのに
具体的な話になると全然でてこないんだね

ダメとかいってる人って、どこがダメなのか説明もできんのか？

>>7
頭悪い設計や、当初の考えをぶち壊しにする仕様変更などが、
それと明確にわかるだけでもオブジェクト指向は良いんじゃないの？
これまでだと、ひどい実装だと思っても批判とかすげーしにくいし、仕様変更も
てきとーにながして結局スパゲティ化させてたけど、
オブジェクト指向だと反省して次に活かしやすい感じ。

クラス継承によるスコープ制限を活用するだけでもすごく見通しよくなる気がします。
たとえば C/C++ を使っているみなさんはいろいろな便利関数を作って
自分用のライブラリを作っていらっしゃると思いますが、
そのたくさんの関数を public な static 関数として
いくつかのクラスに分類するだけでも、整理になるし。

namespace 使わないの？

生産管理システムが多いんですが、
生産ってオブジェクト指向でしっくりくる場合が多い。

逆に金融とか財務とか統計はやりにくいかも。
UIを別にすればだけど

並列オブジェクトがどーたら
逝っていた発言があったけど

Winのメッセージ処理の足かせなんじゃないか？

オブジェクトが全部、別スレッドで動作したとしても
やり方によっては効率よく物事が進むと思うのだが。

OSレベルでそのようなオブジェクトについて
簡単に扱えるようにしてもらわなければ困るけど。

電波くんこっちにもきちゃったからあまり議論する気になれんが、
具体的な話を一つ。

マスタの一覧表示系(Master)と入力項目の一覧表示系(List)の
表示形式が同じだったから、MasterListBaseクラスを作って
そこに共通処理を書いて、更にMasterBaseとListBaseをつくって
各画面はそれぞれ継承して書いてた。したら入力項目の方の
仕様がころころ変わってMasterListBaseに書いてた処理はMasterBaseに
移して、List系は各画面ごとに書き直しになったことがある。

処理が似てても意味合いが違う（マスタと入力項目）ものは
同じベースクラスにしちゃいけないと悟った３年前の夏。

ん？俺のことか？>>47
おれはあっちのスレでは全然発言してないよ。

あっちの494とか実に面白い話だな。

>>47
MasterListBaseは抽象にしとけ。

それに、その仕様変更にも耐えれるように出来るのが
OO志向だからそのままのやり方でいいですぜ、ダンナ

ListViewerというクラスに共通する表示処理を実装して
そいつにデータを渡すためのListインターフェースを
マスタや入力項目のデータクラスに持たせるってのはどう？

>>50
自己レス。
ListインターフェースじゃなくてListアダプタの方がいいかも。

ListViewer.showList( new ListAdaptorForMaster( Master)) ;
ListViewer.showList( new ListAdaptorForInput( Input)) ;

ってな具合。

>>48
つーかお前誰よ？ｗ
デンパは前スレの１でしょ。どうみても。
あと俺は並列OOは知りません。

>>50
いや開発環境Delphiだったので、必要なデータを拾ってきてどうのとか
いうクラスはもともとあんのよ。表示するときにListView+メニューボタン
(エクスプローラみたいなかんじ)なんだけど、メニューボタンの種類や機能が
ガンガン仕様変更されて結局共通化できなくなった、というお話。

継承を「機能の共通化を図るのに便利」と考えていた昔の話。
はじめから委譲にしてれば変更点は少なくてすんだんだけどね。

>>52
なるほど。
継承と委譲の判断はオーソドックスにして深い問題だよね。

>>53
この辺に関してちゃんと書かれた本とか論文とかってあるんですかね？
言語に依存する問題とは思うんですが。
GoFの中では「なるべく委譲使ったらいいんじゃねーの」とは書いてあったけど。

>>54
自分の知る範囲内では見たことがないなぁ。
オブジェクトへのアクセスインターフェースを
動的に構成できるような言語なら話が違ってくるでしょうね。
Lispスレを見てるとまさにそういう言語に見えます。
仕事で使う勇気はないけど(笑)

え、デザインパターンがまさにどういうときにを継承にすべきか委譲にすべきかを
経験則に基づいて系統立ててるんだと思ってたんだけど、違うの？
Observerなんてまさに「こっちが継承、こっちが委譲」みたいなモデルじゃん。

俺がドキュソなのか

自己満足的なOOPしかできないヤツは氏んでくれ。

自己満足でもOOPできるだけマシ。それすらできないやつこそ逝ってまえ

Observerパターンでプログラム作った時
MFCのDocumentViewアーキティクチャと同じことに気づいた
これって、どっちが先？

おブジェクト至高は、人間がいかにサボるために作られた概念であり、それはまたコードの保守性・再利用性を向上させるものであるが、再利用されないときもあり、無駄の一歩手前で落ちかけた手段でもある。

31>>
＞質問なんですが、ほんとにXPの前提にOO開発は必須なんですかね

極単純に考えて、OOの非依存な分割を前提としないと
あのように単体テストを行う意味はないんじゃないかな。

>>59
Observerの方が古いんでないかな。
SmalltalkのModelViewに出てくるModelViewControlerは
モロにObserverだとどこかで読んだ記憶がある。

というか、そうであって欲しい・・・

デザインパターンを「単に便利なテンプレート」としか
思っていない奴には再利用可能なコードなど書けるわけがない！
と思うが、どーよ？

>>63
個人的に同意。
しかし、周りの人デザインパターンという言葉すら知らない。
そのくせOOP自慢げに語ってるし...

デザパタ、まんせい、あげ

あげ