- 1 名前：仕様書無しさん mailto:sage [2007/03/29(木) 01:28:08 ]
- 過去スレ
【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★4
pc11.2ch.net/test/read.cgi/prog/1173529414/
【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★5
pc11.2ch.net/test/read.cgi/prog/1174746731/
スルー推奨ワード（相手をした場合は荒らしとみなされます）
電球、たかひろ
このスレは設計、実装含めた形でのOOに関する話題について語り合う目的で立てています。
なので設計だけ、実装だけといった縛りは特にありません。
設計には方針レベルからデザインパターンなどの実装設計レベルまで幅広くあります。
いままでの流れをみるかぎり、各々OOに対する考え方や適用レベルが異なるため、煽りや中傷のレスが書き込まれていますが、
書き込む方はどのスコープでOOを適用するかを伝えた上で書き込むのが良いかと思います。
- 711 名前：仕様書無しさん mailto:sage [2007/04/27(金) 01:30:52 ]
- 数学で行列やベクトルが何故便利なのかという質問と同じような話な気がする。
事前に演算体系(=クラス設計)を定義する事で実際は複雑な計算(=プログラム)
を如何に表面上簡潔に表現(=プログラム作成)するかというような。
OOP機能はそういった演算体系(=プログラム内の抽象化構造)の階層化を比較的
自然に表現できるし、逆にそういった機能(例ではベクトルや行列計算が無くても
四則演算のみで解決できるような問題)が必要無い規模では余りメリットが見えて
こないかも。
- 712 名前：仕様書無しさん mailto:sage [2007/04/27(金) 02:01:04 ]
- プログラムをOOP機能を使ってで作成する場合、クラス設計に要する思考は対象
となるアルゴリズムよりも一段メタ的な所にシフトして設計し、その後対象
アルゴリズムにシフトダウンする必要があると思うのだけど、この思考の切り替え
の部分が(自分の経験では)人により差異があるように見受けられるのでオブジェクト
指向が難しいと言われる一因ではないかと思う。
ただ幾ら慣れても切り替えのコストは0では無いので自分の場合も数10〜数100行
程度の雑用プログラムを書き殴るのであればクラス機能とか使わない方が楽だけど、
それ以上もしくはメンテナンス効率なんかを考えるとOOP機能は便利。
- 713 名前：仕様書無しさん mailto:sage [2007/04/27(金) 02:04:41 ]
- 思う
思う
思う
('A`)ｳﾞｧｰ
- 714 名前：仕様書無しさん mailto:sage [2007/04/27(金) 02:28:55 ]
- >>646
>>617
- 715 名前：仕様書無しさん [2007/04/27(金) 02:30:17 ]
- これまた判りやすい
薄っぺらな自作自演
- 716 名前：仕様書無しさん [2007/04/27(金) 02:32:15 ]
- 用語使いが特殊というか変だ
- 717 名前：仕様書無しさん mailto:sage [2007/04/27(金) 02:50:10 ]
- 高弘隔離病棟
- 718 名前：仕様書無しさん mailto:sage [2007/04/27(金) 03:39:52 ]
- 710=711=712
別段自演の意図では無く思いついたまま書いただけだけど、自演っぽく映ったの
ならスマヌ
- 719 名前：仕様書無しさん mailto:sage [2007/04/27(金) 05:31:28 ]
- >>707
俺様的には気軽に型を作りまくれる辺りだな
Cで調子こいて構造体作りまくると
操作する為の関数が多くなる
まぁそこまではどっちも似たようなモンだけど
それら自作構造体の内容を全部文字列として標準出力したいとすると…
OOPL:
各クラスでtoString()オーバーライドして
出力ルーチンは単にtoString()して出力するだけでいいんじゃね？
あれだよあれ、多態ってヤツだよ
非OOPL:
型判定して型にそった文字列化の関数呼ぶ？
でもソレちと行数が多いな…つーかこんなに構造体作ったの誰だよ
つーワケで自作型作りまくるなら断然OOPLだな
別にOOでない使い方だって出来るんだしぃ？
- 720 名前：仕様書無しさん mailto:sage [2007/04/27(金) 07:05:12 ]
- 非OOPL:
extern int print(struct foo);
extern int print(struct hoge);
extern int print(struct fuga);
- 721 名前：仕様書無しさん mailto:sage [2007/04/27(金) 07:55:23 ]
- 非OOPL
template<typename T>
void print(T x){printString(toString(x));}
- 722 名前：仕様書無しさん mailto:sage [2007/04/27(金) 08:15:52 ]
- 「プログラミング作法」の Rob Pike 先生によるOO信者批判
hisashim.livejournal.com/69145.html
私はオブジェクト指向設計の熱心なファンではない。私はOOで作られた美しいものを
いくつか見てきたし、自分でもOOなものを若干手がけさえしたけれど、OOは単に問題に
対してアプローチする方法のひとつでしかない。ある問題に対しては理想的な方法だが、
別の問題に対してはそれほど合った方法ではない。（中略）
オブジェクト指向設計の推進者たちは、ひと塊の木材が持つ美しさが作業を始める前に
自ら姿を現すのを待っている、木彫りの名人のように思えるときがある。「おや、見てくれよ。
木をこう回転させたら、木目が座席の角度にちょうどうまく合った角度で流れるよ、ねえ？」
素晴らしい、いい椅子だ。でも自分が座っているときに木目が気になるだろうか？ そして
次回は？ やらなければならないことが、どんな木材にも隠されていないことがときどきある。
OOは、インターフェイスが自然に幅広い範囲の型に適用できるような問題には素晴らしく
適しているが、ポリモーフィズムを扱うにはあまり適さないし（コレクションをOO言語に
持ち込もうと画策する動きは、見ていると仰天することばかりだし、一緒に作業をすると
なるとひどい目にあいかねない）、ネットワークコンピューティングには抜群に不向きだ。
私が、問題によって言語を使い分け、そしてさらには -- しばしば -- ひとつの問題を解決
するために複数の言語で書かれたソフトウェアを組み合わせる、そういったことをする
権利を保留しているのは、このことが理由だ。
- 723 名前：仕様書無しさん mailto:sage [2007/04/27(金) 09:06:20 ]
- たっ、…たとえだよ、たーとーえ！
俺様だってＣ言語ぐらい知ってらい！
ほら、もっと何かあるだろ？
でもC++なんてずるい…
- 724 名前：おじゃばさま ◆GxjxF3yEw6 [2007/04/27(金) 10:14:53 ]
- オブジェクト指向の利点は変更に対する強さだ。
つまり正しく設計されたOOプログラムは変更を繰り返しても、構造が悪化せずむしろ洗練されていく。
Cの構造化でも正しく組めば悪化しないと言うかもしれないが、確かにうまく組めば悪化しないだろう。
しかし構造化Cで悪化しない場合は、設計者が経験豊富で、変更を見越した設計を行っている場合が
ほとんどだ。OOの場合は変更を見越していなくても、OOの方針に従っていれば少ない修正量で構造を悪化
させずに機能追加できる。
あと仕様が明確でなくても作りやすいのがOOの特徴だ。
非OOの場合は仕様が全部見えてないと作りにくい。後から追加された仕様で作り直しに近くなったりする。
OOの場合は分かっている所から作り始めても、OOの方針に従っていれば、修正量は少ない。
ただ設計者が追加を正確に見越していれば、非OOでも問題なく作れる。
例を示すと、CとJavaでDBを使ったアプリを作っていたとする。
営業が「ORACLEは高いからPostgresにする事に決まったよ。」と言ったら、Cの方はDBを変更する事を
見越した設計にしていない限り、作り直しになる。Javaなら少し修正するだけだ。
また営業が「もっと売りたいな、64ビットSolarisでも、32ビットLinuxでも動くようにしておいて。」
なんて言ったとする。64/32の互換を考慮した設計なら非OOでも問題ないが、多くの場合は分かりにくい
バグに悩まされることになる。
- 725 名前：仕様書無しさん mailto:sage [2007/04/27(金) 10:23:27 ]
- なぜOOだとバカでも変更に強い設計が出来るんだ？って説明がないぞ。
どっちかっていうとOOってバカでも能書きが言えて素人をだませる、
という主張にしか見えないなぁ。
- 726 名前：仕様書無しさん mailto:sage [2007/04/27(金) 10:48:57 ]
- >>725
同意。事象の表明を書くのは良いがそれだけじゃ意味が無いワイ
やれば誰でも実感できるレベルの話だけをながながと読まされるこっちの身にもなってみろ。
>>724よ、>>725の指摘した点に自分の考察なり見解なりを書いてみろよ。
お前の観察日記を読むために来てるんじゃない
- 727 名前：仕様書無しさん [2007/04/27(金) 10:50:24 ]
- バカにOO与えると
泥沼になる
- 728 名前：仕様書無しさん mailto:sage [2007/04/27(金) 11:32:25 ]
- >>726
>ながながと読まされるこっちの身にもなってみろ。
おじゃばファンでもないのに、なんで読むのさ。
- 729 名前：仕様書無しさん mailto:sage [2007/04/27(金) 12:10:29 ]
- ぶっちゃけ日記はblogでやってろってなレベル＞アホコテ
- 730 名前：726 mailto:sage [2007/04/27(金) 12:18:56 ]
- >>728
そりゃぁ。
>ながながと読まされるこっちの身にもなってみろ。
とレスするためさ
- 731 名前：仕様書無しさん mailto:sage [2007/04/27(金) 13:41:25 ]
- >>724をリファクタリングしてみた。
ＯＯは仕様変更に強く、変更の繰り返しで寧ろ構造が洗練されていく。
また、分かっている所から作り始められるので、仕様が不明確でも作り易い。
対して、非ＯＯの場合は、熟練者が変更を見越した設計をしていない限り、
修正は困難になる。
例えば、対象DBやＯＳが変更になる場合でも、OOだと、少しの修正で済むが、
非ＯＯでは変更が考慮されていない場合、バグに悩まされることになる。
・・・纏めてみても、結局何を言いたいのかよくわからんな。ＯＯの利点を強調
したいのか、非OOでもうまく設計されていれば問題無いと言いたいのか。
- 732 名前：仕様書無しさん mailto:sage [2007/04/27(金) 14:26:52 ]
- くだらないあげあしとりばっか
あきらかにおじゃば以下
- 733 名前：仕様書無しさん mailto:sage [2007/04/27(金) 14:52:07 ]
- >>725-726
正論。
>>724は信念を語っているだけで、
その信念の合理性を客観的示す事ができない。
つまり宗教なんだ
- 734 名前：仕様書無しさん mailto:sage [2007/04/27(金) 14:59:21 ]
- >>733
そんなもの簡単に示せるわけがない
かいつまんでいうと、あげあしとりｳｾﾞｴ
- 735 名前：仕様書無しさん mailto:sage [2007/04/27(金) 15:06:16 ]
- 全体を批判することをいつから「あげあしとり」と呼ぶようになったんだ。
○○以下 という発言は「自分は○○です」と言っている様に読めるぞ。
かいつまんでいうと、ｵﾏｴが黙れ
- 736 名前：仕様書無しさん mailto:sage [2007/04/27(金) 15:18:33 ]
- >>735
いや黙るべきはお前だ
対案のない批判なんか必要ない
- 737 名前：仕様書無しさん mailto:sage [2007/04/27(金) 15:34:05 ]
- >>733
> >>724は信念を語っているだけで、
> その信念の合理性を客観的示す事ができない。
>>734
> >>733
> そんなもの簡単に示せるわけがない
> かいつまんでいうと、あげあしとりｳｾﾞｴ
信念の合理性を客観的に示す事ができない＝狂信者決定
- 738 名前：仕様書無しさん mailto:sage [2007/04/27(金) 15:43:52 ]
- >>737
おまえの信念と客観的な合理性の提示よろ
- 739 名前：仕様書無しさん mailto:sage [2007/04/27(金) 16:28:29 ]
- 信念：
狂信者に対し、自分の信念を語る暇などない。
客観的合理性：
狂信者とは、己の考えの根本的正当性の確認努力や
他人に対する合理的説明努力を怠ったまま、
自分の考えが絶対正しいと主張する輩に対する
蔑称である。
そのような人物と時間を費やし議論を重ねても、
虚しい言葉が行き来するのみで
相互理解は極めて難しい。
従って、狂信者に対しては何も語らず、
ただ黙殺する事が、時間を有効に使う秘訣である。
- 740 名前：仕様書無しさん mailto:sage [2007/04/27(金) 16:40:14 ]
- >>739
黙るっていったからには絶対黙れよ。
- 741 名前：仕様書無しさん mailto:sage [2007/04/27(金) 16:56:19 ]
- 次スレは
【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発儲はなぜ黙らないの？★
ということでよろしいか？
- 742 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:02:11 ]
- アンチでも信者でもいいけど、なんか中身のあるレスすれば？
あきらかにココ電以下
- 743 名前：仕様書無しさん [2007/04/27(金) 17:02:11 ]
- あまりに>>724が哀れだから >>724を訂正してやろう。
1. OOであろうと構造化であろうと、下記二点
(1)高凝集性：プログラムの構成要素(変数,関数,etc.)の出現範囲を局所化する
(2)疎結合性：局所的なまとまりに対し適切なインタフェースをつける
を「実現」すれば、
「ある範囲」の変更要求に対しては、変更の影響を局所化でき、
拡張性/保守性の高い、いわゆる「変更に強い」プログラムを構築できる。
2. OOは、その種の局所化とインターフェース化について、
構造化よりも適切な道具を提供しており、
「それらの道具を適切に用いれば」、
上記二点を実現する際の設計負荷を和らげる事ができる。
問題は1(1)(2)の実現方法、2の道具の適切な使用方法にある。
OOであれば、熟練しなくとも1(1)(2)、2を実現できるなどというのは
妄言に過ぎない。
- 744 名前：仕様書無しさん [2007/04/27(金) 17:04:50 ]
- >>724
高弘さぁ、レポート書くの苦手だろ。
お前の文章って怨念がにじみ出ていて、
全然客観的じゃない。
「理系の作文技術」でも読んで、レポート書く練習したらどう？
- 745 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:10:24 ]
- おまえアホだろ
おじゃばは少なくとも「OOの方が低コスト」と主張している。
おまえの主張はまとはずれ。
- 746 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:11:26 ]
- ことばたらずだった。
「変更に強い」プログラムをつくるためのコストな。
- 747 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:12:28 ]
- >>743
客観性一切なし。もう黙れ。
- 748 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:13:19 ]
- で>>743に要約したみたいな30年前の素朴な考え方じゃ
とっくに行き詰まりが生じていて、
だから落ちこぼれ業務システムの分野でも
DIコンテナやらサブジェクト指向が取り沙汰されてるんだろ。
- 749 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:13:57 ]
- >>743
具体性も０
- 750 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:14:16 ]
- >>747
とりあえずお前がバカだという事はよく判った。
>>747は罵詈雑言の口先野郎としてスルーする。
- 751 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:14:53 ]
- もしかして、今ここで連続レスしてるのって、
池沼の方？
- 752 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:16:48 ]
- >>748
アスペクト指向、サブジェクト指向はなかなか面白いよね。
業務システムを手続き処理に還元してグダグダにしちまう誰かとは
頭の出来が違うと思った。
- 753 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:17:01 ]
- >>748
だから、の使い方が意味不明。
DIコンテナとサブジェクト指向が、どう行き詰まりを解決するのか書け。
- 754 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:17:56 ]
- >>752
知ったか乙
- 755 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:19:13 ]
- >>752
どこからアスペクト指向が出てくるのやら。
DIコンテナとアスペクト指向に、なにか関係があるとでもおもっているのだろうか。
知ったかJava厨乙
- 756 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:19:31 ]
- バカ相手に講釈するのは時間の無駄。
お前お得意のゴッグルさんで@ITの記事でも読んでろ池沼ｗ
- 757 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:20:58 ]
- 高弘ってテンパるとすぐ罵詈雑言が出てきて、
元の話を棚上げしてくるからからかい易いな
- 758 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:22:29 ]
- 元のはなし： あげあしとりｲﾗﾈ
- 759 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:23:22 ]
- >>756
知ったか確定乙
- 760 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:23:37 ]
- 元のはなし：高弘は言語も思考もカオス
- 761 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:26:14 ]
- 糖質からかうとおもしれぇな
デザパタ、リファクタ、構造化しか持ちネタねぇのかよターコ
- 762 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:40:37 ]
- 糖質の脳内では自分の疑問点を説明してくれない人は
全部「知ったか」と変換されます。
- 763 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:42:43 ]
- 闘牛状態だなｗ
- 764 名前：仕様書無しさん mailto:sage [2007/04/27(金) 17:55:03 ]
- 【レス抽出】
対象スレ： 【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★6
キーワード： 低コスト
抽出レス数：1
>>745はおじゃばの脳内主張をエスパーできるサイコ仲間かｗｗｗｗ
- 765 名前：仕様書無しさん [2007/04/27(金) 18:16:59 ]
- 元の話に出てこない単語が
いきなり飛び出すのは
このスレが糖質の自作自演だから
- 766 名前：仕様書無しさん [2007/04/27(金) 18:54:19 ]
- 野次までつまらなくなってきた
OOわからないなら他行けよ
- 767 名前：仕様書無しさん [2007/04/27(金) 19:00:08 ]
- サイコをリアルタイムでからかえる
とても便利なインターネッツ
- 768 名前：仕様書無しさん mailto:sage [2007/04/27(金) 19:18:16 ]
- DI： クラスの疎結合実装に役立つ
AOP： 個々のクラスが提供すべき機能を
複数の側面に分割して記述する事が可能になる。
結果として通常のクラス設計では複数のクラスに散らばってしまう
横断的関心事の局所化が可能になり、拡張性/保守性を高める事ができる。
- 769 名前：仕様書無しさん mailto:sage [2007/04/27(金) 19:51:51 ]
- サブジェクト指向ってなぁに？ぐぐったら判るの？自分はわかんなかったなぁ。
#ぐぐっったら何でも判るんだったら「オブジェクト指向」も遭難じゃないの？
- 770 名前：おじゃばさま ◆GxjxF3yEw6 [2007/04/27(金) 21:16:17 ]
- >725
バカでも変更に強い設計が出来るなんて言っていない。
そのシステムや業務の経験が浅いSEでも、OOをマスターしていれば、変更に強い設計が出来ると言っている。
>726
「やれば実感出来る話」を長々と書くのは、やらない人が多いからだ。
>731
その解析は正しい。
OOの利点を説明したのが前半。しかし非OOでもうまく設計されていれば問題無い言うのが後半。
OOの利点と、非OOとの違いを聞かれたのでそう答えた。
俺はOOで設計すれば全てOKなどと言うつもりはない。
「仕様が未確定で変更が多い」物にはOOが向く。逆に言うと「仕様が確定していて変更が少ない」なら
非OOの方がいい場合も多い。例えばドライバやハードに近いプログラムなどだ。
- 771 名前：仕様書無しさん mailto:sage [2007/04/27(金) 21:35:07 ]
- いや、だから
バカでも能書きたれて素人をだませる
という主張に見えた、んじゃないの？
依然としてなぜ仕様変更に強い設計が経験が浅くてもできるの、
と言う説明が無いんだけど？
- 772 名前：仕様書無しさん mailto:sage [2007/04/27(金) 21:39:02 ]
- ヒューリスティクスって知ってるか？
- 773 名前：仕様書無しさん [2007/04/27(金) 21:40:52 ]
- また自作自演でレベル低下かｗ
- 774 名前：仕様書無しさん mailto:sage [2007/04/27(金) 21:42:20 ]
- 「やってみたらそうだったから」って話？
んなもん聞いてないだろ、ふつー。
- 775 名前：おじゃばさま ◆GxjxF3yEw6 [2007/04/27(金) 21:42:33 ]
- >733
宗教でも何でもない。
Pro*Cのソースをpostgres用に修正するのと、JDBCのソースをpostgres用に修正するのはどちらが楽か？
設定ファイルに暗号過機能を追加するに、C構造化ソースと、JavaOOソースではどちらが楽か？
やった事のある人なら良く分かるだろう。
>743
実現法方については、すでに具体的なコーディング方法を書いた。
OOなら熟練しなくても良いなど言っていない。その業務には熟練しなくてもいいが、OOの習得は必要。
前にも書いたが、OO方針に従って、1〜2年のプログラミング経験が必要。
>745
「OOの方が低コスト」などとは言っていない。
変更を繰り返す場合は、トータル的にOOの方が低コストになるが、初回の作成や変更の少ないプログラム
では、構造化の方が低コストになる。
- 776 名前：仕様書無しさん mailto:sage [2007/04/27(金) 21:45:08 ]
- 言い訳開始。
- 777 名前：おじゃばさま ◆GxjxF3yEw6 [2007/04/27(金) 21:51:05 ]
- >771
「経験が浅い」って言ってるのは「プログラミング経験」じゃなくて、「業務経験」。
業務経験が浅くてもOOなら変更に強いプログラムを作れると言ったが、
OOのプログラミング経験が浅くても変更に強いプログラムが作れるとは言っていない。
- 778 名前：おじゃばさま ◆GxjxF3yEw6 [2007/04/27(金) 21:55:17 ]
- >774
実例じゃなくて論理を知りたいのか？
長く言うと読まなそうなので短く言うと、抽象化されていると交換が容易なのと、継承を使うと親クラスには
修正が入らないので、ソースが壊れないからの2点が大きい。
- 779 名前：仕様書無しさん mailto:sage [2007/04/27(金) 21:57:04 ]
- ＞業務経験が浅くてもOOなら変更に強いプログラムを作れる
だから、それがなぜかがねえだろ？
だれも「プログラミング経験」の話なんかしてない。誰だ？
逆に「プログラミング経験」があれば業務経験が浅くても
OOなら分析・実装しやすい、のなら話はわかりやすいだろ？
それがテクニックじゃないのかよｗ
- 780 名前：仕様書無しさん mailto:sage [2007/04/27(金) 21:58:42 ]
- 怒濤のようなアナクロニズム
- 781 名前：仕様書無しさん [2007/04/27(金) 22:02:08 ]
- >>777
大当たりおめでとうｗ
なんだかOO利点を挙げようと頑張っているけど1〜2年の経験は1〜2年の経験だ
OOに限らず何事も3年続けてやっとその世界の入り口にたどり着く
3年続けられないならその世界はあきらめろ
- 782 名前：仕様書無しさん mailto:sage [2007/04/27(金) 22:03:05 ]
- もうちょっと話に説得力を持たすための勉強をしろよ、おじゃば。
もうOOとかJavaは習得したんだろ？いいかげん日本語のほうをちゃんとｗ
ま、がんばんなよ。
- 783 名前：仕様書無しさん mailto:sage [2007/04/27(金) 22:15:03 ]
- パソ通時代のログ読んでるのかと錯覚した
- 784 名前：仕様書無しさん mailto:sage [2007/04/27(金) 22:18:04 ]
- 涙はこれで拭いとけ（k
- 785 名前：仕様書無しさん mailto:sage [2007/04/27(金) 22:36:46 ]
- こんな所で自作自演して一体誰が得するんだろうと思った
- 786 名前：仕様書無しさん mailto:sage [2007/04/27(金) 23:02:37 ]
- 自己満足だろ
- 787 名前：仕様書無しさん mailto:sage [2007/04/27(金) 23:29:50 ]
- ジェダイのライトセーバーと同じで
選ばれし者だけがオブジェクト指向を活用できる。
だから本当の意味で流行らないわけだ。
そのことに早く気づこうな。
- 788 名前：仕様書無しさん mailto:sage [2007/04/27(金) 23:58:34 ]
- おじゃばよフォースを使え。
- 789 名前：仕様書無しさん mailto:sage [2007/04/28(土) 00:07:22 ]
- オセロの石やポットの水をオブジェクトにしているようでは
フォースをまとうことは叶わぬわ。
- 790 名前：仕様書無しさん mailto:sage [2007/04/28(土) 00:25:25 ]
- どうしてみんなページ制御が下手なの？
一覧表のページめくりぐらいちゃんと作れなきゃ。だめよ。
- 791 名前：仕様書無しさん mailto:sage [2007/04/28(土) 00:36:54 ]
- 恥ずかしくなっちゃった？
- 792 名前：仕様書無しさん [2007/04/28(土) 00:39:06 ]
- ページの概念をクラスにする。汎用的に使える。
- 793 名前：仕様書無しさん mailto:sage [2007/04/28(土) 00:57:24 ]
- えっと、>>724のおじゃばさんの文面で、ちょっとヘンだな〜って思うところがあります。
OOだと変更が入れば入るほど、洗練されていく、とありますけど、
なぜそうなるんですか？
これはOOの考え方によるものですか？それとも言語仕様も関わりますか？
コーディングって量が少なければ少ないほど、
丈夫なプログラムになるはずなんで、変更が増えるほど良くなる、ってのが分かりません。。。
あと、これはちょっと違うかな〜って思うのがあります。
C言語だとDBが変わると修正が大きくJavaだと小さい、とありますが、
各DB＋言語で使用するライブラリを、DBの違いを吸収した関数を用意しておけば、
関数の呼び先の処理が変わるだけで言語の違いは無いと思うんです。
C言語で、Accessの接続（ODBCあたり？）→Oracleの接続（orlon関数、、かな？）
に変わったとしてもDB_Connect()って関数を呼ぶように作っておけば、
修正はこの関数だけで済みますよね？
バインド変数を使う・使わないとかはDB仕様なのでちょっと変更は必要かもしれませんけど、
Javaでも同じですし・・・
これはオブジェクト指向か構造化かの違いではなく、
単にセンスや考慮の話だと思うんです。
最初の洗練される、ってのも同じ話かな〜って思ってしまって・・・
やっぱりOO分かってないんでしょうね・・・
あぅぅ、長くてすみません；；
- 794 名前：仕様書無しさん mailto:sage [2007/04/28(土) 01:02:09 ]
- あとですね、
OOだと仕様不明点があって作れる、とありますが、
本来のOOってのはそれを設計段階で吸収し終わって、
それをそのままコーディングできるのが強みだと思ってたんですが、
これもやっぱり間違ってますか？・・・
OOとXPのプロトタイプは別の話のはずなんで、
なんか話がいろいろなってる印象があって・・すみません。。
- 795 名前：仕様書無しさん [2007/04/28(土) 01:15:27 ]
- そろそろ我々は設計はヒューリステクスだという事実を認めなければならない。
あらゆる設計に通用する手法などないということを認めなければならない。
最適解など存在しない。しかし、限りなくそれに近づけることはできる。
人間の弱さを認めること。許すこと。許されること。誠意を示すこと。誠意に
保障などないということを認めること。それでも涙しながら助け合うこと。
時に厳しく、時に優しく、諭すこと。切り捨てること。柔軟に対応すること。
我々はクリプトナイトを抱えたスーパーマンだということを、そして簡単に
裏切れるということを認めなければ。コンピュータを相手にしながら、結局、
人間を相手にしているのだということを、認めるしかないのだ。
- 796 名前：仕様書無しさん [2007/04/28(土) 01:23:13 ]
- 最適解どうのこうのいうような事してないんだろｗ
- 797 名前：仕様書無しさん mailto:sage [2007/04/28(土) 03:46:06 ]
- >>793
多分、モジュールとして分割されている事とOO的な分割の
意味を混同しているんだろうと思われる。
たしかに、バイナリレベルで切り離されていれば
呼び出し等は何でも一緒になる。
ペナルティとしては細かいやり取りには向かないって事。
この辺は難度の高いプログラムを組まないとなかなか実感できないと思う。
ソースが洗練云々はプログラムの部品化(つまり共通化)が進むので
開発工程そのものがテスト工程も兼ねる事になるので品質が高くなるという事。
この辺も難度の高いプログラムを組まないとなかなか実感できないと思う。
- 798 名前：仕様書無しさん mailto:sage [2007/04/28(土) 03:47:02 ]
- もうちょっとだけ追加説明をしてみる。
10000ステップの処理に追加処理として10000ステップあったとする。
べたCだと極端な話だけど
10000ステップコーディングした後に
10000*10000通りのテストが待っていて細かくチェックするしかなくなる。
これがOOPだと
元の10000ステップを修正して＋10000以下のコーディングをした後に
元の10000＋10000以下のテストをする事になる。
たいした違いがないように思えるが
これを繰り返すとCだと飽和していくけどOOPだと逆に収束していく。
要はOOPはステップ数を横軸にした場合
コストが収束に向かう関数曲線を描くけど
非OOPは飽和に向かう曲線を描くって話。
- 799 名前：仕様書無しさん mailto:sage [2007/04/28(土) 03:48:23 ]
- おじゃば氏の示している内容はOOPを使って開発経験者なら
誰でも感じる事でむしろ当たり前の事が書かれている。
入門的な書籍等でも大体同じ事は書かれている。
それに食いついている人は実際にはあまりOOPを
扱ってない開発者なのだろう。
- 800 名前：仕様書無しさん mailto:sage [2007/04/28(土) 04:04:49 ]
- >10000+10000うんぬん
どうしてOOだとそうなるのか、説明よろしく。
経験んちゃら、とかじゃなくて「わからなくて質問」してるのがいるんだし、
書籍にあるんなら、どの本か教えてやれよｗ
誰も食いついてなんかいねーよ、説明してくれと言ってる。
- 801 名前：仕様書無しさん mailto:sage [2007/04/28(土) 04:20:27 ]
- >>800
お前、無知なのに生意気だなw
プログラムの部品化(つまり共通化)が進めば
テストされる回数もあがるだろ。
プログラムの品質はテスト回数に比例してあがる。
大規模openソースと企業のソースで適当に調べればわかる。
書籍は俺もかなり前の事なので、よく覚えていない。
お前はいちいち読んだ本の名前を覚えているのか?
初心者向けの本を適当に読めば書いてあるだろw
- 802 名前：仕様書無しさん mailto:sage [2007/04/28(土) 05:03:29 ]
- 読んだ本くらい覚えてるだろ、普通。この本のココを読んだらわかった、とか。
それ以前にどうして構造化がだめでOOだと部品化が進むのよ？
そんなにいいもんなら以下スレタイ、という話じゃないのか。
で、それは「どいつもこいつもOOを勉強しないから」とか
「どれだったか本に書いてあるもん」とか「おっきなとこでやってるから」
「やってみれば誰でもわかるよ」位の話を長文で技術用語(ﾌﾟ垂れ流しでやるから
「それってなんて宗教ｗ」「どこの壺売りよｗ」言われるんじゃないか。
- 803 名前：仕様書無しさん mailto:sage [2007/04/28(土) 07:04:24 ]
- レベルの低い負け犬が30年前の概念を
独りで弄って悦んでる状態か
どうしようもねぇな
- 804 名前：仕様書無しさん mailto:sage [2007/04/28(土) 07:05:52 ]
- > 食いついている人は実際にはあまりOOPを
> 扱ってない開発者なのだろう。
局所化と隠蔽(インタフェース化)
という二言で済む話を延々やってろキチガイ
- 805 名前：仕様書無しさん mailto:sage [2007/04/28(土) 07:10:51 ]
- ＋αがあるだろ
部品化がOOの特徴とかいう陳腐な＋αだがｗ
- 806 名前：仕様書無しさん mailto:sage [2007/04/28(土) 07:25:22 ]
- >人間の弱さを認めること。許すこと。許されること。誠意を示すこと。誠意に
>保障などないということを認めること。それでも涙しながら助け合うこと。
>時に厳しく、時に優しく、諭すこと。切り捨てること。柔軟に対応すること。
元々頭が弱い奴は、プログラミングの現場に来なければいいのに、と思う。
- 807 名前：仕様書無しさん mailto:sage [2007/04/28(土) 08:19:55 ]
- 局所化と隠蔽だけで行き着くところはオブジェクティブスパゲッティｗ
- 808 名前：仕様書無しさん mailto:sage [2007/04/28(土) 08:44:47 ]
- ＧＷ中も糖質は２ちゃん張り付きなのか
- 809 名前：仕様書無しさん mailto:sage [2007/04/28(土) 09:02:33 ]
- 感性を形にできる。それがオブジェクト指向。
感性の良し悪しが、そのまま形になる。それがオブジェクト指向。
- 810 名前：仕様書無しさん [2007/04/28(土) 09:07:01 ]
- 文よりも図の方が直感的で分かりやすい。
つまり構造化よりもオブジェクト指向の方が直感的で分かりやすい。
- 811 名前：仕様書無しさん mailto:sage [2007/04/28(土) 09:15:21 ]
- まずは構造化モデリングが正しく行えるように勉強しなさい。
オブジェクト指向はそれが出来るようになってからな。
|
 |
