07/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:仕様書無しさん
07/04/27 10:23:27
なぜOOだとバカでも変更に強い設計が出来るんだ？って説明がないぞ。
どっちかっていうとOOってバカでも能書きが言えて素人をだませる、
という主張にしか見えないなぁ。
726:仕様書無しさん
07/04/27 10:48:57
>>725
同意。事象の表明を書くのは良いがそれだけじゃ意味が無いワイ
やれば誰でも実感できるレベルの話だけをながながと読まされるこっちの身にもなってみろ。
>>724よ、>>725の指摘した点に自分の考察なり見解なりを書いてみろよ。
お前の観察日記を読むために来てるんじゃない
727:仕様書無しさん
07/04/27 10:50:24
バカにOO与えると
泥沼になる
728:仕様書無しさん
07/04/27 11:32:25
>>726
>ながながと読まされるこっちの身にもなってみろ。
おじゃばファンでもないのに、なんで読むのさ。
729:仕様書無しさん
07/04/27 12:10:29
ぶっちゃけ日記はblogでやってろってなレベル＞アホコテ
730:726
07/04/27 12:18:56
>>728
そりゃぁ。
>ながながと読まされるこっちの身にもなってみろ。
とレスするためさ
731:仕様書無しさん
07/04/27 13:41:25
>>724をリファクタリングしてみた。
ＯＯは仕様変更に強く、変更の繰り返しで寧ろ構造が洗練されていく。
また、分かっている所から作り始められるので、仕様が不明確でも作り易い。
対して、非ＯＯの場合は、熟練者が変更を見越した設計をしていない限り、
修正は困難になる。
例えば、対象DBやＯＳが変更になる場合でも、OOだと、少しの修正で済むが、
非ＯＯでは変更が考慮されていない場合、バグに悩まされることになる。
・・・纏めてみても、結局何を言いたいのかよくわからんな。ＯＯの利点を強調
したいのか、非OOでもうまく設計されていれば問題無いと言いたいのか。
732:仕様書無しさん
07/04/27 14:26:52
くだらないあげあしとりばっか
あきらかにおじゃば以下
733:仕様書無しさん
07/04/27 14:52:07
>>725-726
正論。
>>724は信念を語っているだけで、
その信念の合理性を客観的示す事ができない。
つまり宗教なんだ
734:仕様書無しさん
07/04/27 14:59:21
>>733
そんなもの簡単に示せるわけがない
かいつまんでいうと、あげあしとりｳｾﾞｴ
735:仕様書無しさん
07/04/27 15:06:16
全体を批判することをいつから「あげあしとり」と呼ぶようになったんだ。
○○以下 という発言は「自分は○○です」と言っている様に読めるぞ。
かいつまんでいうと、ｵﾏｴが黙れ
736:仕様書無しさん
07/04/27 15:18:33
>>735
いや黙るべきはお前だ
対案のない批判なんか必要ない
737:仕様書無しさん
07/04/27 15:34:05
>>733
> >>724は信念を語っているだけで、
> その信念の合理性を客観的示す事ができない。
>>734
> >>733
> そんなもの簡単に示せるわけがない
> かいつまんでいうと、あげあしとりｳｾﾞｴ
信念の合理性を客観的に示す事ができない＝狂信者決定
738:仕様書無しさん
07/04/27 15:43:52
>>737
おまえの信念と客観的な合理性の提示よろ
739:仕様書無しさん
07/04/27 16:28:29
信念：
狂信者に対し、自分の信念を語る暇などない。
客観的合理性：
狂信者とは、己の考えの根本的正当性の確認努力や
他人に対する合理的説明努力を怠ったまま、
自分の考えが絶対正しいと主張する輩に対する
蔑称である。
そのような人物と時間を費やし議論を重ねても、
虚しい言葉が行き来するのみで
相互理解は極めて難しい。
従って、狂信者に対しては何も語らず、
ただ黙殺する事が、時間を有効に使う秘訣である。
740:仕様書無しさん
07/04/27 16:40:14
>>739
黙るっていったからには絶対黙れよ。
741:仕様書無しさん
07/04/27 16:56:19
次スレは
【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発儲はなぜ黙らないの？★
ということでよろしいか？
742:仕様書無しさん
07/04/27 17:02:11
アンチでも信者でもいいけど、なんか中身のあるレスすれば？
あきらかにココ電以下
743:仕様書無しさん
07/04/27 17:02:11
あまりに>>724が哀れだから >>724を訂正してやろう。
1. OOであろうと構造化であろうと、下記二点
(1)高凝集性：プログラムの構成要素(変数,関数,etc.)の出現範囲を局所化する
(2)疎結合性：局所的なまとまりに対し適切なインタフェースをつける
を「実現」すれば、
「ある範囲」の変更要求に対しては、変更の影響を局所化でき、
拡張性/保守性の高い、いわゆる「変更に強い」プログラムを構築できる。
2. OOは、その種の局所化とインターフェース化について、
構造化よりも適切な道具を提供しており、
「それらの道具を適切に用いれば」、
上記二点を実現する際の設計負荷を和らげる事ができる。
問題は1(1)(2)の実現方法、2の道具の適切な使用方法にある。
OOであれば、熟練しなくとも1(1)(2)、2を実現できるなどというのは
妄言に過ぎない。
744:仕様書無しさん
07/04/27 17:04:50
>>724
高弘さぁ、レポート書くの苦手だろ。
お前の文章って怨念がにじみ出ていて、
全然客観的じゃない。
「理系の作文技術」でも読んで、レポート書く練習したらどう？
745:仕様書無しさん
07/04/27 17:10:24
おまえアホだろ
おじゃばは少なくとも「OOの方が低コスト」と主張している。
おまえの主張はまとはずれ。
746:仕様書無しさん
07/04/27 17:11:26
ことばたらずだった。
「変更に強い」プログラムをつくるためのコストな。
747:仕様書無しさん
07/04/27 17:12:28
>>743
客観性一切なし。もう黙れ。
748:仕様書無しさん
07/04/27 17:13:19
で>>743に要約したみたいな30年前の素朴な考え方じゃ
とっくに行き詰まりが生じていて、
だから落ちこぼれ業務システムの分野でも
DIコンテナやらサブジェクト指向が取り沙汰されてるんだろ。
749:仕様書無しさん
07/04/27 17:13:57
>>743
具体性も０
750:仕様書無しさん
07/04/27 17:14:16
>>747
とりあえずお前がバカだという事はよく判った。
>>747は罵詈雑言の口先野郎としてスルーする。
751:仕様書無しさん
07/04/27 17:14:53
もしかして、今ここで連続レスしてるのって、
池沼の方？
752:仕様書無しさん
07/04/27 17:16:48
>>748
アスペクト指向、サブジェクト指向はなかなか面白いよね。
業務システムを手続き処理に還元してグダグダにしちまう誰かとは
頭の出来が違うと思った。
753:仕様書無しさん
07/04/27 17:17:01
>>748
だから、の使い方が意味不明。
DIコンテナとサブジェクト指向が、どう行き詰まりを解決するのか書け。
754:仕様書無しさん
07/04/27 17:17:56
>>752
知ったか乙
755:仕様書無しさん
07/04/27 17:19:13
>>752
どこからアスペクト指向が出てくるのやら。
DIコンテナとアスペクト指向に、なにか関係があるとでもおもっているのだろうか。
知ったかJava厨乙
756:仕様書無しさん
07/04/27 17:19:31
バカ相手に講釈するのは時間の無駄。
お前お得意のゴッグルさんで@ITの記事でも読んでろ池沼ｗ
757:仕様書無しさん
07/04/27 17:20:58
高弘ってテンパるとすぐ罵詈雑言が出てきて、
元の話を棚上げしてくるからからかい易いな
758:仕様書無しさん
07/04/27 17:22:29
元のはなし： あげあしとりｲﾗﾈ
759:仕様書無しさん
07/04/27 17:23:22
>>756
知ったか確定乙
760:仕様書無しさん
07/04/27 17:23:37
元のはなし：高弘は言語も思考もカオス
761:仕様書無しさん
07/04/27 17:26:14
糖質からかうとおもしれぇな
デザパタ、リファクタ、構造化しか持ちネタねぇのかよターコ
762:仕様書無しさん
07/04/27 17:40:37
糖質の脳内では自分の疑問点を説明してくれない人は
全部「知ったか」と変換されます。
763:仕様書無しさん
07/04/27 17:42:43
闘牛状態だなｗ
764:仕様書無しさん
07/04/27 17:55:03
【レス抽出】
対象スレ： 【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★6
キーワード： 低コスト
抽出レス数：1
>>745はおじゃばの脳内主張をエスパーできるサイコ仲間かｗｗｗｗ
765:仕様書無しさん
07/04/27 18:16:59
元の話に出てこない単語が
いきなり飛び出すのは
このスレが糖質の自作自演だから
766:仕様書無しさん
07/04/27 18:54:19
野次までつまらなくなってきた
OOわからないなら他行けよ
767:仕様書無しさん
07/04/27 19:00:08
サイコをリアルタイムでからかえる
とても便利なインターネッツ
768:仕様書無しさん
07/04/27 19:18:16
DI： クラスの疎結合実装に役立つ
AOP： 個々のクラスが提供すべき機能を
複数の側面に分割して記述する事が可能になる。
結果として通常のクラス設計では複数のクラスに散らばってしまう
横断的関心事の局所化が可能になり、拡張性/保守性を高める事ができる。
769:仕様書無しさん
07/04/27 19:51:51
サブジェクト指向ってなぁに？ぐぐったら判るの？自分はわかんなかったなぁ。
#ぐぐっったら何でも判るんだったら「オブジェクト指向」も遭難じゃないの？
770:おじゃばさま ◆GxjxF3yEw6
07/04/27 21:16:17
>725
バカでも変更に強い設計が出来るなんて言っていない。
そのシステムや業務の経験が浅いSEでも、OOをマスターしていれば、変更に強い設計が出来ると言っている。
>726
「やれば実感出来る話」を長々と書くのは、やらない人が多いからだ。
>731
その解析は正しい。
OOの利点を説明したのが前半。しかし非OOでもうまく設計されていれば問題無い言うのが後半。
OOの利点と、非OOとの違いを聞かれたのでそう答えた。
俺はOOで設計すれば全てOKなどと言うつもりはない。
「仕様が未確定で変更が多い」物にはOOが向く。逆に言うと「仕様が確定していて変更が少ない」なら
非OOの方がいい場合も多い。例えばドライバやハードに近いプログラムなどだ。
771:仕様書無しさん
07/04/27 21:35:07
いや、だから
バカでも能書きたれて素人をだませる
という主張に見えた、んじゃないの？
依然としてなぜ仕様変更に強い設計が経験が浅くてもできるの、
と言う説明が無いんだけど？
772:仕様書無しさん
07/04/27 21:39:02
ヒューリスティクスって知ってるか？
773:仕様書無しさん
07/04/27 21:40:52
また自作自演でレベル低下かｗ
774:仕様書無しさん
07/04/27 21:42:20
「やってみたらそうだったから」って話？
んなもん聞いてないだろ、ふつー。
775:おじゃばさま ◆GxjxF3yEw6
07/04/27 21:42:33
>733
宗教でも何でもない。
Pro*Cのソースをpostgres用に修正するのと、JDBCのソースをpostgres用に修正するのはどちらが楽か？
設定ファイルに暗号過機能を追加するに、C構造化ソースと、JavaOOソースではどちらが楽か？
やった事のある人なら良く分かるだろう。
>743
実現法方については、すでに具体的なコーディング方法を書いた。
OOなら熟練しなくても良いなど言っていない。その業務には熟練しなくてもいいが、OOの習得は必要。
前にも書いたが、OO方針に従って、1～2年のプログラミング経験が必要。
>745
「OOの方が低コスト」などとは言っていない。
変更を繰り返す場合は、トータル的にOOの方が低コストになるが、初回の作成や変更の少ないプログラム
では、構造化の方が低コストになる。
776:仕様書無しさん
07/04/27 21:45:08
言い訳開始。
777:おじゃばさま ◆GxjxF3yEw6
07/04/27 21:51:05
>771
「経験が浅い」って言ってるのは「プログラミング経験」じゃなくて、「業務経験」。
業務経験が浅くてもOOなら変更に強いプログラムを作れると言ったが、
OOのプログラミング経験が浅くても変更に強いプログラムが作れるとは言っていない。
778:おじゃばさま ◆GxjxF3yEw6
07/04/27 21:55:17
>774
実例じゃなくて論理を知りたいのか？
長く言うと読まなそうなので短く言うと、抽象化されていると交換が容易なのと、継承を使うと親クラスには
修正が入らないので、ソースが壊れないからの2点が大きい。
779:仕様書無しさん
07/04/27 21:57:04
＞業務経験が浅くてもOOなら変更に強いプログラムを作れる
だから、それがなぜかがねえだろ？
だれも「プログラミング経験」の話なんかしてない。誰だ？
逆に「プログラミング経験」があれば業務経験が浅くても
OOなら分析・実装しやすい、のなら話はわかりやすいだろ？
それがテクニックじゃないのかよｗ
780:仕様書無しさん
07/04/27 21:58:42
怒濤のようなアナクロニズム
781:仕様書無しさん
07/04/27 22:02:08
>>777
大当たりおめでとうｗ
なんだかOO利点を挙げようと頑張っているけど1～2年の経験は1～2年の経験だ
OOに限らず何事も3年続けてやっとその世界の入り口にたどり着く
3年続けられないならその世界はあきらめろ
782:仕様書無しさん
07/04/27 22:03:05
もうちょっと話に説得力を持たすための勉強をしろよ、おじゃば。
もうOOとかJavaは習得したんだろ？いいかげん日本語のほうをちゃんとｗ
ま、がんばんなよ。
783:仕様書無しさん
07/04/27 22:15:03
パソ通時代のログ読んでるのかと錯覚した
784:仕様書無しさん
07/04/27 22:18:04
涙はこれで拭いとけ（k
785:仕様書無しさん
07/04/27 22:36:46
こんな所で自作自演して一体誰が得するんだろうと思った
786:仕様書無しさん
07/04/27 23:02:37
自己満足だろ
787:仕様書無しさん
07/04/27 23:29:50
ジェダイのライトセーバーと同じで
選ばれし者だけがオブジェクト指向を活用できる。
だから本当の意味で流行らないわけだ。
そのことに早く気づこうな。
788:仕様書無しさん
07/04/27 23:58:34
おじゃばよフォースを使え。
789:仕様書無しさん
07/04/28 00:07:22
オセロの石やポットの水をオブジェクトにしているようでは
フォースをまとうことは叶わぬわ。
790:仕様書無しさん
07/04/28 00:25:25
どうしてみんなページ制御が下手なの？
一覧表のページめくりぐらいちゃんと作れなきゃ。だめよ。
791:仕様書無しさん
07/04/28 00:36:54
恥ずかしくなっちゃった？
792:仕様書無しさん
07/04/28 00:39:06
ページの概念をクラスにする。汎用的に使える。
793:仕様書無しさん
07/04/28 00:57:24
えっと、>>724のおじゃばさんの文面で、ちょっとヘンだな～って思うところがあります。
OOだと変更が入れば入るほど、洗練されていく、とありますけど、
なぜそうなるんですか？
これはOOの考え方によるものですか？それとも言語仕様も関わりますか？
コーディングって量が少なければ少ないほど、
丈夫なプログラムになるはずなんで、変更が増えるほど良くなる、ってのが分かりません。。。
あと、これはちょっと違うかな～って思うのがあります。
C言語だとDBが変わると修正が大きくJavaだと小さい、とありますが、
各DB＋言語で使用するライブラリを、DBの違いを吸収した関数を用意しておけば、
関数の呼び先の処理が変わるだけで言語の違いは無いと思うんです。
C言語で、Accessの接続（ODBCあたり？）→Oracleの接続（orlon関数、、かな？）
に変わったとしてもDB_Connect()って関数を呼ぶように作っておけば、
修正はこの関数だけで済みますよね？
バインド変数を使う・使わないとかはDB仕様なのでちょっと変更は必要かもしれませんけど、
Javaでも同じですし・・・
これはオブジェクト指向か構造化かの違いではなく、
単にセンスや考慮の話だと思うんです。
最初の洗練される、ってのも同じ話かな～って思ってしまって・・・
やっぱりOO分かってないんでしょうね・・・
あぅぅ、長くてすみません；；
794:仕様書無しさん
07/04/28 01:02:09
あとですね、
OOだと仕様不明点があって作れる、とありますが、
本来のOOってのはそれを設計段階で吸収し終わって、
それをそのままコーディングできるのが強みだと思ってたんですが、
これもやっぱり間違ってますか？・・・
OOとXPのプロトタイプは別の話のはずなんで、
なんか話がいろいろなってる印象があって・・すみません。。
795:仕様書無しさん
07/04/28 01:15:27
そろそろ我々は設計はヒューリステクスだという事実を認めなければならない。
あらゆる設計に通用する手法などないということを認めなければならない。
最適解など存在しない。しかし、限りなくそれに近づけることはできる。
人間の弱さを認めること。許すこと。許されること。誠意を示すこと。誠意に
保障などないということを認めること。それでも涙しながら助け合うこと。
時に厳しく、時に優しく、諭すこと。切り捨てること。柔軟に対応すること。
我々はクリプトナイトを抱えたスーパーマンだということを、そして簡単に
裏切れるということを認めなければ。コンピュータを相手にしながら、結局、
人間を相手にしているのだということを、認めるしかないのだ。
796:仕様書無しさん
07/04/28 01:23:13
最適解どうのこうのいうような事してないんだろｗ
797:仕様書無しさん
07/04/28 03:46:06
>>793
多分、モジュールとして分割されている事とOO的な分割の
意味を混同しているんだろうと思われる。
たしかに、バイナリレベルで切り離されていれば
呼び出し等は何でも一緒になる。
ペナルティとしては細かいやり取りには向かないって事。
この辺は難度の高いプログラムを組まないとなかなか実感できないと思う。
ソースが洗練云々はプログラムの部品化(つまり共通化)が進むので
開発工程そのものがテスト工程も兼ねる事になるので品質が高くなるという事。
この辺も難度の高いプログラムを組まないとなかなか実感できないと思う。
798:仕様書無しさん
07/04/28 03:47:02
もうちょっとだけ追加説明をしてみる。
10000ステップの処理に追加処理として10000ステップあったとする。
べたCだと極端な話だけど
10000ステップコーディングした後に
10000*10000通りのテストが待っていて細かくチェックするしかなくなる。
これがOOPだと
元の10000ステップを修正して＋10000以下のコーディングをした後に
元の10000＋10000以下のテストをする事になる。
たいした違いがないように思えるが
これを繰り返すとCだと飽和していくけどOOPだと逆に収束していく。
要はOOPはステップ数を横軸にした場合
コストが収束に向かう関数曲線を描くけど
非OOPは飽和に向かう曲線を描くって話。
799:仕様書無しさん
07/04/28 03:48:23
おじゃば氏の示している内容はOOPを使って開発経験者なら
誰でも感じる事でむしろ当たり前の事が書かれている。
入門的な書籍等でも大体同じ事は書かれている。
それに食いついている人は実際にはあまりOOPを
扱ってない開発者なのだろう。
800:仕様書無しさん
07/04/28 04:04:49
>10000+10000うんぬん
どうしてOOだとそうなるのか、説明よろしく。
経験んちゃら、とかじゃなくて「わからなくて質問」してるのがいるんだし、
書籍にあるんなら、どの本か教えてやれよｗ
誰も食いついてなんかいねーよ、説明してくれと言ってる。
801:仕様書無しさん
07/04/28 04:20:27
>>800
お前、無知なのに生意気だなw
プログラムの部品化(つまり共通化)が進めば
テストされる回数もあがるだろ。
プログラムの品質はテスト回数に比例してあがる。
大規模openソースと企業のソースで適当に調べればわかる。
書籍は俺もかなり前の事なので、よく覚えていない。
お前はいちいち読んだ本の名前を覚えているのか?
初心者向けの本を適当に読めば書いてあるだろw
802:仕様書無しさん
07/04/28 05:03:29
読んだ本くらい覚えてるだろ、普通。この本のココを読んだらわかった、とか。
それ以前にどうして構造化がだめでOOだと部品化が進むのよ？
そんなにいいもんなら以下スレタイ、という話じゃないのか。
で、それは「どいつもこいつもOOを勉強しないから」とか
「どれだったか本に書いてあるもん」とか「おっきなとこでやってるから」
「やってみれば誰でもわかるよ」位の話を長文で技術用語(ﾌﾟ垂れ流しでやるから
「それってなんて宗教ｗ」「どこの壺売りよｗ」言われるんじゃないか。
803:仕様書無しさん
07/04/28 07:04:24
レベルの低い負け犬が30年前の概念を
独りで弄って悦んでる状態か
どうしようもねぇな
804:仕様書無しさん
07/04/28 07:05:52
> 食いついている人は実際にはあまりOOPを
> 扱ってない開発者なのだろう。
局所化と隠蔽(インタフェース化)
という二言で済む話を延々やってろキチガイ
805:仕様書無しさん
07/04/28 07:10:51
＋αがあるだろ
部品化がOOの特徴とかいう陳腐な＋αだがｗ
806:仕様書無しさん
07/04/28 07:25:22
>人間の弱さを認めること。許すこと。許されること。誠意を示すこと。誠意に
>保障などないということを認めること。それでも涙しながら助け合うこと。
>時に厳しく、時に優しく、諭すこと。切り捨てること。柔軟に対応すること。
元々頭が弱い奴は、プログラミングの現場に来なければいいのに、と思う。
807:仕様書無しさん
07/04/28 08:19:55
局所化と隠蔽だけで行き着くところはオブジェクティブスパゲッティｗ
808:仕様書無しさん
07/04/28 08:44:47
ＧＷ中も糖質は２ちゃん張り付きなのか
809:仕様書無しさん
07/04/28 09:02:33
感性を形にできる。それがオブジェクト指向。
感性の良し悪しが、そのまま形になる。それがオブジェクト指向。
810:仕様書無しさん
07/04/28 09:07:01
文よりも図の方が直感的で分かりやすい。
つまり構造化よりもオブジェクト指向の方が直感的で分かりやすい。
811:仕様書無しさん
07/04/28 09:15:21
まずは構造化モデリングが正しく行えるように勉強しなさい。
オブジェクト指向はそれが出来るようになってからな。
812:仕様書無しさん
07/04/28 09:29:57
達人を目指すならアセンブリコードを学ぶこと。
コンパイラの勉強をすればアセンブリコードの知識も身に付くだろう。
グローバル変数、ローカル変数、スタック、ヒープメモリやアドレッシング、割り込み、スレッドなどなど
基本的な概念が正しく身に付く。
そうすることにより、今まで見えなかったり、感じなかったことが驚くほど分かるようになる。
オブジェクト指向もな。
813:仕様書無しさん
07/04/28 09:35:12
ソフトウェア設計はエンジン設計と同じだ。
部品一つ一つに情熱を注げ。美しさを追求しろ。
814:仕様書無しさん
07/04/28 10:04:45
>>812
やっぱドラゴンブックがいいの？
815:仕様書無しさん
07/04/28 11:24:10
この辺りから入門しなさい。
・URLﾘﾝｸ(www.atmarkit.co.jp)
・スモールコンパイラの制作で学ぶプログラムのしくみ
816:仕様書無しさん
07/04/28 11:51:49
ドラゴンはある程度分かってからな。
817:仕様書無しさん
07/04/28 12:05:12
こないだ中田育男教授の最終講義があったね。
「コンパイラとつきあって40年」
818:仕様書無しさん
07/04/28 12:12:12
入門用
・いまどきのプログラム言語の作り方
819:仕様書無しさん
07/04/28 12:35:39
いちおうマジレスしとくと
コンパイラの勉強なんてのは学生時代に済ましとくべきものだよ。
820:仕様書無しさん
07/04/28 12:37:48
笑えるじゃないか。
現在進行形でコンパイラのおべんきょしてる
40過ぎのじじぃが知ったかぶってる姿
821:仕様書無しさん
07/04/28 12:38:56
おまいするどいなｗ
822:仕様書無しさん
07/04/28 12:44:15
いちおうマジレスしとくと
オブジェクト指向の勉強なんてのは学生時代に済ましとくべきものだよ。
823:仕様書無しさん
07/04/28 12:48:06
うーんとね、
おいらの場合は学部３年の計算機実習で
その記事と同じ電卓コンパイラ＆VMやったね。
センセはソフトウェア・ツールの翻訳もやってた
木村研出身のひと。
再帰下降文法でうんちゃらかちゃらなんて恥ずかしいんで、
当時ちょこっといじってたPrologライクに、
演算子の優先順位と結合性決めて、演算子順位文法で提出したな。
趣味ではあとLisp VMとLisp コンパイラ。アーカイブっつう雑誌見て手作り。
Scheme VMは、Dylanのひとが作ってたX Schemeでおべんきょ。
Smalltalk VMあたりは・・・うーん・・・当時はVM仕様は判っても、
その上にのっかるImageがどうしようもなく入手困難だったから諦めたなぁ。
Smalltalk/V と GNU Smalltalk で雰囲気を想像する、という・・・
824:仕様書無しさん
07/04/28 12:52:01
いや思い違いか、
学部二年だな、そんな初心者勉強は。
学部三年ともなると専門教育が忙しくなって、
そんな他分野のお遊びに首突っ込む暇はなくなる、という
825:仕様書無しさん
07/04/28 12:53:32
>>820
50後半なんだな。
826:仕様書無しさん
07/04/28 12:55:08
誰が？
827:仕様書無しさん
07/04/28 13:01:07
いずれにせよ、向学心旺盛なのは誉めるべきだけど、
その手の専門課程では習ってて当たり前の事について
ハッタリこいてウダウダ言い出すと新人さんに舐められるよ
828:仕様書無しさん
07/04/28 13:05:58
でも、このスレでオブジェクト指向についての理解度を見てると
専門課程で何を学んできたのか疑問？？？
829:仕様書無しさん
07/04/28 13:07:28
マジッすか？
うちの大学の情報は院行かないとオブジェクト指向までやらないみたいだよ
それともプログラミング関連なんて独学でやってて、学部二年までにやっとくべきって事？
確かに中高ぐらいでC++やJavaの機能駆使して実用アプリつくりまくってる人たちが居ることから
考えるとそれぐらい出来て当たり前という気もするけど
830:仕様書無しさん
07/04/28 13:07:52
そうね。それはね。本で学んだ表層の知識だけで理解したと勘違いしてるだなぁ。
831:仕様書無しさん
07/04/28 13:10:02
技術を極めるには、師の元でOJTが一番だろ。
832:仕様書無しさん
07/04/28 13:11:21
>>828
それはお前の説明が基礎的な部分で変だから
とても低いレベルの突っ込みが入っているだけだろう。
レベルを高くしたいなら、基礎的な部分の説明は省いて
もっとレベルの高い話に専念するというのも一つの手だ。
まあお前が説明が下手糞なだけで、きちんとした基礎ができている
という仮定の上の話だがｗ
>>830
意味不明抽象煽り乙
これだから頭が悪い奴は
833:仕様書無しさん
07/04/28 13:11:39
マスターとパダワン。
834:仕様書無しさん
07/04/28 13:11:47
完璧に理解せんでもOOPの恩恵に肖れるだけで十分だと思うけど
理論ってそういうもんでしょ？
何を以って理解したとするのか
835:仕様書無しさん
07/04/28 13:12:10
ここまでのまとめをオブジェクト指向でよろ
836:仕様書無しさん
07/04/28 13:13:39
そんな下らない話題は誰も興味を持たない。
837:仕様書無しさん
07/04/28 13:13:42
ムキになるなよ。勉強不足が伝わってくるよｗ
838:仕様書無しさん
07/04/28 13:14:25
なんだ今日の粘着当番は知能が劣悪な池沼の方か
839:仕様書無しさん
07/04/28 13:15:06
ロジカルシンキングと同じ流れだな
誰でも無意識で行ってる事に関心を無駄に注いで、意味無く難しくみせてるだけ
もっと力抜けよ
840:仕様書無しさん
07/04/28 13:15:54
OOPの恩恵ってか。OOPで迷惑掛けられてる方が圧倒的に多いちゅうの！
841:仕様書無しさん
07/04/28 13:16:03
池沼の書き込みはひたすら無意味
バカなんだから書き込みやめればいいのに
842:仕様書無しさん
07/04/28 13:17:42
それは恩恵に気づいてないだけだろ
短所って長所より目立つもんだし
843:仕様書無しさん
07/04/28 13:19:00
>>842
学生さんですか？
仕事はそんなにあまくないのよ。
844:仕様書無しさん
07/04/28 13:20:37
50代後半でこのグダグダかよ
845:仕様書無しさん
07/04/28 13:21:24
例えば、Gap Bufferを知ってる方居ますか？
もし知らなかったら、もっと勉強したほうがいいよ。
846:仕様書無しさん
07/04/28 13:23:30
なんでエディタのデータ構造をそんな自慢したがるんだ
847:仕様書無しさん
07/04/28 13:24:30
一生懸命、検索中。。。
848:仕様書無しさん
07/04/28 13:25:43
いやさ、なんでそんな瑣末な知識を自慢しようとしてるの？って聞いてるの。
Emacsの構造に興味を持った事がある人なら大抵知ってるだろ
849:仕様書無しさん
07/04/28 13:25:52
>>843
詳しく
趣味レベルのアプリだとCからC++に移行して
かなりバグが減ったんだけど、その程度のメリットなんて雀の涙
ってほど業務用ソフトウェアってヤバイという事ですか？
850:仕様書無しさん
07/04/28 13:26:31
OJTでダメな先輩に洗脳されちまった廃人のテクニック自慢なんて
えてしてそんなレベルだ
851:仕様書無しさん
07/04/28 13:29:08
ここの記述は謎だな。
URLﾘﾝｸ(www.kmonos.net)
「時々「行=GapBufferOf文字、文書=LinkedListOf行」で使う、 という解説を目にすることがあるんですけど、 その構成は正直意味がわからんです。」
とか書きながら、説明の方はしっかり行＝GapBufferOf文字になっているというグダグダさ加減
852:仕様書無しさん
07/04/28 13:33:14
>>851
おまいが理解できていないことに気づかないか？
853:仕様書無しさん
07/04/28 13:34:03
>>848
検索乙
854:仕様書無しさん
07/04/28 13:36:21
なんだ理解できてない奴が表面上煽ってるだけか。
バカの相手して損したぜ
855:仕様書無しさん
07/04/28 13:39:42
ＧＷは楽しいね
856:仕様書無しさん
07/04/28 13:48:02
古い話題になるが
羽生田さんのAOSD解説はなかなか的を得ていたな。
ヤコブソンがユースケースをアスペクトと解釈してうんたらかたら。
違和感はない。
M$萩原さんのSoftware Factory解説の中のサブジェクト指向解説、
斜め読みした時はなかなかいい線行ってると思ったんだけど、
よくよく読んでみると何を言ってんだかわかんねぇな、相変わらず。
彼の話はいつも、断片的には素晴らしい事を言っているみたいな印象を
与えるんだけど、全体構造が不安定っつうか、全体構造の肝が
細部の仔細な事柄に依存していて、正しいかどうか判定し難いという・・・。
857:仕様書無しさん
07/04/28 13:52:16
萩原氏流のサブジェクト指向っつのは、
OOのドメインクラス＋FDDのフィーチャー
みたいな感じで不変部分と可変部分を分けましょうという話。
オブジェクト指向の業務システムは
処理がオブジェクトなんだぁ～！！！！なんて負け犬よりは
よっぽどまともに見える。
858:仕様書無しさん
07/04/28 14:02:29
楽しくないよ。
859:仕様書無しさん
07/04/28 14:10:13
マトモである事の方が重要だ
860:仕様書無しさん
07/04/28 14:23:12
楽しくてマトモであることが大切
861:仕様書無しさん
07/04/28 14:33:47
>>802
俺は覚えてない。
どうでも良いことはすぐに忘れるので
内容だけが頭に残るだけ。
それもそのときに重要と感じた部分以外は忘れてそうだけどな。
本のタイトルと情報のリンクは長くても一年前位までだな。
同じ内容が複数の本に載ってたりするのが
デフォルト状態だから覚える事に意味を感じない。
862:仕様書無しさん
07/04/28 14:37:28
どうでもいい話ばっかだな
863:仕様書無しさん
07/04/28 14:46:10
結局オブジェクト指向は、デザインパターンのセンスだけ修得すれば桶？
864:仕様書無しさん
07/04/28 14:46:35
>>804
数回書き込んだだけだろ。
食いついてくんな、キチガイ。
早く病院でカウンセリングを受けろYO!!
>>805
＋αを認めてるなら文句言うなYO!!
OOは魔法じゃないんだYO!!
>>813
同意。
別に俺はOO厨な訳じゃないので書いておく。
プログラムは効率のよい感じに書いてあれば
非OOPでも別に良いと思ってる。
それがOOPだといくらかしやすいよっていう簡単な話。
だから当然だけど非OOPで書き殴ったような糞コードを
書いてる人がOOPで書いても問題は解決しない。
865:仕様書無しさん
07/04/28 14:47:45
オブジェクト指向とは、処理対象に処理方法を割り振る方法論。
サブジェクト指向とは、オブジェクト指向を前提としつつ、
処理がオブジェクトに分散してしまう欠点を克服するために、
処理の主題(サブジェクト)に沿った処理記述を再導入しようという試み。
オブジェクトとサブジェクトは、AOPのweavingによって関連付ける。ｗ
866:仕様書無しさん
07/04/28 14:49:34
と、まあコレくらいの話ができないと21世紀らしくねぇんだな。
867:仕様書無しさん
07/04/28 14:51:07
>>865-866
そのレベルの話はもう2～3年前からさんざん行われているだろ。
このスレだけ30年前にタイムスリップしてるようだが
868:仕様書無しさん
07/04/28 14:51:44
サブジェクト指向ってコンサルが入れ食いしそうなネタだね。
おもしろそう。
869:仕様書無しさん
07/04/28 14:56:42
>>863
結局何をしたいかによるんじゃないか？
それによって利点も違ってくるだろうし。
継承と多態と隠蔽が基本で後は使い方のテクニックだよ。
あと、基本を深く理解するために概念等を深く学ぶ
必要がある場合のある人もいるし、そうじゃない人もいるってだけ。
例で言えば、一つ数式があっったとする。
ある人は見ただけで理解できて、派生の数式も頭に思い浮かぶ。
ある人は派生の数式を見たときに元の数式も理解する。
ある人は問題集を解きまくったときに理解する。
オブジェクト指向ってそういうもんだと思うな。
870:仕様書無しさん
07/04/28 14:56:52
バカコンサルに関わるとこのあたりの話は全然できなくなるわけだが。
バカコンサルに関わる前に俺がやろうとしていた仕事
URLﾘﾝｸ(www.research.ibm.com)
871:仕様書無しさん
07/04/28 15:05:36
>>865
>>866
何がしたいのかわからないけどw
効果的と思うなら自分で実証してレポートでも
あげれば良いんジャマイカ？
>>867
少なくてもC++のコンパイラは何回も改定されていて
今の状態に落ち着いたのは数年前レベルだよ。
C++仕様事態が落ち着くのに時間がかかっている。
872:仕様書無しさん
07/04/28 15:07:47
初心者はデザパタ勉強したほうが近道なんでしょうか？
873:仕様書無しさん
07/04/28 15:13:31
>>870
最初はOOPも効果が懐疑的でなかなか浸透しなかったもんだよ。
そういう中を先人達が開拓して進んでいった訳だから
お前も突き進めばいいんジャマイカ？頑張れ～
と無責任に応援するw
874:仕様書無しさん
07/04/28 15:14:33
無理だよ。こいつニートだもんｗ
875:仕様書無しさん
07/04/28 15:16:48
>>872
近道です。デザパタでセンスを磨いてください。
876:仕様書無しさん
07/04/28 15:18:08
>>872
書籍：オブジェクト指向のこころ が近道への近道です。
877:仕様書無しさん
07/04/28 15:18:20
バカコンサルの手にどんな重要な指摘をしても通じない。だからバカはバカなまま一生を終えるしかない。
878:仕様書無しさん
07/04/28 15:18:38
>>872
本当に本物の初心者なら、どこから手をつければいいかは迷いどころだな。
デザパタから入るのだけは違うけどw
今のところ、言えるのはこんなもんかな。
879:仕様書無しさん
07/04/28 15:22:03
初心者はアンチパターンからw
880:仕様書無しさん
07/04/28 15:23:13
>>878
デザパタって常套手段を集めたものなのでしょう？
そこから手を広げるってのは間違ってないっと思うんですが
デザパタから入るのが大間違いって理由を教えてください
881:仕様書無しさん
07/04/28 15:24:48
>>878
デザパタから入るのは正解です。安心してください。
なんでもそうですが、スタイルを真似ることから始めるのは良いことです。
882:仕様書無しさん
07/04/28 15:27:55
>880
どうしてそうなっているのがよいのか、も分からずにスタイルだけ真似してる奴は
所詮偽者
ブランド品が買えない貧乏人w
883:仕様書無しさん
07/04/28 15:30:22
>>880
間違ってないと思うなら、そうすればいいじゃない。
貴方の情報が足りないので明確な事は言えない。
一つ例をあげると、本物の初心者には情報処理の基本や
コンピューターのしくみの理解も重要。
884:仕様書無しさん
07/04/28 15:34:59
>>881
そんなことはない。
初心者がプロ仕様の方法や道具を使っても
なんちゃってなだけで上達にはよくない。
学習という意味においては
段階によっていろいろと使い分けるべき。
885:仕様書無しさん
07/04/28 15:35:52
私の知識の程度としては
独習C、独習C++、STL標準講座と一通り軽くさらってきた程度です
計算機の知識としては教養程度の情報リテラシー、初歩的な情報数学を修めた程度
そろそろOO用の機能を効果的に利用して設計することも勉強したくなってきたので
デザパタに目を付けたのですが間違ってますか？
886:仕様書無しさん
07/04/28 15:48:25
>>885
学生さんみたいですね。
基本が抑えられていれば、特にやり方で問題は起きないのではないでしょうか？
887:仕様書無しさん
07/04/28 15:51:55
>>885
あと、そろそろ専門の知識の習得にも時間を割くと良いと思います。
進路によって必要な知識はかなり異なります、老婆心ながらですが…
888:仕様書無しさん
07/04/28 15:55:33
またデザパタか
高弘って難しい事言われて戸惑うと
すぐデザパタ議論を始めるからバカバカしいんだよ
889:仕様書無しさん
07/04/28 15:57:22
結論：>>1の近辺を除き、オブジェクト指向開発は普及している。
>>1の近辺でオブジェクト指向開発が流行らないのは、
>>1の性格と頭に問題があって、まともな人間が寄り付かないから。
終了
890:仕様書無しさん
07/04/28 15:57:40
>885
べつにいいんじゃねの？
「ハンマーを持った人は全てが釘に見えて叩きまくる」症候群にさえ気をつけてれば
1画面に収まらない"ハローワールド"には笑えない...
891:仕様書無しさん
07/04/28 15:58:55
>>889
とても判りやすい結論だ
おかしいと思ってたんだよね
彼の居るスレに限って、
いつも世間とずれた話ばかりしているから
892:仕様書無しさん
07/04/28 15:59:48
オブジェクト指向が判らないのは一部の池沼だけと結論が出たから、
次はもっと現代的な話題に移ろう。
893:仕様書無しさん
07/04/28 16:04:55
オブジェクト指向はどのような問題を抱えているか
その問題を解決するには、どういった手段をとればいいか
894:仕様書無しさん
07/04/28 16:13:43
なんだ？このスレを流したい流したいというふいんきは？
俺も手伝ってやろうｗ
895:仕様書無しさん
07/04/28 16:14:19
オブジェクト指向が抱える問題ではないかもしれないが、
底辺に居るオブジェクト指向コンサルにはこんなとんでもない奴が居る。
こいつらをどうやって排除すれば良いか話し合えば、少しは底辺のレベルも向上する事だろう。
事例１：OOPは理解できるが、OODを理解していない人間が
「設計レベルでデザパタを駆使する」という奇妙な概念を振り回して
現場を混乱に陥れる。
デザパタとはマイクロ・アーキテクチャ、イディオムレベルの事柄に過ぎず、
アーキテクチャや概要設計レベルに持ち込むべき概念ではない。
896:仕様書無しさん
07/04/28 16:15:54
設計とデザパタの接点と言えば、
せいぜいクラス設計とか詳細レベルの話だろう。
アーキテクチャを論じる場面でデザパタデザパタ煩い奴が居たら、
キチガイとして放り出すのが適切だ
897:仕様書無しさん
07/04/28 16:17:17
次スレタイトル：
【OOD/A】偽ｵﾌﾞｼﾞｪｸﾄ指向ｺﾝｻﾙってなんで死滅しないの
898:仕様書無しさん
07/04/28 16:21:19
タイトル：【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★6
URL：ｽﾚﾘﾝｸ(prog板)
【糞スレランク：ＳＳ】
直接的な誹謗中傷：42/897 (4.68%)
間接的な誹謗中傷：599/897 (66.78%)
卑猥な表現：14/897 (1.56%)
差別的表現：33/897 (3.68%)
無駄な改行：2/897 (0.22%)
巨大なＡＡ：6/897 (0.67%)
by 糞スレチェッカー Ver0.73 URLﾘﾝｸ(kabu.tm.land.to)
899:仕様書無しさん
07/04/28 16:25:33
>>895
その考えには賛同できない。
デザパタは設計レベルで用いるのが正解です。
デザパタは概念なのだから。
900:仕様書無しさん
07/04/28 16:32:01
>>899
お前、信念表明しかできないヘタレだろ。
証明せよと言うとまたぞろ大規模開発をデスマーチ化するのが落ちだからなあ
901:仕様書無しさん
07/04/28 16:33:34
デザパタ使うのなんて、
せいぜいアーキテクチャ設計のサンプルコードや
クラス設計レベルの話だろ。
そこでマルチスレッドのノウハウもなく、
疎結合に関するノウハウもなく
ダメダメな結果を出したのが鈴木高弘
902:仕様書無しさん
07/04/28 16:34:30
> デザパタは概念なのだから。
違います。
デザパタは概念ではなく
クラス設計レベルのノウハウに過ぎません。
903:仕様書無しさん
07/04/28 16:46:23
デザパタデザパタ煩い奴に限って、
本当はデザパタをきちんと理解できていない。
例えばインタープリタパターンと言葉で言っても、
再帰下降パーサを理解できていなければ実装のしようがない。
要するに、鈴木高弘の言うデザパタとは
鈴木高弘本人が未だに理解できていないノウハウ、未来技術の総称ｗ
904:仕様書無しさん
07/04/28 16:47:11
UFOは宇宙人のデザパタ技術で実装されているんだね、きっとｗ
905:仕様書無しさん
07/04/28 16:48:08
大統一理論のキーはデザパタが握っているｗｗｗ
アインシュタインの宇宙定数はデザパタ２３パターンの事だｗｗｗｗｗｗｗ
906:仕様書無しさん
07/04/28 16:53:09
デザパタ＝クラス設計レベルのノウハウ という勘違いｗ
907:仕様書無しさん
07/04/28 16:57:17
はいはい池沼は口が減らないなあ
バカだから単に争い事をしたいだけなんだろ
908:仕様書無しさん
07/04/28 17:01:13
池沼にとってデザパタとは
万物の根源であり
全ての事象が従うべき法則であり
池沼の人格の基礎となる
絶対不可侵の存在なのでしょうｗ
909:仕様書無しさん
07/04/28 17:24:37
What Is Software Design?
ソフトウェア開発では，「すべて」が設計プロセスの一部になっているという大きな問題があります。コーディングは設計であり，テスティングとデバッギングも設計の一部であり，私たちが一般的にソフトウェア設計と呼んでいるものもやはり設計の一部なのです。
910:仕様書無しさん
07/04/28 17:30:41
やっぱりね
お前の用語遣いは一般人のそれと激しく解離している
だからお前の周りはお前と話が通じない奴ばっかなんだ
おかしいのはお前自身だとはやく気付け
911:仕様書無しさん
07/04/28 17:38:43
なるほど。陳腐な知識しか持っていない低脳が
トンチンカンな用語遣いをして他人に怪訝な顔をされて
「オブジェクト指向は理解されていない」とか喚いているだけか。
akonの言う勘違いって要するにそのレベルの話か
912:仕様書無しさん
07/04/28 17:45:17
伊賀者元気だなｗ
913:仕様書無しさん
07/04/28 17:47:43
またお前の脳内友達の話題か
お前はリアルな友人が少ない割に
脳内友達には事欠かないようだなｗ
914:仕様書無しさん
07/04/28 17:49:03
伊賀者といえば忍者ハッタリくんの事？
ハッタリ最近元気ねぇな。また事業に失敗したのかｗ
915:仕様書無しさん
07/04/28 17:53:47
なにそれ
２年毎に会社から逃げ出している人の事？
今年もそろそろ逃げ出す時期だな
916:仕様書無しさん
07/04/28 18:46:35
ほんっと飽きないねえ
おんなじことばっかり延々と
917:仕様書無しさん
07/04/28 18:50:02
>909
もしお前が「ソフトウェア開発の全てが設計プロセスである」と主張したいのであれば、
グータラな大規模開発の影にかくれてこそこそオブジェクト指向もがきを続けるのではなく、
お前の考える開発プロセスの理論化と実践に努力を注ぐべきだろう。
そのような努力なしに上記の主張をするのは、お前自身の怠惰さを誤魔化すのが目的なのだろう。
918:仕様書無しさん
07/04/28 18:51:44
>>916
このスレの主は偏執狂だからな。
ちょっと目を離すと、延々同じ話を書き続ける。
たまに構ってやっても、大体同じパターンの反応しか示さない。
成長が止まった技術者というのは、こんなものなのだろう。
919:仕様書無しさん
07/04/28 18:52:50
>917
つ"Development Baseline"
920:仕様書無しさん
07/04/28 18:53:13
>>917
頭悪すぎてアンチ理論になった人だから
自分自身を正当化するための理論構築もタブーなんだろう。
921:仕様書無しさん
07/04/28 18:54:22
>>919
つ お前の発言は常に意味不明。
ベースラインとは改善作業の基準の事だが
それが何か？
922:仕様書無しさん
07/04/28 18:59:05
ここのスレ主は了見が狭すぎる。
OO設計の議論してぇとか言い出すから
UMLまで書いて議論の土台を起こしてやれば
キチガイ呼んで来てスレを滅茶苦茶にするし、
スレ主の過去の設計の問題点を議論しようとすれば
人をキチガイ呼ばわりして延々と議論妨害を始めるし、
デザパタ、リファクタ、構造化以外にネタを持ってなさそうだから
新しい議論の核を投入してやっても、ロクに反応できず放置しちまうし。
いったいおまえって何のためにスレに粘着してるんだよ。
お前の人生が無意味だからといって、
その内側で発生した害毒を世の中に垂れ流し続けるのは正しくない。
さっさと人生を終了した方がいいよお前。
923:仕様書無しさん
07/04/28 19:00:14
休日の高弘いじりは愉しいなｗ
924:仕様書無しさん
07/04/28 19:03:05
>>921
要するに>>919は >>909がとてもユニークな考え方だと信じていて、
>>909の普及活動をしないと >>909をベースにした議論ができない
とか信じ込んでいるんだろう。
実際はそのような考え方など多くの人が理解しているのに(一部低学歴は除く)
925:仕様書無しさん
07/04/28 19:09:21
結局、不可知論者なのだろう。
自分のやっている事の不合理は決して自分の責任ではなく、
誰か頭がいい人が解決すべき問題だと考えて
いつまでたっても「こっちにいいヒントがあるらしい」とか
とんでもない方向指して、人々を混乱に陥れるだけの曲者。
926:仕様書無しさん
07/04/28 19:22:14
さっきからスレ主がどうのこうのいってるけどさあ、
このスレはおまえがたてたんじゃねえかよ
みんな次スレｲﾗﾈつってるのによおｗ
927:仕様書無しさん
07/04/28 19:24:28
↑この人を真犯人です゜
928:仕様書無しさん
07/04/28 19:25:39
>>923
ゴミみたいな人生もうやめちゃえば？ｗ
929:仕様書無しさん
07/04/28 19:26:09
俺もこのスレ要らねぇ
たまに高弘いぢりするくらいしか用はねぇ
930:仕様書無しさん
07/04/28 19:26:59
いいねえ
さっさと自殺しろよ
931:仕様書無しさん
07/04/28 19:28:58
これよりこのスレは
スレ主の人生の終了方法を議論するスレとなりますた。
932:仕様書無しさん
07/04/28 19:30:45
教会で異端尋問して破門後火炙り
933:仕様書無しさん
07/04/28 19:33:05
大規模開発現場でデスマの全責任おっかぶせて過労死
934:もっと効果的な方法があるだろｗ
07/04/28 19:40:44
>>1に書かれてるNGワードを連呼して、発狂死させる
935:仕様書無しさん
07/04/28 20:26:16
次スレ立てるやつ、NGワードにもうひとりの糞コテ名も突っ込んどいてね。
936:仕様書無しさん
07/04/28 20:27:03
おまえ発狂してるけど死んでないじゃん>>版画
937:仕様書無しさん
07/04/28 20:30:16
>>935
だから次スレいらねってw
もう糞スレたてんなボケ>>版画
938:仕様書無しさん
07/04/28 20:32:45
高弘が発狂し始めたｗ
939:とおりすがり
07/04/28 20:33:45
このスレ変
940:仕様書無しさん
07/04/28 20:38:02
ほとんどハッタリ一人の自作自演スレだからな
ハッタリの脳内世界全開の奇妙なワールドなのさ
941:仕様書無しさん
07/04/28 20:42:01
まったくだな。なにがサブジェクト指向だよw
942:仕様書無しさん
07/04/28 20:43:19
そうだな。ハッタリの脳内ではOOを超える方法論など
存在すら許されないんだもんな。
943:仕様書無しさん
07/04/28 20:46:23
ハッタリに足止め食らわせるのはとても簡単だ。
２ちゃんで煽りながら新しい話題を振れば、
必ずハッタリはその話題を否定してかかる。
そして今や、ハッタリと世間の技術的乖離は約30年。
もっともっと退化して、みんなを笑わせてクレ！ガンバ！
944:仕様書無しさん
07/04/28 20:53:50
いいか？次スレいらねーぞw
自分で立てといて
乙！とかきめえこといってんじゃねーぞ？w>>版画
945:仕様書無しさん
07/04/28 21:02:08
ここは糞スレ化するとほんとに速いなw
伊賀者とか鈴木とか誰の事だよ。
特に個人名出しちゃあかんだろ。
以前も書いたことあるけど、ほんとに氏ねよ。
粘着うざいよ。
946:仕様書無しさん
07/04/28 21:06:36
公人の名前が頻出するのはしょうがないだろ。
匿名であろうと社会的責任を持って発言してもらわないといかんからな
947:仕様書無しさん
07/04/28 21:08:11
>>944
お前が一番スレ立てフラグ立ってるじゃねぇ～か。
いいか、スレは絶対に立てるなよ！絶対だぞ！
もしスレが立ったら嵐まくってやるからな！ｗ
948:仕様書無しさん
07/04/28 21:08:56
946 名前：仕様書無しさん []：2007/04/28(土) 21:06:36
公人の名前が頻出するのはしょうがないだろ。
匿名であろうと社会的責任を持って発言してもらわないといかんからな
949:仕様書無しさん
07/04/28 21:10:13
いいかぁお前ら
絶対に次スレは立てるなよ
特にスレタイは
【OOD/A】偽ｵﾌﾞｼﾞｪｸﾄ指向ｺﾝｻﾙってなんで死滅しないの
こんなの絶対まずいって。いくらハッタリでも頭から湯気立てて怒るぞ
だから、次スレは絶対立てるな
950:仕様書無しさん
07/04/28 21:11:00
きみひとクン大人気だな
951:仕様書無しさん
07/04/28 21:12:48
次スレ
【OOD/A】偽ｵﾌﾞｼﾞｪｸﾄ指向ｺﾝｻﾙってなんで死滅しないの ★7
ｽﾚﾘﾝｸ(prog板:1番)
952:仕様書無しさん
07/04/28 21:14:07
>>947
俺はたてねーよ。
だれもたてねーよ。
お前以外はw>>版画
953:仕様書無しさん
07/04/28 21:15:29
>>952
しらじらしいぞハッタリ
もう立ってるじゃん
954:仕様書無しさん
07/04/28 21:16:38
ハッタリきみひとクン
結局誰かに構って欲しいんだね
さびしい人ｗ
955:仕様書無しさん
07/04/28 22:39:28
しかし、マジで、デザパタ＝クラス設計レベルのノウハウ と思ってるのか？
とんでもない勘違いだぞ。
956:仕様書無しさん
07/04/28 22:48:19
元はITの外の世界の概念なんでそう思ってるわけじゃないけど
クラス設計レベルでの利用しかしてない俺は趣味ﾌﾟﾛｸﾞﾗﾏ
957:仕様書無しさん
07/04/28 22:55:57
937=944=947=952(自己レス自演乙)
958:仕様書無しさん
07/04/28 23:00:59
また代案を提示できないキチガイが活動開始か
959:仕様書無しさん
07/04/28 23:02:28
まぁ、素直に勉強し直すことだね。もう無理かもしれんが。
960:仕様書無しさん
07/04/28 23:08:24
キチガイ高弘的にはデザパタにどんな幻想を抱いちゃってるんだい？
どうせまた回答もせずに1000までゴネるだけだろうけど、一応聞いてやるよ
961:仕様書無しさん
07/04/28 23:10:47
詐欺師として材料が古すぎるんだよな
いまどきデザパタデザパタ喚いて、
その割に23パターン全て把握できてないのって
鈴木高弘くらいだろ
962:仕様書無しさん
07/04/28 23:10:53
新スレ
ｵﾌﾞｼﾞｪｸﾄ指向開発は構造化開発と何が違うの？★7
ｽﾚﾘﾝｸ(prog板)
963:仕様書無しさん
07/04/28 23:11:47
960も961も、おまぃらどっか行け
生産性の無い粘着厨房うざすぎ
964:仕様書無しさん
07/04/28 23:12:03
似非ｺﾝｻﾙちゃんは今
ドラゴンブックを読むのに必死。
この20年間一体何やってたのかと
問い詰めたい気分だ
965:仕様書無しさん
07/04/28 23:13:15
>>964
Fランク大学で留年してた落ちこぼれには
読破はムリだろう。
いや、読んだフリだけして中身は理解できていない
というパターンもあり得るがｗ
966:仕様書無しさん
07/04/28 23:18:04
詐欺師の人
そろそろ対案出さないと
詐欺がバレバレになるぞ
お前の脳内妄想をサクッとゲロッちまえよバーカ
967:仕様書無しさん
07/04/28 23:21:12
詐欺師がその生活の糧としている
詐欺ネタをゲロるわけねぇ～だろ
デザパタで金融証券向け大規模OO開発ができますって
これからも詐欺人生を続けていくつもりなのだから。
せめてM$のHﾜﾗ氏くらい高級な事言えば
もうちょっとマシなカモを引っ掛ける事ができるだろうに
よりによって「デザパタ」だぜぇ
968:仕様書無しさん
07/04/28 23:24:55
詐欺師というより勘違いだろう
本人がデザパタすらきちんと理解できていない事を判っていないのだから
騙すつもりじゃなく、本気で見当違いな事を言っているだけ。
一回話せばすぐ判る事だ
969:仕様書無しさん
07/04/28 23:28:21
基礎的な勉強ができていない人って
数少ない古臭い知識で全てを説明しようとするから
滑稽だね
970:仕様書無しさん
07/04/28 23:29:41
まぁ、素直に勉強し直すことだね>>鈴木
971:仕様書無しさん
07/04/28 23:30:51
【今日のレスの総括】
本題を忘れ会議が成り立たない連中
972:仕様書無しさん
07/04/28 23:31:37
よく分からんが、アンチな連中
必死だなｗ
973:仕様書無しさん
07/04/28 23:35:23
>>972
お前の言うアンチって誰の事？
お前の日本語能力が低いのはよく知っているけど。
話の筋すら追えないほどのナルシストなのか。
迷惑な人間だ
974:仕様書無しさん
07/04/28 23:38:22
必死だなｗｗｗ
975:仕様書無しさん
07/04/28 23:41:54
おっぱい大好き星人が降臨しないと
からかいがいがないな
池沼の相手はつまらん
976:仕様書無しさん
07/04/29 09:49:27
オブジェクト指向は勘違いが多いよね。
977:仕様書無しさん
07/04/29 09:50:30
複雑な問題を簡単化する技術のはずなのに、さらに複雑化させている。
978:仕様書無しさん
07/04/29 09:51:56
強力な概念だけに危険性を併せ持ってる。
979:仕様書無しさん
07/04/29 09:52:54
プログラムをクラスでパズル化するから手に負えない。
980:仕様書無しさん
07/04/29 09:56:44
そもそも技術は体系立てられたものなのだから、その体系を学ばず
いきなりオブジェクト指向は無理だろ。
981:仕様書無しさん
07/04/29 19:40:20
オブジェクト指向が有益じゃないなんて、理解できない奴の妬みだろ。
どこの世界にもいるな。素質が無いんだからこの仕事さっさとやめてくれれば
助かるんだが、そんな奴に限って管理職としてのさばるったりするから始末に
負えない。
982:仕様書無しさん
07/04/29 20:46:13
日頃のルサンチマンが爆発した模様です。
983:仕様書無しさん
07/04/29 21:30:42
>>981
同意だね。当人は素質がないことに気づいてないんだよね。
不思議だよね。
984:仕様書無しさん
07/04/29 23:00:23
どっかのキチガイが立てた次スレ、
リアルに壊れてる人が来ちゃったな
985:仕様書無しさん
07/04/30 00:16:43
OOを理解できない人はできる人を基地外や馬鹿扱いする傾向にあるようです。
また、子供言葉で叩くしか能が無く論理的に説明するのが苦手なようです。
まともに相手しても疲れるだけなので関わらない方が無難です。