[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/10 01:29 / Filesize : 224 KB / Number-of Response : 986
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

【OOD/P】オブジェクト指向開発はなぜ流行らないの?★6



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を適用するかを伝えた上で書き込むのが良いかと思います。


660 名前:仕様書無しさん mailto:sage [2007/04/25(水) 21:03:18 ]
>>655
「OOPに慣れた奴は自然と使ってるパターンがあるが名前が無く
 どういうパターンと言われても説明が長くなる」
というモノに名前を付けたのがデザパタだろ?
だからちゃんと使えてる奴は意識せずとも使ってるのさ

661 名前:おじゃばさま ◆GxjxF3yEw6 [2007/04/25(水) 22:40:32 ]
>653
PGなら誰でも分かるぐらいに簡単に説明したつもりだが、あれでも分からないのか?
いくらなんでも分からない訳ないだろう。つーか読んでないだろ?


662 名前:仕様書無しさん mailto:sage [2007/04/25(水) 22:54:33 ]
>>661
そもそも読む気が起こらない上によく分からん。

663 名前:おじゃばさま ◆GxjxF3yEw6 [2007/04/25(水) 23:01:45 ]
>654
そのような事をHPで言っている人がいたが、いまいち意味が分からなかった。
集合体のインスタンスを生成出来るかどうか?
Cは構造体のインスタンスを生成出来るし、Javaはクラスのインスタンスを生成出来るから、
どちらも集合体のインスタンスは生成出来ると思うが、集合体のインスタンスって何だ?

「シングルトンの場合はモジュールと同じような使い方になる」?
シングルトンは構造化だと言っているのかな?staticメソッドじゃなくてか?


664 名前:仕様書無しさん mailto:sage [2007/04/25(水) 23:07:29 ]
>>654
「オブジェクト指向のクラス」という考え方が間違い。
言語のコードなどどうでもよい。
概念レベルで設計できるのがオブジェクト指向の素晴らしさなのだから。

665 名前:仕様書無しさん mailto:sage [2007/04/25(水) 23:14:02 ]
概念レベルで設計できないパダワン達が言語機構のポリモフィズムを乱用し、
そのうえスレッドを乱発するから、もう何がどうなっているのかわけわからんw
ちゃんとコンピュータサイエンスを学ぼうよ。

666 名前:仕様書無しさん [2007/04/25(水) 23:17:45 ]
もうオブジェクト指向スパゲッティはたくさんだ!!!!!!!!!!!!!!!

667 名前:仕様書無しさん [2007/04/25(水) 23:21:16 ]
オブジェクティブスパゲッティーでマンプクプクw

668 名前:仕様書無しさん [2007/04/25(水) 23:22:48 ]
現実的に生産性は最悪だな。オブジェクト指向。流行らなくていいよ。もうw



669 名前:仕様書無しさん [2007/04/25(水) 23:27:57 ]
何百も派生クラス作るんじゃないよ。まったく。属性で対応できるだろw

670 名前:おじゃばさま ◆GxjxF3yEw6 [2007/04/25(水) 23:28:27 ]
>662
それなら読まずに、Java使ってCの構造化手法でシステム作って、その後にどんどん機能拡張してみるといい。
恐ろしいほどにスパゲティー化するだろうから。

671 名前:ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. [2007/04/25(水) 23:34:18 ]
/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
| 先輩、言われたとおりすべての変数にゲッターとセッターつけました

   ̄ ̄ ̄|/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ∧_∧        / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ( ・∀・)  ∧ ∧ <  マクロで組んでどうすんだよ
 (  ⊃ )  ( ;゚Д゚)  \_____________ 
 ̄ ̄ ̄ ̄ ̄ (つ_つ__ 
 ̄ ̄ ̄日∇ ̄\| VISTA |\
       ̄   =======  \


672 名前:仕様書無しさん [2007/04/25(水) 23:41:26 ]
ここには神レベルのプログラマが二人も降臨しているんだから
みんな有り難く拝聴するんだ!カスのあおりはスルーだ!

673 名前:仕様書無しさん mailto:sage [2007/04/25(水) 23:45:11 ]
主張するとたたかれるのが2ch。ま、主張するより叩く方が気楽で安全だわな。
で、主張するものがいなくなると、ぱったりと寂れるのがこのスレの特徴でもある。

674 名前:仕様書無しさん mailto:sage [2007/04/25(水) 23:52:26 ]
プログラム?ポリモーフィズム?ぷっw、俺様は概念を理解してるからね
そんな末端の瑣末な事柄には興味ないなぁ。チミたち、まだまだだね。
もちょっと勉強しようね。
って言っとけば、とりあえず王様気分でいられる。ま、なんの意味も無い
書き込みだけどね。

675 名前:仕様書無しさん [2007/04/25(水) 23:52:59 ]
変数は必ず関数経由でアクセスする、これがOOですよね先生!

676 名前:仕様書無しさん mailto:sage [2007/04/25(水) 23:55:26 ]
>>663
もう一度言おう。
>いまいち意味が分からなかった。
ばかだからでは?
>Cは構造体のインスタンスを生成出来るし
だから何?
CはOOPLではないが(厳密にはC++も違うかも知れん)、OOPができないわけではないし
そもそも複数のインスタンスが生成できることと構造化パラダイムとは何の関係もない。

677 名前:仕様書無しさん [2007/04/25(水) 23:58:44 ]
糖質スレ

678 名前:仕様書無しさん mailto:sage [2007/04/26(木) 00:00:54 ]
複数のインスタンスが生成できることはOOPパラダイムの一部だもんね



679 名前:仕様書無しさん mailto:sage [2007/04/26(木) 00:02:23 ]
構造体の領域をメモリに確保することと、インスタンスを生成することを
同義とみなす偉大なるおじゃばさま。

680 名前:仕様書無しさん mailto:sage [2007/04/26(木) 00:12:16 ]
意味論つまらん
>>633に戻ってほしい

681 名前:仕様書無しさん [2007/04/26(木) 00:13:54 ]
複数インスタンス厨連投うぜええええ

682 名前:仕様書無しさん mailto:sage [2007/04/26(木) 00:21:11 ]
大体、複数インスタンスってなんなんだよ
インスタンスなんだから複数ある前提に決まってんじゃねえか

683 名前:仕様書無しさん mailto:sage [2007/04/26(木) 00:25:25 ]
package Ojavasama;

sub new {
my $class = shift;
bless {},$class;
}

sub Kakiko {
return 'ぐだぐだぐだぐだ....';
}

1;

684 名前:仕様書無しさん mailto:sage [2007/04/26(木) 00:28:43 ]
javaworldに記事を書いた前橋が沸いてるのか?

685 名前:仕様書無しさん [2007/04/26(木) 00:35:44 ]
kmaebashi.com/programmer/object/response3.html

前橋確定

686 名前:仕様書無しさん mailto:sage [2007/04/26(木) 06:24:56 ]
夢見過ぎだぞ。高弘大丈夫か?


687 名前:仕様書無しさん mailto:sage [2007/04/26(木) 07:07:48 ]
今はまだベッドの上で長い長い夢を見てるの。
でも、きっと彼は帰ってくる…いいえ、絶対帰って来ます!
だから、今はそっとしておいて…お願いです。

688 名前:仕様書無しさん mailto:sage [2007/04/26(木) 07:08:58 ]
糖質は大変だな



689 名前:仕様書無しさん mailto:sage [2007/04/26(木) 07:19:27 ]
ねーねーおかーさん
とーしつってなあに?

690 名前:おじゃばさま ◆GxjxF3yEw6 [2007/04/26(木) 09:41:17 ]
>666
オブジェクト指向のスパゲッティー化で嫌いになった人が結構いるって事か。
レガシーCの上級者が最初に作ったJavaプログラムに多い。
しかし成功より失敗からの方が多くを学べるから、オブジェクト指向をマスターするにはいい環境だよ。

>676
ところでパラダイムって何?

>685
そうそう、このHP。
マルチインスタンスがどうの以外は問題ないと思うが、肝心のオブジェクト指向はマルチインスタンスと
言うのが意味分からない。多分インスタンスの意味が違っていると思うが、クラスやオブジェクトに
読み替えてもちょっと意味がずれてる。
他で見かけない意見だから654はHPの作者じゃないか?よかったら説明してくれ。


691 名前:仕様書無しさん mailto:sage [2007/04/26(木) 11:31:21 ]
お前の言いたいことのほうがよくわからん

692 名前:仕様書無しさん mailto:sage [2007/04/26(木) 11:40:02 ]
コンピュータサイエンス(笑)

693 名前:仕様書無しさん mailto:sage [2007/04/26(木) 14:10:34 ]
詳細設計や実装には強いが分析をあまり重視しないBooch法。
問題領域を調査する手法を提供する反面、解決領域が弱いOMT。
そして、解決領域での利便性に比べて問題領域が重視されないOOSE Objectory。
これらを1つの一貫した統一アプローチへ統合したスリーアミーゴはつくづく偉大
だと思う。残念ながらその理念を理解し使いこなしている人が少ないの現状は、
非常に残念だ。

694 名前:ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. [2007/04/26(木) 18:48:08 ]
OO厨の糞ソース読んでたら 血を抜かれたみたいにぐったり。
OOちゅ死ね

695 名前:654 mailto:sage [2007/04/26(木) 19:04:54 ]
ちがうよ、俺はそこの作者じゃない。
つか、どこに、「オブジェクト指向はマルチインスタンス」って書いてあんだよ。寧ろそこ
の作者の言ってることと逆じゃねぇか。
同一クラスのインスタンスが常に複数生成される訳じゃないだろ。例えばWinアプリ
とか作るときでも、生成するアプリクラスのインスタンスは1個だけだろ。その場合は
別に無理にクラスにしなくてもエントリポイント(WinMain)と初期化ルーチンとかメッセー
ジループを用意してやればいいんだけど、ただ全体的にOO設計で統一した方が分か
り易いし、いろいろ都合がいいからアプリケーションクラスなんてものを作って、その
インスタンスを1個だけ用意してるわけだろ。他にもマネージャクラスとか、リソース管
理クラスとか、インスタンスを1個しか使わないケースはいろいろあるわな。
つまり必ずしもインスタンスは複数生成するものじゃない。じゃなきゃ、シングルトン
とかモノステートなんか不要だからな。必要があるからそのための手法があるわけだ。

696 名前:仕様書無しさん mailto:sage [2007/04/26(木) 19:12:34 ]
文章的特徴が一緒なので、自作自演どころか単なる独り言にしか見えない。

697 名前:仕様書無しさん mailto:sage [2007/04/26(木) 19:13:39 ]
文体を微妙に変えている所がまた泣けるな

698 名前:仕様書無しさん mailto:sage [2007/04/26(木) 19:25:12 ]
つーかなにこの改行
読みにくいってレベルじゃねーぞ



699 名前:654 mailto:sage [2007/04/26(木) 19:42:42 ]
>>698
全員が自分と同じ環境で2chを見てると信じて疑わない莫迦に言われたくない。
つか、お前の改行も変だぞ。句読点をつけないのとその文体の特徴から今までの
カキコもバレバレだし。

700 名前:仕様書無しさん mailto:sage [2007/04/26(木) 19:43:58 ]
なあ、アンタ、何逆ギレしてんの?

701 名前:仕様書無しさん mailto:sage [2007/04/26(木) 20:18:23 ]
即答だなw

702 名前:おじゃばさま ◆GxjxF3yEw6 [2007/04/26(木) 20:49:11 ]
>695
俺はオブジェクト指向かどうかと、インスタンスが複数生成できるかは関連がないと思っているのだが、
そこの所はどうなのだろうか?


703 名前:654 mailto:sage [2007/04/26(木) 21:03:41 ]
インスタンスを生成できないオブジェクト指向なんて俺は使いたくない。
クラス(変数とメソッドの塊)のオブジェクト、つまりインスタンス(構造体
じゃないよ)の生成は非OOでも擬似的にやれなくもないが、よっぽどうま
くやらないと本来の主眼である保守性や拡張性、可読性を損なうことになる。
つか、そこまでやっちゃうともはやOOだろう。cのmallocはデータ領域の
生成であって、インスタンスの生成じゃないからな。おわかり?


704 名前:仕様書無しさん mailto:sage [2007/04/26(木) 21:09:48 ]
42 654 sage 2007/04/26(木) 21:06:59

 ぱんつとパンティーじゃ全然ちがうんだよ、ヴぉけ。

705 名前:仕様書無しさん mailto:sage [2007/04/26(木) 21:24:24 ]
既出だったらすまないけど、前橋和弥(ポインタ本の人)のOOP論についてはどう思う?
俺はこの人のOOP論は倒錯してると思うんだけど。

どう倒錯してるかは気が向いたら書きたいと思うけど、簡単に言えば言語のOO化の
副産物に過ぎないものをOOPの主目的と取り違えている。

その倒錯は恐らく、「図解の技術」―― 分かり易い設計図の書き方に関する技術であるOOを、
要は人間の脳へのアプローチであるOOを、「工法」―― 地震に強いとか防音といった
新しい機能を実現するための技術、要はコンピュータへのアプローチと混同し
取り違えているところから来ていると思われる。


706 名前:仕様書無しさん mailto:sage [2007/04/26(木) 21:44:14 ]
>>705
おいクソコテ付け忘れてるぞ

707 名前:仕様書無しさん mailto:sage [2007/04/26(木) 22:41:25 ]
えっとですね、おじゃばさんに質問していた件ですけど、
オブジェクト指向ってもうすこし具体的に何がいいかってのが知りたいんです。
たとえばJavaの場合だと、
newしてほったらかしのガーベジコレクタとかは確かに便利ですし、
呼び出し元関数の変数アドレスが呼び出し元で確保できてるのも便利です。
でも、これってJava言語仕様の話であって、
オブジェクト指向とは関係ないですよね。

自分が便利だと思ってるのがそのへん(プログラマがメモリ意識しなくてよい点)なので、
オブジェクト指向が便利なのではなく、Java言語(VM?)の恩恵が高いってのが
目立ってて、オブジェクト指向自体でうれしいってことが見えないんです。
今C++の業務やってるんですけどnewしてdeleteは当たり前ですし、
オブジェクト指向言語って???って感じで・・・
すみません、うまく伝えられなくって・・・

708 名前:仕様書無しさん mailto:sage [2007/04/26(木) 22:42:32 ]
あ、5行目間違いです・・
呼び出し先のアドレスが、呼び出し元でも残ってる、って意味です。。



709 名前:仕様書無しさん mailto:sage [2007/04/26(木) 23:56:48 ]
>>707
継承や多態は恩恵だと思わないか?

710 名前:仕様書無しさん mailto:sage [2007/04/27(金) 01:11:09 ]
データ構造に対するオペレーションが複雑になった時にそれをクラスの挙動
として集約できるのはそれだけでメリットじゃなかろうか、後プログラムの設計時
にあるデータ集合を取りまとめてより1段上の階層でのオブジェクト関係で取り扱う
場合にも集約し易いし、概念的な取り扱いを自然に表現する上で多態なんかも便利
だしメンテもし易い

上手く表現できないけど自分の場合そんな感じ、自分もメインはC++で使っているので
所有権は明確にしなきゃいけない事が多いけど、それでも便利だと思う>OOP機能

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言語ぐらい知ってらい!
ほら、もっと何かあるだろ?

でも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をリファクタリングしてみた。

OOは仕様変更に強く、変更の繰り返しで寧ろ構造が洗練されていく。
また、分かっている所から作り始められるので、仕様が不明確でも作り易い。
対して、非OOの場合は、熟練者が変更を見越した設計をしていない限り、
修正は困難になる。
例えば、対象DBやOSが変更になる場合でも、OOだと、少しの修正で済むが、
非OOでは変更が考慮されていない場合、バグに悩まされることになる。

・・・纏めてみても、結局何を言いたいのかよくわからんな。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
具体性も0

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の記事でも読んでろ池沼w

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 ]
元のはなし:高弘は言語も思考もカオス






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<224KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef