1 ：
仕様書無しさん：
なんて素晴らしい世界なのだ。
読みやすく綺麗なソースコード
拡張性、移植性、保守性、再利用性があり即座に移植、プロジェクトの引き継ぎが可能なコード。
即座にUMLでリバースエンジニアリングできるソースコード。
美しい、すんっばらしいぃ！
1000！
3 ：
仕様書無しさん：04/07/06 10:36
￣￣￣￣￣￣○￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
O 。
, ─ヽ
＿＿＿＿＿＿＿＿ /,/＼ヾ＼ ／￣￣￣￣￣￣￣￣￣
|＿＿|＿＿|＿＿|＿ __（（´∀｀＼ ）＜ というお話だったのサ
|＿|＿＿|＿＿|＿＿ ／ノへゝ/''' )ヽ ＼＿＿＿＿＿＿＿＿＿
||＿＿| | | ＼´-｀） / 丿/
|＿|＿| 从.从从 | ＼__￣￣⊂|丿/
|＿＿|| 从人人从. | /＼＿＿/::::::|||
|＿|＿|／//ヽヾ＼ / ::::::::::::ゝ/||
────────(~～ヽ::::::::::::|／ ＝ 完 ＝
5 ：
仕様書無しさん：04/07/06 14:18
とりえあずデザインパターンを学べ
7 ：
仕様書無しさん：04/07/06 14:26
実装したことがある朱らこそすばらしさを理解できるわけだが
少しでも大きなプロジェクトで開発したことがあれば、
色んな政治的要因にボコボコにされて少しずつ腐っていく実装を見たことがあると思う。
少なく
>>1にそんな経験はなさそうだな。
業務系にはデザパタなど無用の長物
アンチパターンだけ覚えてろ
>>9 確かに、右から左にデータが動くだけのシステムには
必要ないよなあ。
>>10 右から左にデータが動くだけのシステムってどういうの想像してんの？
こんなの？
データ←データ←データ←データ←データ←デート←データ←データ←データ
>>8 知ってるよ。
顧客が急げといわれたらその美しさも枯れてしまう。
ダイヤモンドダストのようにすぐに消えてしまう一瞬のきらめきがあるからこそ
デザインパターンは美しいのだよ。
>>9 > 業務系にはデザパタなど無用の長物
基幹系業務に使われているJ2EEではかなり使われているぞ。
J2ＥＥパターンとかな。
15 ：
仕様書無しさん：04/07/06 16:21
仕事でデザインパターンをうまく使うにはスタートダッシュをかけるしかないと思われる。
急いで骨格を作る。早めに一度作ってしまえばなんども再利用できる。
せっかちな顧客に対してはこの戦法しかない。
これによってよりデスマーチ率が減り多くに人が救われれば幸いだ。
16 ：
仕様書無しさん：04/07/06 16:26
究極といえばエクストリームプログラミング(XP)。
この戦術を使って開発じゃ。
これに加えてオブジェクト指向を頻繁に駆使し開発する。
オブジェクト指向開発は最初が肝心だ。
スパイラル開発、反復型開発, RUP, XP ができたとしてもオブジェクト指向設計が生半可だと
モジュール間の依存関係が大きすぎて思うように反復(後戻り)できない。
モジュール間の依存関係を早めのうちに疎にしておくべきだ。
関係を一度密にしてしまうとくっついたものをなかなか取り外すことができない。
やはりオブジェクト指向にはスタートダッシュが必要不可欠だ。
17 ：
仕様書無しさん：04/07/06 16:31
所詮ﾄﾞｶﾀ開発
デザインパターンとは定石をマニュアル化しただけのもの。
分かりやすくすっきりしていてあたりまえだ。
美しいとかすばらしいとかってのはそういうことじゃないだろ。
19 ：
仕様書無しさん：04/07/07 21:22
>>18 同感。デザパタをかたくなに信奉しそこから一歩も踏み外せないのは
かえって滑稽
宗教がかったスローガンを恥かしげもなく連呼するような奴は、
低能確定。自分の脳で考えることをしていないだけでしょ。
21 ：
仕様書無しさん：04/07/09 23:51
>>17 デザインパターンをﾄﾞｶﾀ開発呼ばわりするｱﾌｫに未来は無い。
22 ：
仕様書無しさん：04/07/10 09:14
>>20 日本人はろくにデザインパターンというものを勉強しないので
プログラマーの価値がその分下がっている。
よってこのような布教活動は欠かせないのだ！
プログラマーの価値を高めるために！
23 ：
仕様書無しさん：04/07/10 11:29
エーンタプライズプログラマーにデザインパターンは必要不可欠。
エンタープライズアーキテクトになるならデザインパターン、アーキテクチャパターンは
必要不可欠だ。
デザインパターンがGoF本を指してるのか構造をさしてるのか分かりにくい。
大規模なアプリを作るときに保守性の高い構造にするのは当然だが
このスレでマンセーしてる奴らは実際の業務で仕様書を見て
「この構造はGoF本に載ってない！」とか騒ぎ出しそうなにおいがする。
26 ：
名無しさん＠そうだ選挙に行こう：04/07/11 11:13
アフォです まじで
>>24 > デザインパターンがGoF本を指してるのか構造をさしてるのか分かりにくい。
それはチミの脳内変換です。
私は
>>1だがGraspパターンも知ってる。
GoFだけに限定するなんてとんでもない。
28 ：
名無しさん＠そうだ選挙に行こう：04/07/11 14:42
デザインパターンの次に覚えるとは？
次なる段階は
アーキテクチャーパターンだ。
そしてアナリシスパターンだ。
アンチパターンもついでに
30 ：
名無しさん＠そうだ選挙に行こう：04/07/11 15:43
そして、イディオムも。
だいたい、この板に救ってる香具師の大半は
オブジェクト指向をろくに理解できず使いこなせない馬鹿どもばかり。
そんなやつらが唯一しっているパターンといったら
イディオムくらい。
イディオムってぇーのは簡単に言うとアルゴリズムのあつまりみたいなもんだ。
>イディオムってぇーのは簡単に言うとアルゴリズムのあつまりみたいなもんだ。
おいおい・・・
GoF本に限定しなけりゃデザインパターンを何で限定してるの？
限定しなきゃデザインパターンなんぞ有用無用含めて沢山ある。
まぁいいか、クソスレだしな
34 ：
仕様書無しさん：04/07/12 13:15
デザインパターンを自慢する奴って、伊東家の食卓の知識を翌日にひけらかすのと同じに思えるんだが。
35 ：
仕様書無しさん：04/07/12 13:20
>>33-34 考えすぎ。
このスレはデザインパターンを普及させるためにある。
多くのマ板のデザインパターンを知らないプログラマを啓発するためにある。
36 ：
仕様書無しさん：04/07/12 14:06
OOしか知らないのって視野が狭くてダメだね。ﾌﾟ
37 ：
仕様書無しさん：04/07/12 14:41
>>36 で、お前の自慢は、くそくだれねーポインタ演算か？
シンデクレ・シュガーか？
いいか。おい。
結城本でいいから、OOとデザパタは勉強しとけ。
でなけりゃ、すぐ辞表書けや。
「くそくだれねー」？
このスレに居る奴ら究極にバカ
デザインパターンは、実装を積み重ねないと体感できないよ。
そこを忘れてくれるな。
41 ：
仕様書無しさん：04/07/15 00:32
結城浩の本でもよんでなんども繰り返しプログラミングしていれば
何かいいことが思い浮かんでくるさ
厨が漂うスレだな。
43 ：
仕様書無しさん：04/07/15 00:36
結城本＝現場で使えないプログラマー量産本
44 ：
仕様書無しさん：04/07/15 00:41
>拡張性、移植性、保守性、再利用性があり即座に移植、プロジェクトの引き継ぎが可能なコード。
受け取り側が糞なら、どんな方法論であろうと↑みたいな結果には絶対できましぇーん。
教育(または無能者淘汰)について語るほうが先なんじゃないかと思う今日この頃。
45 ：
仕様書無しさん：04/07/15 00:45
>>43 ちゃんと読んでいない、あるいはその本を読んだだけで終わった
向上心の無い香具師らばかりだったらそうなるだろうな。
だが、何も読まないよりはマシだ。そこから進歩し成長してゆく。
46 ：
仕様書無しさん：04/07/15 00:56
>>20 バカだな。
デザインパターンを理解し実際に使いこなすにはかなりの想像力がいる。
徹底的に自分の脳で考えることを必要とする。
GoFなどの他人が考えたデザインパターンを見ることで
プログラマはスキルアップする。
この本を読んでみるといい。
Code Reading
http://book.mycom.co.jp/book/4-8399-1265-3/4-8399-1265-3.shtml プログラマが仕切るアップするためにはとにかく他人のソースコードを
ぬすんででも読むことだ。この本にはそう書いてある。
だからこそオープンソースは力だ。
とにかく他人の考えたデザインパターンを習得することだ。
そこから新しいアイディアが生まれスキルアップして成長してゆく。
47 ：
仕様書無しさん：04/07/15 01:04
今のプロジェクトで使ってるフレームワーク。
J2EE、EJB周りのアンチパターンがぎっしり詰め込まれてます。
それを使うとアンチパターンに沿った開発ができる素晴らしさ。
泣きそう。
つまり自分でゼロから生み出す能力が無い人が使うHowTo本みたい
なもんですね。
確かに最初は頭の体操になるな、イテレーターとかオブザーバーとか
そういうこっちゃ。
オブジェクト指向の第一人者も「デザインパターンとか自分で作るもんだ」
って言ってGoF本バカにしてたしな。
パターン関連のワークショップやらミーティングやらは
科学者はほとんどいなくて、実務家ばっかりみたいですね。
研究系は自分さえ読めればいいからな。
>>46 デザインパターンに心奪われるやつはその本を読もうとしない罠！
たぶん本を読み始めた一言目が「Cかよ！なんでJavaじゃねーんだよ、
わかんねーよ、くそだなこの本！」だと思われ。
>>50 第一人者となればそうだよなぁ、デザインパターンをやっと見つけた
必殺技みたいに思ってるやつはまさに初心者といわざるをえない。
ここで言ってるいわゆるデザインパターンとは"整理"するものだからな。
「ほー、こうやって分類しておけばいいんだな」と、そのくらいのものだよな。
意思伝達のための、共通認識が存在する単語が増えるのは良いことだ。
GoFを一通り読んだ後、「パターンハッチング」を読むといい。
>>48 > つまり自分でゼロから生み出す能力が無い人が使うHowTo本みたい
> なもんですね。
で、お前はどんなものをゼロから生み出すことができたんだ？
「独創性」と称して何もできない奴に限ってそういう偉そうなことを言うもんだ。
お前にはこの本を読ませてやりてえな。
「バカの壁」
http://www.amazon.co.jp/exec/obidos/ASIN/4106100037/250-7193262-0133047 この本に、おまえがよくしでかすような「独創性」「個性」に対する誤解についてよく述べられている。
汚い、読みにくい、拡張性が無い、移植性が悪い、汎用性が無い、再利用性が低い、開発効率が
悪い、顧客や他の開発者に迷惑をかけるようなバグだらけのスパゲティコードを書くことが
「自分でゼロから生み出す能力がある」と勘違いして逃げる奴の前例が今までに腐るほどあるからな。
日本語を使って仕事をすべきところを、日本語しか使う必要がないところで
独創性と称して、わざと韓国語やバスク語で会話したり説明することが「個性」と勘違いしている迷惑バカと一緒だなお前は。
おまえがなんでもかんでも本当にゼロから生み出すことができるというなら
フレームワークもライブラリもプログラミング言語もゼロから作ってみろ。
おっと、プログラミング言語をつくるときにyacc/flexなんてもは使用禁止だぜ。
ゼロから生み出す能力があるならそんなものに頼らずにプログラミング言語をつくれるんだろ？
お前はそういったはずだよな？ そうなんだろ？
そしてゼロから生み出す能力があるならコンピュータを使わずにものをつくってみろよ。
コンピュータも自分のゼロから生み出す能力で作ってから使えよ。
コンピュータを作る部品、半導体などの素子も店で買うのではなく自分のゼロから生み出す能力で作れよ。
もちろんそれらの半導体をつくる素材も工場なんかつかってつくるなよ。
57 ：
仕様書無しさん：04/07/18 09:16
ま、お前（
>>48 ）の論理では
「自分でゼロから生み出す能力が無い人」＝「工場に頼ってものを作る人」
だからな。
それらをゼロから生み出す気があるなら半導体を作る原料も全部自然界から自分で採取して来いよ。
「自分でゼロから生み出す能力がある奴はHOWTO本なんて道具なんかに頼らないんだろ(藁
道具に頼らずに素手で採取して来いよw
それと、通勤にも電車なんか使うなよｗ
どうしても電車という「資本」を使いたければ自力で鉄道を敷設して電車を作ってから通勤しろよw
鉄道のメンテナンス、管理もすべてお前だけのゼロから生み出す能力だけでやれよw
さもないとお前自身がお前の言う、「自分でゼロから生み出す能力が無い人」と見なされるぞw
原料を採取するときも道具なんかに頼るなよw
58 ：
仕様書無しさん：04/07/18 09:31
>>57 主張したいことは正しいけど、電車のたとえはちょっとアレだね
59 ：
仕様書無しさん：04/07/18 09:31
>>53 >
>>46 > デザインパターンに心奪われるやつはその本を読もうとしない罠！
> たぶん本を読み始めた一言目が「Cかよ！なんでJavaじゃねーんだよ、
> わかんねーよ、くそだなこの本！」だと思われ。
馬鹿馬鹿しい詭弁だな。あの本がスパゲティコードで埋め尽くされているわけじゃあるまいし。
Java使いでデザインパターンを使おうとする者の大半は
C, Unix経験者だ。C/C++コードが読めないと言うことはありえない。ちょと読みにくいだけだ。
スパゲティコードリーディングという名の本ではあるまいし
基本的な記法を知っていれば全然苦にならない。
そもそも、読んでためになるソースコードはスパゲティコードなんぞにはなりえないからな。
それ以外でJavaを使っている香具師の大半は
嫌々ながら仕事でJavaをやらされているだけのServlet初心者だ。
>
>>50 > 第一人者となればそうだよなぁ、デザインパターンをやっと見つけた
> 必殺技みたいに思ってるやつはまさに初心者といわざるをえない。
しかしそのデザインパターンをろくに使いこなせない香具師が多いのも事実だが。
ここであのパターンをつかってくれればこちらもそのクラスを使いやすくできるのに、
なんでこんな効率の悪いことをやっているんだ、他のクラスでラップするのは禁止されているし
一ヶ所を変更するたびに結局コピー&Pasteを繰り返しか、
って何度思ったことか。
クラスやメソッドのアクセス権の効率のよい使い方も知らずに勘違いしている者がどれだけ多いことか。
60 ：
仕様書無しさん：04/07/18 09:40
「吸収合併サービスに最適な開発言語はJava」
採用すると漏れなく吸収合併されちゃうという最強言語Java
について語り合いましょう
61 ：
仕様書無しさん：04/07/18 09:43
>>58 電車と「資本」の喩えは「巨富を築くための13の条件」にも載っている。
つまり一人でなんでもできるなら資本には頼らないってことだ。
もちろん電車でなくても車でいくとしてもだ。
一人でなんでもできるなら車を買って運転することもおかしい。
そしてガソリンスタンドでガソリンを補給して貰うこともおかしい。
本当に一人でなんでもできる、ゼロからなんでも生み出すことができるなら
イラク、サウジアラビアに自力で石油を採取しに行くものだ。
そして、一人でなんでもできると言い切るなら
車が通る道も国や地方自治体に任せずにすべて自分でメンテナンスするものだ。
資本主義社会は誰かさんの想像する社会と違って一人だけでは何もできない社会構造になっているのだ。
つねにお互いに協力し合っている。人にものを頼むときは自分の中からお金、時間など何かを犠牲にして取引をする。
つまりゼロからなんでも間でも生み出すことができる奴なんてこの世に一人もいないということだ。
アインシュタインの理論だってそうだ。相対性理論はゼロから生み出されたものではない。
事前にニュートン力学、電磁気学などを模倣するところから生まれたものだ。
もちろん、これらの理論は数学無くしては語れない。
数学すらも使わずにこれらの理論をゼロから生み出すことなど不可能だ！
ゼロから生み出すことにやたらと拘る奴はやたらと使えないOSやプログラミング言語を乱立させて
互換性問題で他人に迷惑をかける。変な形のネジを大量生産されたらネジの形が共通規格に合わず
作業効率が悪化するだろう。
昔の銃器の大量生産に喩えて貰いたい。銃器は昔は職人が作っていた。
そのため銃器の形状、サイズ、銃器に使える弾薬の形状、サイズはそれぞれ異なり互換性がないものとなった。
それだけでなく巨大な軍隊を変性するには大量生産できず効率が悪すぎた。
そこで銃器、弾薬の雛形を発明する者が現れた。それにより職人に頼らずに銃器を大量生産することができ
巨大な軍隊を素早く変成することが可能となった。
>>56 へー。面白そうな本だな。
何々・・・
>知りたくないことは自主的に情報を遮断し、耳を貸さないというのも「バカの壁」の一種。
>その延長線上には "オブジェクト指向" があるという。
63 ：
仕様書無しさん：04/07/18 20:02
>>62 あほだろ。実際はこうだろ。
>知りたくないことは自主的に情報を遮断し、耳を貸さないというのも「バカの壁」の一種。
>その延長線上には "スパゲティコードによる後継者霍乱" があるという。
なんか粘着してる奴が居るが、言語仕様については
ANSIなりSunなりの定義に従うのは当然だが、その上でのアプリの構造に対しては
制限される必要ないのは当たり前だろ？
自分で多少考えて一からくみ上げていこうという努力を
極論で否定しようとする
>>56の意図はなんなんだ？
つか、１の言いたいデザインパターンのすばらしいところって
「オブジェクト間のつながりを疎にして再利用性を増やそう」っていう
コードの作りに関する考え方にあるんじゃなかろうかと提案してみるテスト。
ただObject指向だとこの考え方があまり無いが、
デザインパターンが登場してからと言うもののオブジェクト間を”疎にする”っていうのは
よく考えられるようになったかと思う。
疎にしないとうまくいかないなんて経験則なんざ、モジュール化が叫ばれてた時代からあった。
「オブジェクト指向の落とし穴」ぐらい読め。
うるせー！ちんこ燃やすぞ！
69 ：
仕様書無しさん：04/07/19 19:24
>>63 いや、それは曲解が過ぎる。
>>63 は自分でも文章として「おかしい」と感じないか
養老孟司は長年プログラマが身に着けてきた「問題を分割せよ」という深遠な智慧に
「待った」をかけたのだ。
「そんな態度は役にたたんよ・・・」と。
彼は脳みそ屋さんだからそう感じたのかも知れないけど、
プログラマからみたら噴飯物の考え方だね。
で、その回答がこれだってさ。。。
http://www.worldtimes.co.jp/syohyou/bk040510-2.html 一言だけ私見を述べさせてもらえれば、古今東西、
Memento Mori を謳う学者にロクな奴がいた例はないね。
（↑バカの壁の見本ともいう）
うるせー！ちんこ燃やすぞ！
71 ：
仕様書無しさん：04/07/19 19:36
>>65 なんで疎結合の考え方がオブジェクト指向に無かったなんて言うのか…。
疎結合にするってのは、オブジェクト指向の背骨みたいなもんだろ。
>>71 いちいち学生の書き込みに反応してると体壊すよ。
>>69 単なる「要素還元主義の限界」の指摘ではないのか
Javaにしろデザインパターンにしろ、何で宗教じみた
スレが多いの？
マジでキモイつうの。
>>75 えっ！
Java、デザインパターン、宗教とくれば結城さんのことか？
キモイは言いすぎだぞ、キミィ。
77 ：
仕様書無しさん：04/07/24 21:11
>>64 > 自分で多少考えて一からくみ上げていこうという努力を
> 極論で否定しようとする
>>56の意図はなんなんだ？
だれも否定していないが、「独創性」の意味を勘違いしているバカ
がわんさかいるからな。ウザイんだよ。独創性だ独創性だと言っておきながら
自分は一人で一から何も作れず過去に作ったものにたよっているくせに
全部一人で一から作れと説教垂れる糞ジジイが。
>>69 > いや、それは曲解が過ぎる。
>>63 は自分でも文章として「おかしい」と感じないか
>>62の喩えも十分おかしいと感じないか？
> 養老孟司は長年プログラマが身に着けてきた「問題を分割せよ」という深遠な智慧に
> 「待った」をかけたのだ。
お前は養老孟司の意図を勝手に曲解しているだけか。
> 「そんな態度は役にたたんよ・・・」と。
> 彼は脳みそ屋さんだからそう感じたのかも知れないけど、
> プログラマからみたら噴飯物の考え方だね。
嘘付けアフォ。解剖学者なんだよ。
> 一言だけ私見を述べさせてもらえれば、古今東西、
> Memento Mori を謳う学者にロクな奴がいた例はないね。
だれがそう謳っていたんだ？
MementoというからMementoパターンのことかと思ったぞ。
79 ：
仕様書無しさん：04/07/24 21:29
>>69 おまへは「死の壁」を読んでいないだろ。
自分とは何かということをよく解っていない。
自分とはつねに変化するものであり、過去の自分と今の自分とは
まったく違うのに「本当の自分はこうじゃない」と叫んでいるこ
とがおかしいといっているだけなんだよ。
情報という記憶だけが残ったためにそれに流されてしまって
いることに気づくけといっているんだよ。
コンピュータを扱っているなら記録を簡単に残せることくらい解るだろう。
しかし自然界にあるもはつねに変化し移り変わってゆく。
文明社会ではそれがない。
我々は情報工学というテクノロジを使って仕事をしている。
そこで文明社会にいるプログラマがどうすればいいかを
かんがえるべきなんだ。考えられることはいくらでもある。
プログラムは消すか修正するかしないかぎり消えない。
彼は「現実を見ろ」と言いたいだけなんだよ。
「死」を「バグ」に置き換えてみよ。
お前には「バグの壁」が潜んでいるんじゃないのか？
バグなど絶対に存在しないという原理主義を唱えて現実逃避し例外処理対策、
テストプログラミングを怠っているんじゃないだろうか？
80 ：
仕様書無しさん：04/07/24 21:32
>>79 >彼は「現実を見ろ」と言いたいだけなんだよ。
いいや違うね。彼が言いたいのは
「皆、俺を見てくれ。
皆、俺が眺めるように死体を見てくれ。
それこそが現実であり、全てなのだから・・・」
って事。
何故、「バカの壁」等という世の中の普遍的な問題に対する解答に、
彼の飯の種である「死（＝死体）」なんてものが関わってくるんだ？
偶然にしては余りに「出来過ぎている」と感じないか？
COBOLer が全てのシステム構築には COBOL が最適だと考えてしまうように、
彼の脳内では「死」こそが全ての問題解決の万能薬になってしまっているのだろう。
そして COBOL と同じく、現代において「死」は社会から迫害されているのだから、
なおさら偏屈にもなる。
恐らく彼の「バカの壁」は「死体」の山で築かれているのだろうね。
82 ：
仕様書無しさん：04/07/24 23:17
>>78 養老孟司はCOBOLerみたいな古くさい考えは持たない方だぞ。
「NHKスペシャル 人体Ⅱ The Universe Within 驚異の小宇宙 脳と心」
を見たか？
バカの壁を構築しているのはまさにお前じゃないのか？
>>82 ならば、これに対して回答してくれ。
>何故、「バカの壁」等という世の中の普遍的な問題に対する解答に、
>彼の飯の種である「死（＝死体）」なんてものが関わってくるんだ？
>偶然にしては余りに「出来過ぎている」と感じないか？
このすれホントきもい。まぁ、スレタイからしてキモイから仕方ないんだろうけど。
85 ：
仕様書無しさん：04/07/26 00:35
>>83 彼が人体解剖を通して死というものを良く見てきたからだろう。
すでにそこでも述べられていると思うが
死ぬってことは当たり前のことなんだよ。
それを受け止める事ができない者がいて、そういう輩が原理主義に走る。
>>85 >彼が人体解剖を通して死というものを良く見てきたからだろう。
ならば、もし彼が産婦人科だったなら、
「バカの壁」等という世の中の普遍的な問題に対する解答は
「出産」になるのか？
世界は彼を中心に廻っているのか？
87 ：
仕様書無しさん：04/07/26 09:26
読んでもいねえ癖に厨uzeeeeeeeeee
とりあえず死の壁を嫁
デザパタが美しいなんて、頭おか
デザインパターンはそもそもC++で書かれてたもので
Java厨よりちょっと偉い幹部くらいの人がUMLと共に流行らせた
91 ：
仕様書無しさん：04/07/27 05:51
だが、おまいはJava厨よりも下等で
そんなに偉くはないC++厨なわけだがわけだが。
92 ：
仕様書無しさん：04/07/27 06:01
>>81 > 恐らく彼の「バカの壁」は「死体」の山で築かれているのだろうね。
死体というのはいずれ腐り果て、土に還り、菌類の栄養素となり
植物に恵みをあたえ成長の手助けをする。
その植物が人間に恩恵をもたらす。
つまり、「バカの壁」、「死の壁」にも書いてあるとおり、
万物は流転するものなのだ。
このよに変わらないものなどない。すべてのものは生まれては成長し、
変わり行き、やがて老化しいつしか死んでゆく。
桜が散る姿をみてはかないと思ったときこそ、死を実感するときだ。
デザインパターンに対するあり方も進化してゆき、変わり行く。
この世に不変なものなど存在しない。不変なものとは情報(イデア)だけである。
オブジェクトは常に変化している。常に変わり行く。
C++厨も、過去の栄光を懐かしく思っている頃だろう。
あのころは良かった、昔はよかったと。あのころのはかない思い出、栄光の時代
にまた戻りたいと思っているだろう。だか、もうそのような栄光はC++厨には戻って来やしない。
C++厨の栄光も、桜の花びらのように散ってゆくのだから。
そして世の中は移り変わりC++の時代に終止符が打たれるのだ……………。
「万物は流転する」という法則そのものは流転するまい。
95 ：
仕様書無しさん：04/07/27 19:22
>>93 枯れ桜の如く散ってゆくC++厨ごときが何ほざいているの？
Java厨でもありC++厨の俺が言いたいことはただ一つ。
みんな仲良くしてぇーーーーーーーーーーーーーーーーーっ！
>>95 > 枯れ桜の如く散ってゆく
君の人生がでしょ？Java厨なんかやってるからだよ
俺はmementパターンしか使わねえぜ
>>98 デザパタは糞あたりまえな実装法に名前を付けて意思の疎通をしやすくしたもの。
パターンを知らないだけで似たようなことは彼方此方でやってるはず。
100 ：
仕様書無しさん：04/07/27 19:49
>>97 いや、君の人生を象徴しているんだよ。
自称C++厨なただのC厨なんかやってるからだよ。
101 ：
仕様書無しさん：04/07/27 19:49
>>99 似たようなことをやっているよに見えて実際に覗いてみると
拡張性がなかったりクラス間の依存関係が非常に濃密になって使い勝手がわるかったりするんだよな。
>>100 Java厨ごときがプログラマ名乗るなんてお江戸なら切腹ものだぞ。
負け組み能無しコーダはへこへこしてりゃいいんだよｗ
>>101 お前は何が言いたいんだ？
ただデザインパターンを軽んじられる発言が許せないだけなのか？
お前みたいな奴が一番使えねぇ。
104 ：
仕様書無しさん：04/07/27 20:19
>>102 お前、本当にカルシウムたりないな。
病気だろ。
なあ、コボラーあがりのJava厨には別の呼び名をつけようぜ。
107 ：
仕様書無しさん：04/07/28 01:48
Javaの評判を落としてる諸悪の根源はｺJavaﾗｰにあると思う。
>>109 PGの評判を落としてるのはお前だな(w
111 ：
仕様書無しさん：04/07/28 01:56
やっぱJabolでしょ。
JABOLer
ｵﾚはCからVB果てはｵﾗｸﾙまで完璧だぜ
114 ：
仕様書無しさん：04/07/29 08:43
VBあがりのC#厨はさらにプログラマの評判をおとしていることだろう。
これは確実だ
115 ：
仕様書無しさん：04/08/08 22:20
やたらと関数をstaticにせず、
ちゃんとデザインパターンを駆使してプログラミングしましょう。
>>115 VB.NETで全部Moduleにしろと、怒られた(´･ω･`)ｼｮﾎﾞｰﾝ
117 ：
仕様書無しさん：04/08/12 17:10
>>115 やたら程度じゃねぇよ
全部 static だったよ
もうね、アホかｔ・・・
118 ：
仕様書無しさん：04/08/12 19:12
>>117 それだけならまだいい。
統一性の名の元に全員にそれをやれと
言われた日にゃ・・・
>>116 VBしか出来ない会社の上司って
どうしてあんなにアホなんだろうな。
121 ：
仕様書無しさん：04/08/25 19:57
リファクタリングしまくれば自然と理想の設計に近付くよ
122 ：
仕様書無しさん：04/08/25 20:06
>>121 リファクタリングしまくれることが理想だ。
123 ：
仕様書無しさん：04/08/25 20:11
>>116, 120
知ってる、知ってる！
その場凌ぎのプログラミングしかしたことないからだよ！
納期にさえ間に合って、とりあえず落ちなければ満足なんだよ！
きれいなコーディングやリファクタリングなんて、コストの無駄としか思ってないんだよ！
（正確には、そんな単語すら知らないんだよ！）
124 ：
仕様書無しさん：04/08/25 22:02
ところで、デザインパターンというとIteratorばっかりさも便利かの
ように語るやついないか？
思わず「それしか知らないんだろ？」と言いたくなる。っていうか
言ってしまった・・・
125 ：
仕様書無しさん：04/08/25 23:05
>>124 Iteratorだけを語る奴はデザインパターン知らないんだよ。
JavaのAPIとしてのIteratorを語ってるんだよ。
126 ：
仕様書無しさん：04/08/26 02:28
C++のSTLとしてのIterator程度しか語れない香具師もいるが
127 ：
仕様書無しさん：04/08/27 01:32
単なるクラス設計上のテクニックにグレードの上下もないは思うが、
なんとなく凄いパターンって言うと、Composite+Visitorとかじゃないかな。
不適切な位置で使われている事が一番多いのは、Singletonかな？
つうか、それ以外が現場で使われていることにめぐり合うことって少ないけどさ。
128 ：
仕様書無しさん：04/08/29 01:13
>>127 もうちっと消化すれば色んな所で色んな使い方が出来るよ。
つーかフレームワーク使うだけでパターンの宝庫な訳だが。
ポリモーフィズム使うと、わかりにくいって言われるんだけど。
動的に流れが変わるのが嫌だって言うんだけど、よくよく
考えてみりゃ、if文だって同じじゃねーか。
まぁわかりづらいはわかりづらいよなぁ
if文のような明快な目印はないわけだから
目印というよりは、ifやswitchは動的に変わるところが一箇所に集中するのが、
ポリモだと分散する。あきらかに一箇所に集中した方が分かりやすい。
関数ポインタとか、コールバック関数とかが分かりにくいのと本質一緒。
特にenumによるswitchは非常に分かりやすい究極の美。
>>131 ＞目印というよりは、ifやswitchは動的に変わるところが一箇所に
＞集中するのが、ポリモだと分散する。
逆じゃない？
ポリモフィズムだと、インスタンス生成時に分岐があるだけで良く
て、あとはインスタンスごとに振る舞いが定義されているから
呼び出し側は（振る舞いが異なっても）同一メソッドを呼ぶことが可能。
if文はメソッド呼出しごとに分岐しなきゃならない。
131は釣りだろ？
マジレスだったら爆笑するぜ
ifとかswitchだとstateパターンか。
stateってifいらないじゃん
分かりやすさ云々で言えば、
>>130-131に禿同だな。
それでも複雑になればなるほどポリモ使うのがベスト。
OOの目的はわかりやすさじゃないからな。
>>134 ちゃんと勉強しろよ。
なんかＯＯ信者って、必死で、ifとかswitchをクラスに置き換えてるのな。
ポリモフィズム覚えたばっかで使いたいのは分かるけど、キモいな。
ifやswitchはクラスに置き換えないだろう。
どう考えても
>>131の言ってることはオカシイのに、それを支持するやつがいるってことはｼﾞｻｸｼﾞｴﾝなんだろうな…。
141 ：
仕様書無しさん：04/08/30 01:02
>>140 妄想ＯＯ信者キモいな。
絶対こいつJava厨だな。
デザパタって結城を筆頭にJava厨多いから嫌いだ。
次はforループ使うよりｇｏｔｏループした方がいかに美しいかについての議論でもする？
ifやswitchだと、「ここは分岐だよ、分岐先はこれとこれとこれだよ」ってのが
全部固まってるんだけど、ポリモするとそれを推測するのにちょっと手間と知識がいる。
だから、ifやswitchがわかりやすいってのは事実だと思うよ。
ifとswitchならバカでも一応理解できるし（というか、ポリモーフィズムわからない奴多すぎ)。
ただ、else ifやcaseが10も20もあるソース読まされると、書いた奴の首しめたくなるね。
インターフェースのドキュメントなしで多胎されてもよみづれーだけなんだよ！
なんで多態が分岐なんだ？
タイプコードによる分岐を多態で置き換えるリファクタリングはあるけどな。
・if や switch がないほうが理解しやすい
・多態するためのinterfaceを実装したクラスは、if の中身さえ実行すればよい(=一つのことをしっかりやる)
・interface とやりとりするクライアントは、単純にサービスを依頼すればよい
どれも正しいし、当たり前だ。
なぜ分かりにくいんだ？
正直、判り易さ云々で議論してる限り、処理追っかけ廚は絶対に納得できないんだよね。
ここは素直に
・条件分岐が増えれば、バグが混入される確率も跳ね上がる
だけでいいんじゃない？
これさえ否定するアホ？知らんわ
148 ：
仕様書無しさん：04/08/31 00:59
相変わらず、Java厨馬鹿ばっかだな。
世間的に馬鹿扱いされている事にJava厨は気づいてないんだよな。
まぁまぁ、とりあえず
>>131だけがアフォだったってことで…。
純粋に、クラス(131風ならenum)が一個増えたときの
追加分の処理を書くのがポリモーフィズムは楽
楽というか既存部分はそのままで、追加クラスの定義だけ書けばよい
switchだと全部のswitchにcase増やすはめになり
中規模以上では泣く
しかし、全クラスにメソッドを一個追加するときは
ポリモーフィズムだと泣きたくなるのも事実ｗ
スーパークラスにかいとけ。
ifやswitchの方が判りやすいという意見も判ります。
フローチャートのようにソースを読めて
あらかたの仕様が把握出来るから
ドキュメントが貧弱な所につっこまれて
デバグする時とかは確かに楽ですね。
クラスがいっぱいあるとあっち開いたり
こっち開いたりしなきゃいけない。
ただ、「可読性」と「変更に強い設計」とは全く別の話ですね。
フローチャート的な頭の使い方からオブジェクト指向的な
方へ変えないといかんのでしょうな。
面倒臭がらずに、あっち開いたりこっち開いたりして
頭の中で処理をイメージ出来るようにする、と。
>>151 デフォルトの実装用意すればいいじゃん。
そもそも同等の修正をswitch caseで書いたコードに行うと泣かなくて済むのか？
デフォルトの実装なんざ書きようがないメソッドを
多数のクラスに追加することなんざ
普通にあることだろうが
当然、スーパークラスには純仮想メソッドが追加されて
各サブクラスでクラスタイプごとに違う動作を実装
これが、switchタイプの実装なら
switch文でタイプごとに分岐する関数を一個書けばすむから
幾分楽になるわけ
どんな状況でも、OOの方が従来型より保守性に優れるわけじゃないってこと
要するに、区分を
ひとつのクラスの属性として持つか、
サブクラスを区分の数だけずらっと用意するか
ですよね。
良い悪いは場合によりけりでしょうね。
それを見極めて使い分けるセンスが
一番必要なんじゃないでしょうか。
それがないからなんでもOO、
なんでもif switch って事になって
両方から文句が出る。
書いてみたものの、
正論は何時だってつまんないですな。
if,switch と OO が対立してるのがよくわからん
>>156は両方出来るオブジェクト指向型言語を使いましょう！
オブジェクト指向マンセー！と言ってるんです。
>>156 それクラス設計が悪いだけだよ。
何をどうやってクラスとしてまとめるかが分かってない人が設計するとそうなる。
再点火乙！
162 ：
仕様書無しさん：04/09/01 01:15
結論は、Javaは糞で、OO厨は何が真分かりやすいかを理解していない糞ってことだな。
>>160 こういうこと書いてる奴のクラス設計が最悪なのに、自分では最高だとか思ってるんだな。
再再点火乙！
扱ってる問題の規模や複雑さによって最適解が変わるんじゃないかな。
結局OOやパターンやフレームワークより大事なのはシンプルデザインだと思う。
>>156 100行のメソッドを1つ書くのと10行のメソッドを10個書くのとどっちがいいかという話か。
>>166 ポリモーフィズムうんぬんからいうと、
100行のメソッドを1つ書くのと
10行のメソッドをもつクラスを10個書くのと
どっちがいいかという話ですか。
みんな落ち着けよ、とりあえず
>>131だけがアフォだったってことで…。
まぁ131がアフォだという事実は
131以外はみんな同意するところだろう。
>>131は、すべてのものが自分のスコープにあっても大丈夫な、スーパーな人間なんだよ。
>>166 まあそういうこと
C++だと、さらに10個のヘッダーファイルも修正だから
純粋にまんどくせえ
173 ：
仕様書無しさん：04/09/03 00:55
>>171 だな。Java厨はアフォだからそれが分からないと。
てか、Java厨ってプログラム経験がないんだろうな。
174 ：
仕様書無しさん：04/09/03 00:57
しかし、Java厨ってなんでもかんでもデザパタだからほんと困るよな。
結城の馬鹿本かってしたり顔かよ。
だからおちつけって、とりあえず
>>131だけがアフォだったってことで…。
つか、お前らアフォばっかだろ。
デザパタ関係ないじゃん。
Java厨、Java厨って、確かに無能な香具師多いが、お前らより結城の方が有能だな。
本はどうしようもないが。
1クラス、1ヘッダーって普通じゃねえのか？
クラスが10個あって、それらにメソッドを1つづつ追加したら
10ファイル変更が普通かと思うが
>>178 スーパークラスにメソッド1つ追加しただけで、
サブクラスのヘッダにまでメソッド追加作業が波及するか?
コンパイル時には依存が発生するけどさ。
お前等JavaとEclipse使ってください。
くだらない悩みから開放されますよ。
スーパークラスに純仮想関数宣言
サブクラスに仮想関数の宣言
両方必要だと思うが？
気にするな。
たぶんＣ＋＋をろくに知らない"Javaだけ厨"だろ。
>>178 普通じゃないし、そもそもソースでクラス定義するときもある。
お前C++ろくに知ってないC厨だろ？
>>183 待て。
１クラスにつきh&cpp１組ってのは基本だろ。
クラス内で利用するクラスを.hに同時に定義することも「たまに」あるが、
今回例に挙がってるような場合では分けるだろ。
お前がよっぽど汚いちゃんぽんソース書いてるなら別だが。
184に同意。
>ソースでクラス定義するときもある。
は俺はやらないが、そもそも183だって「普通に」は
やらんだろ。それが普通なら只のバカ。
>>184 そりゃ公開するような独り立ちするクラスならファイルわけるだろうさ。
だがこれは公開しないクラスだぞ？
あるクラスの内部でひっそりと使われるクラスをなんでわざわざ別ファイルに書くよ？
>>185 簡単な、そこだけで使う関数オブジェクトとか普通に定義しまくってるが？
クロージャ感覚だな。関数内で定義したいがそうするとテンプレートに渡せないからムカツクが。
・・・デザインパターンって、設計パターンだよな。
>186
だからバカ。
どこが？ではなくて全文バカ。
「あるクラスの内部でひっそりと使われるクラス」や「簡単な、そこだけで使う関数オブジェクト」
の話をしてるのはお前だけだということに気づいたほうがいいぞｗ
クラスが10あったら、そのうちの一個ぐらいは、cppの中に定義されていたり
クラス内クラスだったりすると言いたいのかな？
そういう統計的な話は、全くしていないわけだが
内部クラス沢山作る奴って協調性なさそう。
193 ：
仕様書無しさん：04/09/06 23:39
インターフェイスとかパッケージングとか知らんのか(-_-;
内部クラス＝inner class
インターフェイスとかパッケージングとかは別次元の話
>>192,194
こういうヤツラが構造化言語いじると
関数全部公開モジュールとか作り込むんだろうな。
196 ：
仕様書無しさん：04/09/08 18:10
>>195 うちのプロジェクトでは、hoge.c で static int foo() を定義して、hoge.h で
static int foo(); と宣言している。
まともなプロジェクトでhogeとかfooとか使う奴はパターン以前の問題。
あ、
>>196じゃなくてウチの先輩ね。
ヲイヲイ。そこは実際には別の名前に置き換わってるだろ？普通。
・・・ハッ
釣られたか？
>>198 バカだなぁ…。
＞・・・ハッ
＞釣られたか？
↑これがなかったらお前がツリをしたことになってたのに。
なんか一言、保険のための言葉なんか書いちゃって…、チキンハートだな。（笑）
>>196の本質は名前ではなくて static だと思うのだが。
201 ：
仕様書無しさん：04/09/09 12:00
>>200 他のソースから呼び出せない関数ね。
これが分かる椰子はC厨。JAVA厨では指摘できないとこだな。
>>196 何を自慢したいんだ？
それともツッコミ入れちゃってもいいのかな？？
>>200 でわからない人もも一回勉強しなおせ～
203 ：
仕様書無しさん：04/09/09 23:50
>>202 うちのプロジェクトには「プロトタイプ宣言は .h に書く」というコーディング規約が
いにしえよりあって、もうどうしようもなくなっている。
くだらない規約は廃せ。
英雄になれるぞ。
定期的に改訂しなければ「規約」の名に値しない
のであるが
206 ：
仕様書無しさん：04/09/18 18:48:47
ヴィバ！ デザインパターン！
>>203 プロトタイプ宣言は他のモジュールというかソースから参照するためのものを
書くものではないのか？違うのか？
# あ、～.h に書くプロトタイプ宣言の事ね。
>>207 次の現場入る前にstatic関数について調べておけ
>>208 だーかーらーたとえ規約でプロトタイプ宣言は～.hに書くことになってても、
staticなんかは普通適用外でしょ？って言いたかったんだが…
なんでstaticについて知らんことになるんだ？
211 ：
仕様書無しさん：04/09/19 12:35:27
とりあえず
>>203の会社はバカ会社のひとつということで
212 ：
仕様書無しさん：04/09/19 12:36:40
プロトタイプといえば
GoFデザインパターンの一種ProtoTypeパターンのことだな
デザパタスレっていつも厨ばかりだな。
214 ：
仕様書無しさん：04/09/23 13:30:35
じゃあどんなスレが厨が少ないスレだというのだ？
そもそも、お前みたいな厨が邪魔をしてばかりいるから
厨ばかりのすれに見えてしまうのだ。
いい加減にしろ
215 ：
仕様書無しさん：04/11/14 01:59:42
C厨ばかりって意味ではマ板は厨ばかりだけどね
とりあえず下の問題を解いてください(別のスレから拝借)
------------------------------------
次のプログラムは、食事をする人を表現しています。
このプログラムのEatingMan#eat()メソッドは、if～elseが連続していて長い上に、
新しい種類のFoodクラスを作成する度にコードを付け加える必要があります。
この問題を解決するように、プログラムを書き換えなさい。
なお、すべての食べ物について、その食べ方は1通りしかないものとします。
------------------------------------
class EatingMan{
void eat(Food food){
if(food instanceof Rice){
// お箸を使ってfoodを食べる
}
else if(food instanceof Bread){
// 手づかみでfoodを食べる
}
else if(food instanceof Steak){
// ナイフとフォークを使ってfoodを食べる
}
}
}
abstract class Food{}
class Rice extends Food{]
class Bread extends Food{}
class Steak extends Food{}
おれはプログラマー
オブジェクト指向は大得意
パターンだってお手の物
俺が設計すればコードもすっきりだ って言うじゃない？
でもあんたの会社 4層の下請けの最下層ですから！ 残念！
規約でインターフェース作れない 斬り！
ギター侍ネタにはほんとにイライラ
うんざりさせられたここ数ヶ月だったが
218は面白いです。
そうだね。どうせソースコードの中身なんて
会 社 は 評 価 し て く れ な い
他人の三倍の速度で作っても、作業を追加されるだけで
給料にはあんまり反映されないしな。
それより上司と喫煙室で仲良くなって、飲み会でお世辞言ってる
方が100倍得になる。
ぱたーん
>>216の様に解くのって、実に自然だよな。
「食べ方」って言うのは、「食べ物」毎にあるんじゃない。
食べ物と、食べる人の「狭間」に存在するんだ。
そして、その狭間に存在する「食べ方」の内、どれを選択するのかは、
完全に食べる人にのみ、依存するのだ。
interface EatingMethod {
void perform(EatingMan man, Food food);
}
class ChopstickMethod implements EatingMethod {
public void perform(EatingMan man, Food food) {
System.out.println(man + " はお箸を使って " + food + " を食べる");
}
}
class HandMethod implements EatingMethod {
public void perform(EatingMan man, Food food) {
System.out.println(man + " は手づかみで " + food + " を食べる");
}
}
class KnifeForkMethod implements EatingMethod {
public void perform(EatingMan man, Food food) {
System.out.println(man + " はナイフとフォークを使って " + food + " を食べる");
}
}
class MethodUnknown implements EatingMethod {
public void perform(EatingMan man, Food food) {
System.out.println(man + " は " + food + " の食べ方が分からない");
}
}
class EatingMan {
Map eatingMethods = new HashMap();
MethodUnknown unknownMethod = new MethodUnknown();
void eat(Food food) {
if (food == null) {
unknownMethod.perform(this, food);
return;
}
Object o = eatingMethods.get(food.getClass());
EatingMethod method;
if (o instanceof EatingMethod) {
method = (EatingMethod) o;
} else {
method = unknownMethod;
}
method.perform(this, food);
}
void teachHowToEat(Class foodClass, EatingMethod method) {
eatingMethods.put(foodClass, method);
}
}
public class Main {
public static void main(String[] args) {
//誕生
EatingMan man = new EatingMan();
//教育
man.teachHowToEat(Rice.class, new ChopstickMethod());
man.teachHowToEat(Bread.class, new HandMethod());
//man.teachHowToEat(Steak.class, new KnifeForkMethod());
//料理
Food rice = new Rice();
Food bread = new Bread();
Food steak = new Steak();
//食事
man.eat(rice);
man.eat(bread);
man.eat(steak);
man.eat((Food) null);
}
226 ：
仕様書無しさん：05/02/17 23:57:37
>>216 RatingManに以下のメソッドを追加。
void eat(Map foodMap){
Iterator iterator = foodMap.iterator();
Food food;
while(iterator.hasNext()){
food = (Food)iterator.next();
food.eat();
}
}
Foodクラスにabstract void eat()メソッドを追加。
それに従ってFoodのすべてのサブクラスにeat()メソッドを実装させる。
食べ方はif文内書いたものを書く。
これで、クラスを追加するたびにEatingManクラスにif文を追加する必要がなくなる。
必要に応じてwhileステートメント内にif文とbreakを付け加えよ。
Mapにはiterator()メソッドはない。
ここでは、Iterator iterator = foodMap.values().iterator() かな。
と書いてから、そもそもがMapじゃなくてCollectionが来るべきところのような気がしてきた。
STLみたいにキーと値のペアが取り出せるイテレータがあっても
いいのにね。
map.entrySet()
でMap.Entry (KeyとValueのペア)の集合が取れる。
>>223 >>216の
＞なお、すべての食べ物について、その食べ方は1通りしかないものとします。
っていうのは、言い換えると
「食べ方は、食べ物の種類ごとに決められていると考えてください」
っていうことを言いたいんだと思う。
232 ：
仕様書無しさん：05/03/13 00:11:45
>>228-229 > STLみたいにキーと値のペアが取り出せるイテレータがあっても
> いいのにね。
Jakarta Commons Collectionsにあるコレクションクラスを使うってのもありかもね
233 ：
仕様書無しさん：2005/06/03(金) 21:58:47
デザインパターンを首尾よく使えない言語は糞
いい本がない
235 ：
仕様書無しさん：
age