オブジェクト設計＆デザパタ 2
レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん
2012/02/12(日) 01:58:07.74http://toro.2ch.net/test/read.cgi/tech/1272806908/
0002デフォルトの名無しさん
2012/02/12(日) 02:04:04.50消費税率は変わるわけがない
0003デフォルトの名無しさん
2012/02/12(日) 02:06:51.54消費税率が変わる前に、別のソリューションが見つかるかもしれない
だろ
0004デフォルトの名無しさん
2012/02/12(日) 02:08:45.51マジックナンバーでいい
0005デフォルトの名無しさん
2012/02/12(日) 02:11:34.72これは本質わかってなさげでネタとしても
イマイチだな
0006デフォルトの名無しさん
2012/02/12(日) 02:17:07.630007デフォルトの名無しさん
2012/02/12(日) 02:18:16.280008デフォルトの名無しさん
2012/02/12(日) 02:18:51.870009デフォルトの名無しさん
2012/02/12(日) 02:21:22.81マジックナンバーで思い出したけど、昔レビューでマジックナンバーやめて定数にしろって
指摘したらNUM_1、NUM_2って具合に全部NUM_+元の数値って名前で定数作ってきた
強者プログラマーがいたよ。
0010デフォルトの名無しさん
2012/02/12(日) 02:21:43.83全ての場合に有効な戦略が無いわけだ
じゃあ臨機応変に戦略を変えようって？
それも戦略のひとつとして見れるから全ての場合に有効ではない
どうすればいいんだー＞＜
0011デフォルトの名無しさん
2012/02/12(日) 02:25:30.13ノーフリーランチ定理？
ITの開発って時点で十分に特殊化されてるからYAGNIでも充分やれる
0012デフォルトの名無しさん
2012/02/12(日) 02:27:07.98本質が分かってないな。それでも理系かよ
問題の集合を限定したって、その全てに対して有効な戦略は無いの
0013デフォルトの名無しさん
2012/02/12(日) 02:27:37.64完璧でなくても十分にやれるだろw
0014デフォルトの名無しさん
2012/02/12(日) 02:28:01.91株って過去のデータから予測すんじゃん。でもその予測があってるかどうかって確かめようが無いの
0015デフォルトの名無しさん
2012/02/12(日) 02:28:13.26YAGNIに反するものだが、必要ないと思っていたものが
あとで必要になることはよくあるので、最初に考えておくのもありだろう。
0016デフォルトの名無しさん
2012/02/12(日) 02:29:16.33まあ俺も現実には十分やれるって思ってるんだけど
実は無理というか、信じるしかないことなんだよ
株も過去データを解析して良さそうって思っても最後は信じるしか無いの
0017デフォルトの名無しさん
2012/02/12(日) 02:30:02.36同じ労力で実装できるなら拡張性の高いほうを選ぶな。まあ外部に晒さない程度に
0018デフォルトの名無しさん
2012/02/12(日) 02:31:53.79結論に飛びつき過ぎだ
必要だったからFWに入ったんだ
利用者の一人に過ぎないおまえが必要と感じなかったことは関係ない
0019デフォルトの名無しさん
2012/02/12(日) 09:41:32.01同じ労力なんてありえないけどね
どうやって単体試験通すんだっていう
場所によっては仕様と関係ないコードは全部廃棄になる可能性だってある
if文１つ１つに仕様書との関連を求められるところもある
なんかＶＳのコードカバレッジ機能がついてからそういうの求められるの多くなってきた
0020デフォルトの名無しさん
2012/02/12(日) 09:44:02.23値が限定できるってことは不具合も限定できるってことぐらいはプログラマとして知っておくべき
作って終りなら汎用性重視でもいいけどね
0021デフォルトの名無しさん
2012/02/12(日) 10:11:39.34それこそYAGNIだ。必要ないテストはしない。
0022デフォルトの名無しさん
2012/02/12(日) 11:05:35.10だからさー、そんな仕様書重視してるところのことは例外として考えろよ。
デザパタも糞も一切の議論が成り立たなくなるんだから。
0023デフォルトの名無しさん
2012/02/12(日) 11:49:09.98そうじゃないところなんてそのうち淘汰されるからそれこそ無意味
ついでにお前も淘汰対象
0024デフォルトの名無しさん
2012/02/12(日) 12:18:36.61じゃぁその時に後悔しますｗｗｗ
0025デフォルトの名無しさん
2012/02/12(日) 12:20:21.61それでいいんじゃない
現時点で仕様書いい加減にしてるところが残ってることに驚きだけど
0026デフォルトの名無しさん
2012/02/12(日) 12:23:39.52トータルコストが当初の想定に対してどうだったか。
アジャイルな方法論を採用する場合こそ、そういうメトリクスが必須。
効果測定の欠けたアジャイルは「場当たり無秩序開発」を体よく誤魔化してるだけ。
0027デフォルトの名無しさん
2012/02/12(日) 12:24:22.93> if文１つ１つに仕様書との関連を求められるところもある
いまどき、そんなところが残ってることに驚き。
まぁ儲けなくていいところはのんびりしてるんだろうな。
0028デフォルトの名無しさん
2012/02/12(日) 12:29:11.01>> if文１つ１つに仕様書との関連を求められるところもある
>いまどき、そんなところが残ってることに驚き。
驚く奴がいることに驚き。
0029デフォルトの名無しさん
2012/02/12(日) 12:33:41.24Ｎ○Ｃでも富○通でも三○でも同じような開発方式とってた
日○はもとからアフォかってほど仕様書キチガイだし
もう残ってるとこそんなないだろ
これ以外の方法とってたらプログラマが実は余計なコードばっかり書いてることがわからないから
無駄な金払い続けることになる
0030デフォルトの名無しさん
2012/02/12(日) 12:38:15.73どこも、儲け出さなくていいからのんびりしてるよね。
0031デフォルトの名無しさん
2012/02/12(日) 12:40:35.510032デフォルトの名無しさん
2012/02/12(日) 12:42:39.70設計思想なんてゴミクズ以外なにものでもないだろ
まったく同じソースだって仕様書次第ではそれはゴミにもなりうるってことをプログラマなら知っておくべき
0033デフォルトの名無しさん
2012/02/12(日) 12:44:21.67不具合あってもちょこちょこアップデートすりゃいいとこはノリが軽いよね
0034デフォルトの名無しさん
2012/02/12(日) 12:46:38.19先に作るだけ無駄だよ。
0035デフォルトの名無しさん
2012/02/12(日) 12:46:58.19不具合がなければおｋ
ですんじゃうところはいいな。
0036デフォルトの名無しさん
2012/02/12(日) 12:56:02.230037デフォルトの名無しさん
2012/02/12(日) 12:57:05.140038デフォルトの名無しさん
2012/02/12(日) 12:57:36.33最初から仕様書上の設計って前提で話を進めれば何も問題ないじゃん
仕様書とコードの対応が～とかいうならリファクタリングスレにでもいけよ
日立は試すからなあ‥‥‥
0040デフォルトの名無しさん
2012/02/12(日) 12:58:31.86開発でみんなから邪魔だって言われてるよ君
0041デフォルトの名無しさん
2012/02/12(日) 12:59:35.10え？プログラマ動かすには金が一番楽だけど？
１００万払えば、たいていのプログラマはどんなくだらないプログラムでも
一人月分の仕事してくれるよ。
0042デフォルトの名無しさん
2012/02/12(日) 13:00:44.75自分の好きなオナニーしてただけでしたってことが時代が変わったことでバレちゃった
って話でしたねﾆﾔﾆﾔ
0044デフォルトの名無しさん
2012/02/12(日) 13:03:29.00無理やり動かすのはそれが最強だけど、プログラマなんてそもそも誰に頼まれたわけじゃないのにコーディングしたがる人も多いじゃん
そういう奴らが自発的に作るプログラムのクオリティと開発スピードは世界で一番速いんだろうなって
その作ったプログラムがどんなに要らないプログラムてもさ
0045デフォルトの名無しさん
2012/02/12(日) 13:03:37.26新人：なんだ、こんなゴミ（デザパタ）役に立たないじゃないか！
だいたい仕様書にないクラス勝手に作るって発想がそもそもおかしいだろ！
リーダー：・・・正解だﾆﾔﾘ
0046デフォルトの名無しさん
2012/02/12(日) 13:05:34.27アセンブラレベルで最適化とか、アルゴリズムとか頼まれてもいないのにいろいろ考えちゃうもん
性欲と同じ
0047デフォルトの名無しさん
2012/02/12(日) 13:05:55.230048デフォルトの名無しさん
2012/02/12(日) 13:06:36.400049デフォルトの名無しさん
2012/02/12(日) 13:08:13.760050デフォルトの名無しさん
2012/02/12(日) 13:12:00.53それにしたがってやってるところが多くなったな
大会議場で毎朝５０人ぐらい集まって・・・ってのはなくなったな
昔はよくあったが・・・めちゃくちゃ眠くてあくびがでまくる拷問だった
0051デフォルトの名無しさん
2012/02/12(日) 13:17:00.89脳内コーディングして、脳内にコンパイラが搭載してあるってことだよね
0052デフォルトの名無しさん
2012/02/12(日) 13:22:42.25デザパタみたいに余計なクラス挟むと理由を問い詰められる
0053デフォルトの名無しさん
2012/02/12(日) 13:22:52.03程度によるけどそれが出来ない奴と一緒に仕事したくない
脳内コーディング、脳内コンパイラ、脳内CPUがあるのは普通だと思うんだよ。完璧ってわけじゃないけどね
0054デフォルトの名無しさん
2012/02/12(日) 13:24:28.64そうかｗ仕様書に構造が書いてあるのか(笑
0055デフォルトの名無しさん
2012/02/12(日) 13:26:53.37そのままコードに落とし込まないといけない
そもそも仕様書にない単語を使ったクラスができるわけがないって思想
YAGNI信者の手によってデザパタ勢力は駆逐された
実際余計な汎用性入れないほうがうまくってことがいろんなところでバレちゃったから
オナニーコードはもう作れなくなってる
0056デフォルトの名無しさん
2012/02/12(日) 13:29:25.37なんて短絡的な考え方なんだろう？
そもそもデザパタを理解してないのではないか？
あれは普通に設計をした時によくあるパターンをまとめたもの。
そう、”よくある”ものなんだよ。
デザパタというだけで余計なものといっているところは、
たいていアーキテクチャがない開発を行なっている所だな。
MVCとか全く知らずに、イベントハンドラやURLから呼び出されるコードに
すべてをベタ書きで書いているような所。
0057デフォルトの名無しさん
2012/02/12(日) 13:30:05.57もしかして、デザパタ＝余計なものって
考えてる？
あれはオブジェクト指向でよくあるコードなんだけど
0058デフォルトの名無しさん
2012/02/12(日) 13:31:01.28じゃあ、それを一生懸命説明すればいいんじゃない？
大変だと思うけど
0059デフォルトの名無しさん
2012/02/12(日) 13:32:21.39仕様書にない単語のクラス＝必要ないコードを書きやがったこの馬鹿
って方向で解釈が進むだろうね
0060デフォルトの名無しさん
2012/02/12(日) 13:33:14.03たぶん、君が読んでるのはシステム設計書とかその類のドキュメントだ。
もしかしたらデザパタとか適応された後の。
そりゃ、そこにない構造を設計し始めたら「なんで？」って聞かれるわな。
0061デフォルトの名無しさん
2012/02/12(日) 13:34:19.00たとえば、データが変わった時（それはユーザー操作だったり外部からの命令だったりする）
それに対応する表示項目（複数ある）を一度に変える時どんな作り方をする？
データが変わる要因は複数あるし、また表示項目はカスタマイズできるから色々変わる。
そういうのを作る方法を、お前は思いつかないだろう？
0062デフォルトの名無しさん
2012/02/12(日) 13:35:38.07そんなわけねーじゃん
頭腐ってるだろ？
0063デフォルトの名無しさん
2012/02/12(日) 13:35:43.61-> クラスとかメソッドとかも練る
-> 下っ端に書かせる
下っ端がデザパタとか粋がっちゃうのがうざいってことじゃないの？
一方で少人数制で
とりあえずリーダー的な奴がおおまかな役割分担
-> 仲間が自分のテリトリーを設計しながら書く(デザパタ使ったり使わなかったり)
お互いにレベルが近ければ、こんな感じになるんじゃないの
趣味でしかやってないから、仕様書とか見たこと無いんだけどさ
0064デフォルトの名無しさん
2012/02/12(日) 13:35:55.65ここは設計段階の話するとこ
コーディングするときの話をするとこじゃないの
わかる？
0065デフォルトの名無しさん
2012/02/12(日) 13:36:16.92そーゆーのやめろって方向だって説明したじゃん＞yaguni
0066デフォルトの名無しさん
2012/02/12(日) 13:36:44.89YAGNIは必要なモノを作らないということ。
いいかい、これは顧客からの要求だ。
だから絶対に必要な仕様だ。
0067デフォルトの名無しさん
2012/02/12(日) 13:37:03.37YAGNIは必要な い モノを作らないということ。
0068デフォルトの名無しさん
2012/02/12(日) 13:37:42.610069デフォルトの名無しさん
2012/02/12(日) 13:38:19.39言い訳を考える所、
説き伏せるところじゃないんだよねｗ
自分ができない理由を探すのはやめないか？
0070デフォルトの名無しさん
2012/02/12(日) 13:38:23.12こんなこと言ってるうちはまったくyaguniが理解できてないってことだな
0071デフォルトの名無しさん
2012/02/12(日) 13:38:53.86自分ができない理由を探すのはやめないか？
0072デフォルトの名無しさん
2012/02/12(日) 13:39:54.74前のコードはばっさり捨てて現状必要なコードに書き換えちゃえばいいわけでしょう？
なんでそんな汎用性の話なんてしてんの？
0073デフォルトの名無しさん
2012/02/12(日) 13:41:08.78エクスプローラは、ファイルを消した時に消えるのは当たり前として、
コマンドプロンプトで消したり、ネットワークドライブだとして
他のユーザーが消した時にも消える。
このように、データが変わる要因が複数あるというのは現実的な。
それに対応するのも現実的な話。
自分ができない理由を探すのはやめないか？
0074デフォルトの名無しさん
2012/02/12(日) 13:41:53.41だから、その「現状必要なコード」をお前にかけんの？って聞いてるんだろｗ
0075デフォルトの名無しさん
2012/02/12(日) 13:42:56.740076デフォルトの名無しさん
2012/02/12(日) 13:49:48.970077デフォルトの名無しさん
2012/02/12(日) 13:49:51.77Chromeは以前はプラグインの仕組みを持っていなかったが
ユーザーの要求により、プラグインの仕組みを搭載した。
同じように自分の作ったアプリにプラグインの仕組みをユーザーに要求された。
プラグインの仕組みを実装しなければならない。
さあ、どうやって作る？
0078デフォルトの名無しさん
2012/02/12(日) 13:50:27.86・一緒に作る人が分かりやすいように
・未来の自分が読み返しても分かりやすいように
・自分がもっとも書きやすいように
自分も含めてなお互いに思いやる気持ちが大事
日本発の「OMOIYARI」思想な
0079デフォルトの名無しさん
2012/02/12(日) 13:50:37.73仕様書になんて書いてあんのさｗ
お前の脳内仕様書なんか、お前が言わないと
誰にも伝わらないぞ。
0080デフォルトの名無しさん
2012/02/12(日) 13:51:34.54コピペで済ませました。
そしたらコードレビューで突っ返されました。
なぜですか？
0081デフォルトの名無しさん
2012/02/12(日) 13:52:23.16そうだ
仕様書になんて書いてあるんだ？
仕様書になんて書いてあるのかわからないのに無意味な話はやめろよ
0082デフォルトの名無しさん
2012/02/12(日) 13:53:59.92普通書いてあるものなのか？
言っとくが書いてないから使わないという意味じゃないぞ。
仕様書に、わかりやすい変数名を使うとか、
関数にするとか書いてないだろ？
それでも普通はそうするだろう？
仕様書を持ち出している時点で根本的に間違いじゃないかってことだぞ。
0083デフォルトの名無しさん
2012/02/12(日) 13:55:14.47いや、それは間違い
仕様書の通りに作るのが真
どうやって作るのかわからないときは担当者にたずねるか突き返すのが真
書いてないからデザパタ適用なんて話はありえない
0084デフォルトの名無しさん
2012/02/12(日) 13:56:05.66書くなら「デザインパターンを使え」ではなくて
「プラグインに対応する」だな。
で、プラグインを実装する時
デザインパターンは無駄な物と言ってる人は、
どうするのさ？
0085デフォルトの名無しさん
2012/02/12(日) 13:56:26.560086デフォルトの名無しさん
2012/02/12(日) 13:58:58.68そして担当者に突き返したとして、
担当者はなんて答えるの？
担当者はデザパタを使え！って答えてくれるの？
その担当者って、プログラミング素人じゃないのか？ｗ
0087デフォルトの名無しさん
2012/02/12(日) 14:00:30.07例の馬鹿だと、
プラグインの作り方がわからないんです。
教えてください。だろうなｗ
それを考えるのが開発者の仕事だろうが！って
一喝されるだけだが。
0088デフォルトの名無しさん
2012/02/12(日) 14:01:01.28デザパタなんて関係ない
しかるべき仕様を書いてくれる
書いてないときはもう一度つきかえす
デザパタは出てこない
0089デフォルトの名無しさん
2012/02/12(日) 14:02:44.96だから、仕様書にはデザパタがでてこないってことだろ？
当たり前だよ。それは関数にしろって仕様書に書いてないのと同じ事
だからといって、デザパタを使わないってことにはならない。
もう一度聞く、プラグインに対応するという仕様があったとき
お前はどうするんだ？
0090デフォルトの名無しさん
2012/02/12(日) 14:03:26.360091デフォルトの名無しさん
2012/02/12(日) 14:04:07.450092デフォルトの名無しさん
2012/02/12(日) 14:05:47.80別にいいけど仕様書にはちゃんとわかる言葉で書いてもらうよ
デザパタなんて単語は出てこない
0093デフォルトの名無しさん
2012/02/12(日) 14:06:06.23自分が、その担当者の立場になることは
永遠にないって思ってるのか？
その担当者の立場になったとして
自分の頭で考えて判断してみなさいよ。
0094デフォルトの名無しさん
2012/02/12(日) 14:06:45.52それは、デザパタの実装方法を、
詳細に書けってことなのか？
0095デフォルトの名無しさん
2012/02/12(日) 14:06:50.88> 書いてないときはもう一度つきかえす
それって、世間一般ではコーダーって呼ばれる人たちのことじゃないの？
0096デフォルトの名無しさん
2012/02/12(日) 14:08:46.15馬鹿「それじゃわかりません。詳細な実装方法を教えて下さい」
担当者「じゃあオブザーバーパターンを使って」
馬鹿「それじゃわかりません。詳細な実装コードを教えて下さい」
担当者「デザインパターンの本を読んで勉強してください」
馬鹿「いやです。俺の分かる言葉でちゃんと書いてもらうよ」
0097デフォルトの名無しさん
2012/02/12(日) 14:09:13.410098デフォルトの名無しさん
2012/02/12(日) 14:10:19.10仕様書と設計書を混同している。
0099デフォルトの名無しさん
2012/02/12(日) 14:11:01.000100デフォルトの名無しさん
2012/02/12(日) 14:12:49.76それで正しい
んで実際に仕様書に書いてみたときに
そのデザパタが使える場面なのか？
仕様は満たしているのかわかるだろ？
0101デフォルトの名無しさん
2012/02/12(日) 14:13:28.28どういうコードを書くかってのは、いずれにしろ
開発の中で誰かが決定しなければならないわけだけど
俺はそれを決定する人ではないから突き返すってことでしょ？
0102デフォルトの名無しさん
2012/02/12(日) 14:13:52.29お前は、馬鹿なのか？
一生担当者にはならないのか？
0103デフォルトの名無しさん
2012/02/12(日) 14:14:39.24仕様書でしかないだろ
デザパタ使ってくださいはありえない
0104デフォルトの名無しさん
2012/02/12(日) 14:14:44.31デザパタが使える場面だったらどうする？
やっぱり、デザパタというだけで
無駄なものって判断しちゃうの？
0105デフォルトの名無しさん
2012/02/12(日) 14:15:36.45デザパタつかえることを証明するのは仕様書担当者の仕事
0106デフォルトの名無しさん
2012/02/12(日) 14:15:40.40仕様書じゃわからない。実際に書かれたコードを見て
デザインパターンを使うか判断する。
0107デフォルトの名無しさん
2012/02/12(日) 14:15:49.66学生か？仕様書と設計書の違いくらい勉強しろよ。
0108デフォルトの名無しさん
2012/02/12(日) 14:16:10.78じゃあ、お前が仕様書担当者と仮定して考えろ。
0109デフォルトの名無しさん
2012/02/12(日) 14:16:38.33いままでそんなヌルイ開発しかしてこなかったから責任の切り分けもできない猿になったんだな
0110デフォルトの名無しさん
2012/02/12(日) 14:16:51.44だからね
ここはね仕様書書いてる人たちが設計やデザインパターンについてお話するとこなの
コードを書く人が勝手にデザインパターンをつかってどうのこうのっていうのはスレ違いなの
わかる？
0111デフォルトの名無しさん
2012/02/12(日) 14:17:43.93仕様書「プラグイン機能搭載」
設計「○○パターンを使ってこういう設計に使用」
プログラマ「よっしゃ○○パターンだな！バリバリ書くぜ！」
コーダー「俺の分かる言葉で書け！」
0112デフォルトの名無しさん
2012/02/12(日) 14:18:07.87そう思ってるのは君だけかもねｗ
0113デフォルトの名無しさん
2012/02/12(日) 14:18:52.040114デフォルトの名無しさん
2012/02/12(日) 14:19:06.38わかってると思うけど
仕様書に○○パターンなんて書くのはダメ
0115デフォルトの名無しさん
2012/02/12(日) 14:19:39.21書いてないだろｗ
0116デフォルトの名無しさん
2012/02/12(日) 14:20:03.54元の概要設計書をいつだつしてヘンテコな汎用性を担当者が入れる余地も消えたし
ホント開発がスムーズになったわ
0117デフォルトの名無しさん
2012/02/12(日) 14:20:22.66言ってる奴がいるようだなｗ
0118デフォルトの名無しさん
2012/02/12(日) 14:20:56.81お前YAGNIとか言うレベルにないぞｗ
0119デフォルトの名無しさん
2012/02/12(日) 14:27:12.28ああ、なんかつづり違うしな
0120デフォルトの名無しさん
2012/02/12(日) 14:35:56.130121デフォルトの名無しさん
2012/02/12(日) 14:47:01.59だからイスにはこだわってる
0122デフォルトの名無しさん
2012/02/12(日) 14:56:07.73何から何まで他人が判断。
そのくせ一人前気取り
あぁ、学生バイトか。
0123デフォルトの名無しさん
2012/02/12(日) 15:08:56.00YAGNIってそういう話だろ？
今はYAGNIで素早く作るが拡張要求が来た時には「こう変更する」
という事まで想定してこそのYAGNIだろ。
拡張に対する想定の甘いYAGNIなど炎上確定じゃないか。アホかと。
0124デフォルトの名無しさん
2012/02/12(日) 15:14:48.18いや、シンプルに作っておけば破棄するだけだからｗ
君みたいなのいらないからｗ
0125デフォルトの名無しさん
2012/02/12(日) 15:24:43.43だから破棄して、次は
拡張性のあるものを作るんだろ？
まさか、次も拡張性のないものを作って
何度も何度も無駄な開発を続ける気か？
0126デフォルトの名無しさん
2012/02/12(日) 15:38:19.95拡張性なんてつけないよ
yagniに従う（今度はつづりは間違えないぞ）
0127デフォルトの名無しさん
2012/02/12(日) 15:39:42.24お前が拡張性をつけないなんて判断するな。
上のものに確認しろ。馬鹿かなのか？
0128デフォルトの名無しさん
2012/02/12(日) 15:41:28.870129デフォルトの名無しさん
2012/02/12(日) 15:46:10.610130デフォルトの名無しさん
2012/02/12(日) 15:47:50.95仕様書と設計書と指示書を混同してる。
コーダーが作業指示書をくれと言ってる
0131デフォルトの名無しさん
2012/02/12(日) 16:13:49.60あんなもんCOBOLer以外で今時書いてる連中がいるなんてビックリなんだが
0132デフォルトの名無しさん
2012/02/12(日) 21:29:04.69だったら仕様書にそう書けよ
0133デフォルトの名無しさん
2012/02/12(日) 21:30:58.000134デフォルトの名無しさん
2012/02/12(日) 21:48:52.99ちゃんとどう拡張するか書いてなかったら即突っ込むけどね
0135デフォルトの名無しさん
2012/02/12(日) 21:51:46.510136デフォルトの名無しさん
2012/02/12(日) 22:00:39.95問題ないな
デザパタ入れる余地もなくすべてがかっきり決まってどこも動かせない状態じゃん
よかったな
後は組むだけだな
0137デフォルトの名無しさん
2012/02/12(日) 22:02:34.75お前じゃなくて、担当者でしょ。
担当者がデザパタを入れると書いてました。どうしますか？
0138デフォルトの名無しさん
2012/02/12(日) 22:11:05.48デザパタは仕様書や設計書に書いちゃいかんだろ
あくまでこういう構造にしますっていうだけ
その構造がデザパタだったとしてもそれは仕様書にはかかれない
0139デフォルトの名無しさん
2012/02/12(日) 22:11:36.22知らなくて、担当者に聞くのは勝手だし、
担当者が、丁寧にパターンのコーディング方法を教えくれるかもしれないが、
その教えてもらったコードの書き方は、やっぱりデザインパターンなんだよ。
0140デフォルトの名無しさん
2012/02/12(日) 22:12:19.57それがデザインパターン・・・
0141デフォルトの名無しさん
2012/02/12(日) 22:16:15.840142デフォルトの名無しさん
2012/02/12(日) 22:17:33.600143デフォルトの名無しさん
2012/02/12(日) 22:17:46.50まず、仕様と設計を区別できるようになろうな。
でざぱたとかいうのはそれからだ。
0144デフォルトの名無しさん
2012/02/12(日) 22:20:39.05書き方を丁寧にレクチャーすれば、
コーダーにとっては知らなくてもいいものだろうねｗ
普通さ、アーキテクトがここは○○パターンにしますって書けば
あとはプログラマが自分で考えて作るもんだろ。
サンプルがあれば間違いが少なくなるが
実際に動くものを作るのはプログラマだ。
コーディング方法を教えてもらわないと書けない奴は
開発の最下層の最下層、絶滅危惧種のコーダーだけ。
0145デフォルトの名無しさん
2012/02/12(日) 22:25:00.50それはダメだろうな
デザパタの何がどのクラスになるかまでちゃんと書かないとそれは設計までやったことにはならない
適用したデザパタがその仕様にふさわしいかどうかの検証は省くことはできない
0146デフォルトの名無しさん
2012/02/12(日) 22:27:27.07ちゃんと書いてあったとしましょう。
0147デフォルトの名無しさん
2012/02/12(日) 22:29:47.79したらデザパタ云々仕様書に書く必要ないよｗ
でも要件定義から外れてるだろうからツッコミくるだろうね
0148デフォルトの名無しさん
2012/02/12(日) 22:30:17.94今まで全部客や上司に指示されたとおりにプログラミングしてただけなのに、
周りのプログラマが設計までやりだしたのを見て、あせってるのか。
0149デフォルトの名無しさん
2012/02/12(日) 22:34:29.48スポーツでファインプレーばっかしようとするやつなんだよ
その一瞬だけ見ればすごくみえるかもしれない
だけど内心チームのみんなは迷惑してんだよ
お前だけだからさ、すげーとおもってるの
0150デフォルトの名無しさん
2012/02/12(日) 22:35:07.79なんでデザインパターンを使うと要件定義から外れるの？
あと仕様書に書く必要がない理由は何？
0151デフォルトの名無しさん
2012/02/12(日) 22:36:21.56時代がかわってデザパタとか詐欺まがいのもんが役に立たなくなって清々してるだけｗ
俺、ここの辺って改善されると思ってなかったらめちゃくちゃ驚いてる
必要なクラスを必要なだけって時代がくるとは思わなかった
誰がプログラマの作ったクラスおよびクラス構造が適切だと説明できるんだろうとか
考えてたけど時代が変わればできるようになるもんだな
0152デフォルトの名無しさん
2012/02/12(日) 22:38:09.90仕様書には要件定義を満たす内容だけが書いてあればいい
デザパタは余計だ
だってそれがデザパタだろうがなんだろうが要件定義を満たせなきゃ意味がない
そしてそれを説明および証明するのは仕様書を書いた本人しかいないから
0153デフォルトの名無しさん
2012/02/12(日) 22:40:46.65ファインプレーでもなんでもなく、定石なんだけどな。
スポーツで言えば、教科書で習うくらいの基本プレー。
俺の設計すげーだろみたいな独自設計てんこ盛りのほうが
迷惑だし、考え付いた本人は満足してるかもしてないけど
デザパタの劣化コピーでしかないことも多い。
0154デフォルトの名無しさん
2012/02/12(日) 22:43:47.64あぁ、それはなんつーかややこしいところは大体フレームワークが
面倒見てくれて、フレームワークに則って作業すればシステム作れますよ
っていう仕事が増えたってことだ。
0155デフォルトの名無しさん
2012/02/12(日) 22:43:48.38なんで？なんで？なんで？
なにがいいの？何を考慮したの？
それはどのくらいお金になるの？
工数はどれだけ減るの？
なんで？なんで？なんで？
大抵・・・説明できない＝役に立たない
0156デフォルトの名無しさん
2012/02/12(日) 22:45:22.880157デフォルトの名無しさん
2012/02/12(日) 22:47:03.34そりゃまぁ、仕事に沿った定石集集めたら
「○○システム作成のデザインパターン集」
ってことになって使えるところが少なくなるからな。
0158デフォルトの名無しさん
2012/02/12(日) 22:47:31.11意味がわからない。
デザパタを使うと上が決めて、
その詳細なコードが丁寧に書いてある。
お前はそれをデザパタとわからないが、
デザパタは使われている。
あってるよな？
0159デフォルトの名無しさん
2012/02/12(日) 22:48:30.30まず、デザパタは余計なクラスではなく、
実践上よくあるパターン、つまり必要なクラスであると
認識を正すことから始めよう。
0160デフォルトの名無しさん
2012/02/12(日) 22:48:37.22それは環境が悪いぞ。もっと周りのレベルの高いところへ行ったほうが自分のためにもなる
0161デフォルトの名無しさん
2012/02/12(日) 22:49:48.25あー、フレームワークを使ってるから
デザパタは必要ないって考えてる人かもね。
でも、実際はフレームワークでデザパタ使われてるよね。
0162デフォルトの名無しさん
2012/02/12(日) 22:50:23.52上流工程は嫌です。
言われたことだけやりたいです。
0163デフォルトの名無しさん
2012/02/12(日) 22:51:14.65動くもんでっちあげれば
美しくするのなんて瞬殺だろ？
0164デフォルトの名無しさん
2012/02/12(日) 22:51:24.40プログラミングもできない奴が偉そうにしてるスレ
0165デフォルトの名無しさん
2012/02/12(日) 22:52:49.14つまり、リファクタリングするわけですね？
0166デフォルトの名無しさん
2012/02/12(日) 22:53:22.38デザインパターンはかなり枯れた技術なんですが
0167デフォルトの名無しさん
2012/02/12(日) 22:53:33.52それは仕様をみないとわからないよね
0168デフォルトの名無しさん
2012/02/12(日) 22:54:19.690169デフォルトの名無しさん
2012/02/12(日) 22:54:58.60仕様も確認しないで
デザパタが必要なクラスとかいっちゃう奴がこの掲示板にもこんなにたくさんいる状況じゃ
無理だって思うだろ
0170デフォルトの名無しさん
2012/02/12(日) 22:55:11.12じゃあ、仕様を見て問題がなかったとしましょう。
0171デフォルトの名無しさん
2012/02/12(日) 22:55:49.17前提として仕様に問題がない場合の話だよ。
0172デフォルトの名無しさん
2012/02/12(日) 22:56:49.87なんの話してんの？
わからないなら途中参加なんてしないほうがいいよｗ
0173デフォルトの名無しさん
2012/02/12(日) 22:57:12.84言ってることがおかしい。
まずお前の言ってることだと、仕様にデザインパターンは書かれていない。
だから、そこにデザインパターンが使われているかどうかは、お前が知ることはできない。
なのに仕様を確認して何が分かるというのだ？
0174デフォルトの名無しさん
2012/02/12(日) 22:57:46.53自分に好都合な前提で話すのやめろよ
0175デフォルトの名無しさん
2012/02/12(日) 22:58:21.66お前はいっていることだけやっていればいい。
デザインパターンを使う使わないは俺が判断して
必要なときに組み込む。
お前は何も言わなくていい。
0176デフォルトの名無しさん
2012/02/12(日) 22:58:43.87うーん、例の人は自分であーだこうだ設計するところはあまり肌に合わないんじゃないかな。
できれば作業手順までかっちりきっかり決められてて、それに沿った作業を進めていくような
現場のほうが向いていると思う。
0177デフォルトの名無しさん
2012/02/12(日) 22:58:50.53デザパタは要件定義を満たせてかつ余計な仕様をいれない内容かね？
0178デフォルトの名無しさん
2012/02/12(日) 22:59:12.55お前はいっていることだけやっていればいい。
デザインパターンを使う使わないは俺が判断して
必要なときに組み込む。
お前に支持出すときは、デザインパターンという
用語は使わないでおいてやるから安心しろ。
お前は何も考えなくていい。
0179デフォルトの名無しさん
2012/02/12(日) 22:59:33.90バーカ
人によらねぇんだよ
プログラムなんて仕様どおりに組めなかったらゴミだ
0180デフォルトの名無しさん
2012/02/12(日) 23:00:03.56当たり前だろｗ
お前より頭がいいやつが考えることだぞ。
0181デフォルトの名無しさん
2012/02/12(日) 23:00:36.84まず、仕様と設計の区別ができるようになろうな。
0182デフォルトの名無しさん
2012/02/12(日) 23:00:44.91お前が要求する仕様、
たとえば「クイックソートを実装しろ」って書いてあったら
それでOKだしますか？
0183デフォルトの名無しさん
2012/02/12(日) 23:01:06.320184デフォルトの名無しさん
2012/02/12(日) 23:01:44.38クイックソートという用語と同じようなもんだろ。
0185デフォルトの名無しさん
2012/02/12(日) 23:01:49.10意味がわからない
なんでクイックソートの必要があるの？
0186デフォルトの名無しさん
2012/02/12(日) 23:02:28.410187デフォルトの名無しさん
2012/02/12(日) 23:02:30.08それが仕様だから。
0188デフォルトの名無しさん
2012/02/12(日) 23:03:45.04要件定義にはなんて書いてあるの？
0189デフォルトの名無しさん
2012/02/12(日) 23:03:48.44書いてもらってそれが妥当な場合はどうする？
あと、必要なのはそれだけだろ？
仕事するの？しないの？
0190デフォルトの名無しさん
2012/02/12(日) 23:04:09.90いかに仕様どおりに組むかという方法論として、
デザパタなどの設計が出てくるってのは理解してる？
設計がいらない類の仕事であれば、意識する必要はないだろうけど。。
0191デフォルトの名無しさん
2012/02/12(日) 23:05:55.74だめだというのなら、どんな仕様ならお前はいいんだ？
それを書けといったよね。
ちゃんと質問に答えてよ。
0192デフォルトの名無しさん
2012/02/12(日) 23:06:57.29仕様が要件定義を満たしているかどうか？
これをデザパタが満たせるような内容の要件定義、仕様書は正直デザパタから逆算でもしない限り
ありえないといっておく
だから現場のデザパタつぶしはおもしろい
0193デフォルトの名無しさん
2012/02/12(日) 23:07:08.34これならOK
0194デフォルトの名無しさん
2012/02/12(日) 23:07:29.650195デフォルトの名無しさん
2012/02/12(日) 23:08:43.82前の方の○○に、パターン名が入るわけですねｗ
0196デフォルトの名無しさん
2012/02/12(日) 23:08:53.56あれあれ？勝利宣言ですか？ﾆﾔﾆﾔ
0197デフォルトの名無しさん
2012/02/12(日) 23:09:24.89なら、そうなんだろうね。お前の中ではな
0198デフォルトの名無しさん
2012/02/12(日) 23:09:49.61お前みたいなクズに俺が負けるわけないじゃんｗ
0199デフォルトの名無しさん
2012/02/12(日) 23:10:28.46あれあれ？捨て台詞ですか？ﾆﾔﾆﾔ
0200デフォルトの名無しさん
2012/02/12(日) 23:11:01.46いいよいいよ
かかっておいで
0201デフォルトの名無しさん
2012/02/12(日) 23:12:28.530202デフォルトの名無しさん
2012/02/12(日) 23:16:18.74そういう楽な仕事がよかったがそんな仕事はこの世にねぇからな
どうでもいい
0203デフォルトの名無しさん
2012/02/12(日) 23:20:06.58プログラマー１
「これはステートパターンでいいよね」
デザパタ嫌い
「なぜステートパターンなんかつかうんですか？
ステートなんて仕様書に書いてないですよ？
仕様書を書き下せば全部実装できるのに、馬鹿じゃないんですか？」
こんな感じかな。
0204デフォルトの名無しさん
2012/02/12(日) 23:24:30.58なんで書いてあるんですか？ って文句言うだろｗ
0205デフォルトの名無しさん
2012/02/12(日) 23:24:44.85彼(?)は仕様と設計とコーディングの間で、過不足があるのが嫌なんだ。
コーディングは仕様と完全に一対一対応じゃないといけないと。
そういう信念を持つのはいいが、
押し付けられるのは迷惑だからやめてくれ。
0206デフォルトの名無しさん
2012/02/12(日) 23:27:23.240207デフォルトの名無しさん
2012/02/12(日) 23:32:46.170208デフォルトの名無しさん
2012/02/12(日) 23:43:14.95俺がこういうシステムを作るからこうしろ
こうこうこんな感じで拡張するかもしれねーからここはこれで
これならもんだいねーんだよ、うまくいく
0209デフォルトの名無しさん
2012/02/12(日) 23:45:36.00実装者は地獄だぜぇ
0210デフォルトの名無しさん
2012/02/12(日) 23:51:00.32設計者が小難しい客の要望をすべて盛り込んだものを設計してくれるんだから実装者は楽なもんだろｗ
0211デフォルトの名無しさん
2012/02/12(日) 23:53:28.13↓
継承よりコンポジション。無駄に継承すんな。
↓
GoFのデザインパターン！どや！
↓
デザパタなんかいらないんや！ ← いまここ
0212デフォルトの名無しさん
2012/02/13(月) 00:24:54.480213デフォルトの名無しさん
2012/02/13(月) 00:50:48.900214デフォルトの名無しさん
2012/02/13(月) 01:01:02.28いや、
①ステートパターンってなんですか？説明お願いします
②それをこの仕様に適用するとどのクラスがどの仕様をみたしているんですか？
③これは仕様に対していらないクラスじゃないんですか？
の流れ
0215デフォルトの名無しさん
2012/02/13(月) 01:35:08.66それはコーダーのお前が考えることではない。
言われたことだけやれ。の一喝で終わり。
0216デフォルトの名無しさん
2012/02/13(月) 01:35:51.82スタート前
↓
ゲーム中→編集状態→ゲーム中に戻る
↓
ゲーム終了 or スタートに戻る
っていうシンプルな状態遷移なんだけど
これをステートパターンで書き直したら予想以上にプログラムがシンプルになった。
各状態特有のクラス変数をキープさせるとその効果が現れる。
単純な状態遷移ではなんらメリットは無い。
0217デフォルトの名無しさん
2012/02/13(月) 01:54:12.60何も考えず４つのステートクラスをインスタンス化しておく。
これを前提にするだけで関連するステップ数が約半分になる。
カラクリは説明が難しい。プログラミングすれば実感としてわかるだろう。
しかし仕様や基本設計している人にこれを理解させるのは至難の業。
0218デフォルトの名無しさん
2012/02/13(月) 02:33:50.15内部がどう実装されていようがSEとしてはしったこっちゃないよ。
ステートパターンがとか各状態特有のクラス変数が～の説明なんか
これっぽちっも聞きたくない。
0219デフォルトの名無しさん
2012/02/13(月) 02:43:56.89SEの仕事は、ただの御用聞きだと思ってる？
システムのエンジニアリングを全くしないのか？
0220デフォルトの名無しさん
2012/02/13(月) 02:47:52.63仕様作成を上流ＳＥもしくはＰＭ、基本設計を下流ＳＥ、プログラミングをＰＧがやる会社があったとして。
少なくとも下流ＳＥにはＰＧ経験が無いとダメだと思うのは上記の理由。
>>218なんかSadism Engineerじゃないかと思えてくる。
0221218
2012/02/13(月) 02:54:59.27状態遷移図や表を書いても、クラス構造やデザインパターンがって
レイヤーまでは降りる必要はないでしょ。
そこまでSEが担当しなくちゃならんのだったらよっぽどプログラマーが
ヘボいか、作業の割り振り間違ってるぞ。
0222デフォルトの名無しさん
2012/02/13(月) 02:55:51.95だから仕様書に書いてないことはやらない。
突っ返す。
0223220
2012/02/13(月) 03:08:54.80しかし設計フェーズでの状態遷移図はそれとは別物であり、
デザインパターンを使うならばツボを知らない奴が設計すれば
下流フェーズで無駄な工程を増やすだけ。
それならデザインパターンを使わない方がマシ。
0224デフォルトの名無しさん
2012/02/13(月) 03:10:59.17ツボを知らない奴が設計すれば
下流フェーズで無駄な工程を増やすだけ。
0225デフォルトの名無しさん
2012/02/13(月) 03:12:41.32全く皮肉になってないねｗｗｗ
0226デフォルトの名無しさん
2012/02/13(月) 03:20:43.97ツボを知らない奴が設計すれば、無駄な工程が増える。
当たり前の話。
0227デフォルトの名無しさん
2012/02/13(月) 03:28:13.79お互いに使ってる言葉が表面上は同じでも、それぞれの思う意味が全然違う気がする
具体的に仕様書書いてうｐしたりさ、具体的に問題設定してみんなで設計してコーディングしてみたりさ
そういうことから一体感が生まれてくると思うんだよな。一仕事終わった頃にはもう10年来の友達みたいな感じでさ
0228216,217,220
2012/02/13(月) 03:32:02.51A.ステートパターンは各ステートごとの内部状態を保持するとプログラムが(劇的に)シンプルになる。
B.しかしただの状態遷移のためだけにステートパターンを用いるならば無駄。
C.それなら変数に各状態に割り当てた数値を入れておく方がマシ。
A.デザパタはいい B.でもツボを知らない C.ならば使わない方がマシ
0229デフォルトの名無しさん
2012/02/13(月) 04:02:16.21一律無駄なものって結論出たよね？
なんで俺の許可無く、話を蒸し返して進めてるのさ。
0230デフォルトの名無しさん
2012/02/13(月) 04:05:27.75スレ立てた身としても嬉しい
0231デフォルトの名無しさん
2012/02/13(月) 04:07:18.320232デフォルトの名無しさん
2012/02/13(月) 04:12:20.58・・・ファクトリーがうざいって言ったやつ
やっぱ俺ってそういう選球眼っていうのかな
時代の流れを読む力だけは昔からあるっていわれるんだよな
0233デフォルトの名無しさん
2012/02/13(月) 04:14:12.16しかも初代スレ立てたのが俺。
0234デフォルトの名無しさん
2012/02/13(月) 04:15:25.12デザパタっていうのまったく知らなかったから、世間での扱われ方みたいなのが分かってよかった
争いの種なのな
なんか俺が始めようとしてるところでは、デザパタ覚えろみたいに言われてさ
そんなにすげえものなのかなって話出してみたらこれだよ。業界のタブー
0235デフォルトの名無しさん
2012/02/13(月) 04:16:06.99そうだったのか。あの時は噛み付いてごめんな
0236デフォルトの名無しさん
2012/02/13(月) 04:17:06.52最初の方にちゃんと書いてあるよ。
デザパタとはよくあるパターンをまとめたもので
別に新しく作ったものじゃない。
名前をつけたことが、一番の価値なのだ。みたいなこと
0237デフォルトの名無しさん
2012/02/13(月) 04:17:47.27なあに、こうしてデザパタの素晴らしさが
世の中に認知されたのだから、何の問題もない。
0238デフォルトの名無しさん
2012/02/13(月) 04:20:23.93話が通じるようになった。
設計を説明されながら、ああ、あんな感じのやつね。
なんとなくわかるよ。みたいなことが少なくなった。
名前を言うだけで通じる。
設計を提案するときも、事細かくラスの役割を
説明する必要もないし、未熟者には、
デザパタを勉強しろと言うだけで住む。
デザパタは重要なものなんだな
0239デフォルトの名無しさん
2012/02/13(月) 04:27:43.36> そうだったのか。あの時は噛み付いてごめんな
お前が噛み付いていたのは、片袖さ
片袖はもともと噛み付かれるためにある。
片袖が何で何が目的なのかはぐぐってね。
0240デフォルトの名無しさん
2012/02/13(月) 04:35:53.150241デフォルトの名無しさん
2012/02/13(月) 06:43:11.99http://www.chosunonline.com/site/data/html_dir/2012/02/11/2012021100371.html
米国で大統領補佐官（国家安全保障担当）を務めたブレジンスキー氏は「韓国が米国との同盟を
強く望んだとしても、米国が韓半島から手を引く時代は少しずつ近づいている」と指摘する。
韓国には「中国による東アジアの覇権を受け入れ、中国とさらに接近する」道と、（反日行為をやめて）
「歴史的な反感にも関わらず、日本との関係をさらに強化する」という二つの道が選択肢として提示されていると明言した。
「中国に頼る」ということは、中国の付属品のように屈従して延命を図り、その下で生き延びるという意味だ。
「日本と手を結ぶ」ことについては、説明する必要もないだろう。
与党も野党も、あるいは右も左も関係なく、韓国のあらゆる政治勢力は、
この状況で5000万の国民をどちらの方向に導くか、決断を下さなければならない。
米国 「もう韓国は捨てるから、中国の植民地になるか、親日になり日本の植民地になるか選べよ」 ★３
http://engawa.2ch.net/test/read.cgi/poverty/1329035247/
0242デフォルトの名無しさん
2012/02/13(月) 07:57:09.38要件定義仕様書
2人対戦オセロが欲しいという客の要望あった
ネットワーク対戦が必要か？
AIを実装する必要があるか？
時間制限を設ける必要があるか？
などをSEが客から聞き出して作成する
基本設計書 機能仕様書
AIを作るためには、αβ法を使う
インプットには、これとこれを入れると評価関数を利用して盤面の結果が帰ってくる
のように要件定義仕様書で必要とされるものを実現するためにシステムとして何が必要かを考えて作成する
ここまでは上流SEが作る
当然技術的な知見が必要である
実現できないことを客の要望として受け入れてはいけない
客の要望をどのようにシステム化するかイメージできなければいけない
またここから作業するデベロッパーの設計、コードレビューをできなければいけない
0243デフォルトの名無しさん
2012/02/13(月) 08:17:36.02詳細設計書（ソフト設計）
基本設計で必要となった機能をクラス、関数の引数、返り値レベルまで落とし込んで作成する
実際にコードレベルでどのように作成したら、品質を確保して動く物を作るか考える
ここではソフト設計を行う（デザインパターンを適用するならここ）
しかしこれはほぼコーディングしているのと同等な作業であるためコーディングせずに設計書上で頭を悩ませる必要性がわからない
引継のためにドキュメントが必要という主張をよく聞くが それは設計書ではなくAPI仕様書などであり、実装完了前に存在する必要はない
コードを作成した後コードからクラス図とAPI仕様書を自動生成すれば充分である
そもそもコードを書かずに完璧なコーディングや設計ができるというのは思い上がりも甚だしい（もちろん実装しながら補助的に、頭の整理をするため、他人に簡易的に説明するためにUMLを利用するのは有用である）
ひどいところでは擬似コードみたいな実装に1行ごとに対応したものを書く
それならコード書けと言いたい
この勘違いは、コードを成果物と捉えているため
成果物はあくまでも実行できるバイナリであり、コードは設計書の1つである
設計書のための設計書は必要ない
0244デフォルトの名無しさん
2012/02/13(月) 08:44:34.18俺はプログラマだ。
そして俺がデザパタ知らなかったとする。
そういう場合でも俺は問題なく作れるよう、
クラスとその役割、書き方、そしてそうした理由など
俺が間違えなく書けるようにちゃんと書いておけという話。
プロだろ？
0245デフォルトの名無しさん
2012/02/13(月) 09:04:15.52動く者を作るだけなら時間をかければ一年目のプログラマーでも可能
（1つのクラスで全機能実装とか）
そのため日本のIT業界では品質無視のクソコードが量産される
そしてクソを作ったSEはこのあと上流SEとなるため、デザインパターンもわからない糞上流SEが生み出される
本来はコーディングと平行しながら設計していくが、日本では中流以上のSEが脳内糞コンパイラで糞設計を行う
このSEはデザインパターンも知らずいったい何を目指して設計しているのか？
その1つ1つのクラス分けの意味を説明して欲しい
オブジェクト指向設計の原則は最低限理解すべきものであるが、大半が存在すらしらない
そして日本では、その糞詳細設計書をそのままコードに落とすのがプログラマーの仕事だと考えられている
（当然設計書そのまま実装したところで動かない。何度でも言うがコードと対応するなら最初からコードを書け。
結局プログラマーが現実に合わせるために修正するため、詳細設計書の作成作業は無駄というか足枷となる。）
そのためプログラミングは単調作業であり評価に値しないというのが日本の風潮
その結果どうなったかは、近年騒がれている日本のIT業界の結果を見れば明らか
また優秀な人間は外資、日本なら技術者を評価しているモバゲーやDeNAなどの儲けているベンチャーに移っている
とSIerでもその下請けでもない第三者の感想
0246デフォルトの名無しさん
2012/02/13(月) 09:10:53.04そもそもプログラマーの役割を勘違いしている
デザパタを適用すべきどうかを検討するのが仕事だ
俺の仕事はソフト設計ではなく、関数の中身を実装することたというなら一生IT土方として頑張ればいい
もちろん詳細設計書のクラス図でデザパタを使っていたら、おもえはクラス図のとおりにクラスを作れば、理解していなくても自然とデザパタを書いたことになる
まあそんな環境の上が設計を理解しているとも思えないから、デザパタも登場しないだろう
やはり君にはデザパタは必要ないから忘れていいよ
0247デフォルトの名無しさん
2012/02/13(月) 09:17:17.29何も考えず手を動かす単純労働者なら説明はいらない
工事現場の人間に、建築家は設計理論を０から説明しないでしょ
こことここにネジを止めろで充分
とSIerは考えていると思うよ
0248デフォルトの名無しさん
2012/02/13(月) 09:24:10.20>技術者を評価しているモバゲー
これを取り消せ。統括している奴が「出来すぎる奴のコードは他人に解らないからダメ」とほざいてた。
0249デフォルトの名無しさん
2012/02/13(月) 09:32:52.020250デフォルトの名無しさん
2012/02/13(月) 11:45:18.27それは間違ってないと思うけどな
Cとかperlの極めすぎた奴のコードとか読みにくすぎる
スキルの使う方向を間違えてる
設計はあくまで第三者を意識して書くものであるべき
コード行数なんて短くしてもなんの意味もない（読みにくいけど短いコードに意味があるなら教えて欲しい）
すべての行で速度面の最適化をするのも意味がない
多少遅くても読みやすさを重視するべきで、本当に速度が求められるようになったらしっかりとボトルネックを解析してそこを最適化していけばいい
ボトルネックの要因は特定のループ内の処理が大半という統計もでてる
0251デフォルトの名無しさん
2012/02/13(月) 11:56:49.34根本的な所でスキルの使い方間違えてるわな
周りの人間に簡潔に簡単に理解してもらうための手段であるべきなんだよね
身勝手なやつが現場入ってるとプロジェクトは燃えるし
他人の身勝手フォローするには
そいつを超えるスキルが必要なんだよね
0252デフォルトの名無しさん
2012/02/13(月) 12:03:46.030253デフォルトの名無しさん
2012/02/13(月) 12:07:01.62ビルゲイツは、プログラマの能力を知りたければ、
ソースコードを渡してすぐ読ませて、
理解度を確かめればいいみたいなこと言ってた。
0254250
2012/02/13(月) 12:17:08.61Scalaのような関数型言語の命令には意味もメリットもあるし、読みにくいのは単にその他の人が関数型言語を理解していないというだけだから
その言語の素直な実装なら文句はない
複雑なテクニックを意味もなく使うのは反対
Perlの無意味なワンライナー、Cの意味不明なマクロ、トリプルポインターなど
0255デフォルトの名無しさん
2012/02/13(月) 12:25:57.63いつからだっけ
0256デフォルトの名無しさん
2012/02/14(火) 01:08:12.41コードが仕様書。テストが仕様書。
自然言語で書かなきゃならない理由は実はない。
0257デフォルトの名無しさん
2012/02/14(火) 01:11:07.91プログラム書けない(書かないのでなく書けない)なんちゃって技術者が
自分の仕様書書きが仕事として意味が薄いもしくは無い
という事実から眼を背けるため
0258デフォルトの名無しさん
2012/02/14(火) 01:13:44.55アホか、YAGNIとデザパタは相反するものじゃない
0259デフォルトの名無しさん
2012/02/14(火) 01:16:19.39全然違う
0260デフォルトの名無しさん
2012/02/14(火) 01:22:54.630261デフォルトの名無しさん
2012/02/14(火) 05:51:41.120262デフォルトの名無しさん
2012/02/14(火) 06:01:30.52デザパタ特有の意味不明な接続クラスを説明できるならそれもいいけどね
大抵できる奴いないよ
デザパタだからとか繰り返すだけ
でもそんなのビジネスの場所じゃ通用しない
0263デフォルトの名無しさん
2012/02/14(火) 06:08:31.15「それは・・・・」
っていうのがデザパタの本来の使い方だよな。共通語としてのさ
逆に考えれば、そういうデザパタ使って粋がっちゃうやつを詰めるためにも使える
GoFもそういう風に皮肉っぽく発表すればよかったのにな
悪いデザイン集、みたいな感じでさ
0264デフォルトの名無しさん
2012/02/14(火) 06:12:26.27でも相手が知らないときに
「はぁ？知らないの？ださｗｗ」
って対応できないでしょ？
これができるのなんて匿名掲示板ぐらいじゃないの？
0265デフォルトの名無しさん
2012/02/14(火) 06:22:00.25相手はデザインパターン信者っていう過程でさ
「なんでここで余計なクラス使っちゃってんの？」
「これはアブストラクトファクトリーです」ってなるじゃん
それを
「なんでここでアブストラクトファクトリー使ってんの？」
って聞けば詰まるじゃん。そういうことよ
なんていうか忘れたけどさ、言葉自体には良し悪しの無いものを
さも言葉自体が良いものであるように使ってるのを詰めるんだよ
なんていうんだっけ
0266デフォルトの名無しさん
2012/02/14(火) 06:23:36.54それはそいつがデザパタの意図を理解せずに使っているというだけでデザパタ批判にはならない
接続クラスも言語仕様によるからデザパタ批判にはならない
接続クラスというのは、Javaの型継承でインターフェースを定義するためにわざわざ新たなファイルが作成されることが無駄ということだよね
動的型付け言語なら満足なの？
インターフェース（ファイルの有無は関係ない）の利点を理解できないなら、デザパタの前にオブジェクト指向設計の原則を勉強するべき
特に開放閉鎖原則と依存関係逆転の原則を理解した方が良い
近代のオブジェクト指向言語使っていてこれを理解してないのは、C言語で未だにGOTO乱用しているようなもの
せっかく便利になった点を活かしてないということになる
0267デフォルトの名無しさん
2012/02/14(火) 06:27:24.91無・良・みたいな言葉だった気がする
価値中立とは別の言葉があった気がする
0269デフォルトの名無しさん
2012/02/14(火) 06:40:18.340270デフォルトの名無しさん
2012/02/14(火) 06:46:57.01デザインパターンそのものを批判してるならまだしも
デザパタ利用者批判はスレ違い通り越して板違いだろ
続きをやりたいならマ板にスレたててそっちでやれよ
0271デフォルトの名無しさん
2012/02/14(火) 06:58:27.38なんでも分類排除すればいいってもんじゃない。
２ちゃんねるのように閑散とするだけだ。
0272デフォルトの名無しさん
2012/02/14(火) 07:00:14.59見事にレス追ってなかったわ
なんだろう
議論がよくわからないけど、詳細設計書通りに書かなければいけないというのなら、コーディング前に詳細設計書ができ上がっている体制そのものに反対
きっとその設計書は糞だから
詳細設計書に従う従わない以前の問題
詳細設計書がいらない
でも現実的には詳細設計書があるから、そこから勝手にデザパタのインターフェースが用意するのが許されるか許されないかという話かな
現場で上流と交渉しろw
このクラスの意味は？依存性強いけどいいの？と思い当たる問題点をつっこんでみる
ろくに説明できないだろうから、何を基準に設計してるんですか？ この設計は糞です。と延々と説明してみればいい
重要なのはここで対案を出すこと、批判だけなら誰でもできる
新しい設計を見せてメリットを説明する
理解できないなら勉強不足ですねと一言
最低限OOを理解できないのは、原始人がスマートフォンを見て鏡や金槌として使うようなもの
そして移動となる…
やっぱり体制が糞だ
0273デフォルトの名無しさん
2012/02/14(火) 07:04:57.03本当にコードと一対一対応してるなら
設計書を直接コンパイルすればいい
コンパイル出来ない言語（自然言語）で書く意味が無い
0274デフォルトの名無しさん
2012/02/14(火) 07:06:51.21ほんとその通りコンパイラないのに動くかどうかどうやって判断するんだよ
それとも詳細設計書は動かない前提で書いてるのか
0275デフォルトの名無しさん
2012/02/14(火) 11:00:17.06自分で好き勝手好きなものつくってるときだねぇ
0276デフォルトの名無しさん
2012/02/14(火) 13:25:38.18自分がやってる仕事が
他所ではコンパイラの仕事と言われた気分はどう？
0277デフォルトの名無しさん
2012/02/14(火) 19:53:28.50人間にとってはどうでもいい話だよ
使ってる道具で優劣は決まらん
0278デフォルトの名無しさん
2012/02/14(火) 20:50:31.49__ノ ｀ゝ
,． '"´ ￣￣￣ ｀`ヽヽ ﾆ三
,.ｲ ‐‐‐- ､ﾆﾆﾆ ,,,,__ ヾ:＼ フ ち
/:/,r─‐-､ -_-_- ﾆﾆミﾐヽヾ:::ヽ も く
.r＝=っ |::ﾚ'" ￣｀` ,r'ﾆﾆヽ u ';:::::', っ わ
ﾄ､ |. l:l r- ､ ﾞ, ,:'´ `ヽ! i::::::l て し
{::| | _ﾘ｀ﾐﾆヽ @)ﾉﾉ ,: .r @ ｀)ノ ｡ l::::::! ね か
{::l | ﾚ′ ￣｀ﾌ´ ｀ﾆ"´￣_ノ u !::::! ぇ
ﾚ′ r! ﾉ u ,,r ("´` ￣ l::/ ！
| /.:| j! ,,､､､､L _rｿノ⌒ヽ u ! ⌒ヽ
| ﾉ.:::L＿ ﾉj 彡'"´二ﾆﾆ'ｰミﾐヽ. u .! ﾉ ﾉﾉ
"´￣ __ﾉ ,′ﾉ >ｲ.-┴┴┴-ヽ ﾞﾐ;, ノ /_ノ/⌒7
,. -‐''"´ ) ￣｀` ,.{. （ { L.:.:.:.:.:.:.:.:.:.:..ﾉく;ハ ,:′ /_ ノ l/ V^V^V^
"´￣｀) 二ﾆ彡ﾄ､ ヽ､ ｀`""""´__ノ ﾉ ,:′ /￣｀`ヽ､ _ _＿_
‐''"´,.ｲ´ ヽl '"￣｀¨`ヽ ´ :′ /.:! ヽ:厂￣
／ / 入 , .イ.:/ !:l
／ / / 〈llllliiiiiiiiiー--‐''彡'"´ ,ﾚ′ リ
／ / ヾlllliiiir''"´ ,r'´ / lﾉ /.:,
イ / , ﾍﾉ / r─- ､」 .::/.:/
0279デフォルトの名無しさん
2012/02/14(火) 21:05:01.66オブジェクト指向でGoFのパタン一切使わないのは逆に難しくないか？
フレームワークの穴埋めでできてしまうシステムくらいしか思いつかん。
もしくは、よっぽど小さなプログラムか。
0280デフォルトの名無しさん
2012/02/14(火) 22:15:44.57なんだから、普通使うよな。
0281デフォルトの名無しさん
2012/02/15(水) 06:05:41.53そこでわざわざデザパタを適用する工程を入れる意味がわからない
0282デフォルトの名無しさん
2012/02/15(水) 06:08:41.59ここでは仕事の話は無しな
デザパタについて語ろうじゃないか。
・デザパタに含まれてない新しい概念
・デザパタの冗長性。23個もあって無駄な感じするじゃん
こういう観点からさ
0283デフォルトの名無しさん
2012/02/15(水) 06:11:08.36逆に難しそうだな
仕様書くんがまた同じ主張を開始したな
少し前のレスへの反論はできないみたいだからもういいや
0284デフォルトの名無しさん
2012/02/15(水) 06:12:07.76デザパタ自体の否定じゃなくて、重複した概念とかの排除な
デザパタ自体が使える使えないじゃなくてさ、プログラムの構造を記述する共通言語としてどうかってことを語ろうぜ
・全てのプログラムの構造を記述できるか
・一意に記述できるか
っていうさ
0285デフォルトの名無しさん
2012/02/15(水) 06:19:21.31GoF以外だとマルチスレッドのパターンとSingletonに似ているモノステートしか知らないや
冗長性という意味だとデザパタはほとんが何かしらと似てる
基本的にはポリモーフィズム、委譲、継承のテクニックであるtemplateパターンのどれかを組み合わせて、それに役割を与えたもの
Strategy,State,Commandなんてほぼ同じ
クラス生成系のパターンもほとんど同じ
Singletonは特殊
その似ていることは悪いことではなくて、提案としてはとても良いものだと思う
ただ学びやすくするために基本のパターンを定義して欲しかった
0286デフォルトの名無しさん
2012/02/15(水) 06:20:23.31洗練デザパタを書く -> コード自動生成
っていうのができたらいいんじゃないかなって
0287デフォルトの名無しさん
2012/02/15(水) 06:27:13.06よく使うとかいってるけど俺はつかわねぇよ
だってそんな余計なクラス挟む意味ないもの
0288デフォルトの名無しさん
2012/02/15(水) 06:28:54.32実用的なプログラミング言語って、ひとつのことをやるのに何パターンもあるんだよな
それが書きやすさにつながる
デザインする段階だと何パターンもあると逆にめんどくさいのかな
あと複数人で作業する場合は、一意性が逆に良いのかもしれない
0289デフォルトの名無しさん
2012/02/15(水) 06:32:11.43ある処理をするプログラムを書こうって思ったときに
誰が書いても同じにしか書けないプログラミング言語があったとしたら
もの凄い再利用性があると思うんだけど
プログラミング言語じゃなくても、デザインする上で一意に書ける何かがあったら喧嘩にならなくていいよな
0290デフォルトの名無しさん
2012/02/15(水) 06:33:19.40話をループさせるなよ
>>287
GoF以降もパターンはいろいろ出てるよ
0291デフォルトの名無しさん
2012/02/15(水) 08:07:21.12俺はコード自動生成には懐疑的
コーディングしながら設計するのが正しいと思ってる
実際にMDAもやってみたけどあれを習得する暇があったらコード書く
ツールに依存するところも大きくて細かい対応がしづらい
理想的にはいいのかもしれないけど、現実的には要件をすべてUMLなどを使って表現するのは逆に難しいと感じた
実際に普及する兆しはない
0292デフォルトの名無しさん
2012/02/15(水) 08:08:35.61仕様書くんに続く新キャラか
0293デフォルトの名無しさん
2012/02/15(水) 10:46:54.38やってることは同じポリモーフィズムでも概念的にはStrategyとCommandは全く別物だし、そっちで区別したほうが良いキガス。
0294デフォルトの名無しさん
2012/02/15(水) 12:44:52.81そうそう
概念としては違うから23パターンそれぞれ必要だと思う
ただクラス図たしての構成は似ているよと解説が欲しい
初めて学習したとき混乱した
0295デフォルトの名無しさん
2012/02/15(水) 13:53:47.55仕様 -> デザイン
ってやった場合にデザインは一意であるべき。なんでここでコーディングのことを考えないといけないのか
例えば、実行速度とのトレードオフとか
デザイン -> 実装
って全部実装側に押し込められるようなデザインパターン考えようぜ
一番単純な例だとソートだけど、マージソートとか踏み込みたくないじゃん
ソートよりももっと高度な概念もさ、"実装以外の部分"を綺麗に切り離して表現できればいいんだよな
0296デフォルトの名無しさん
2012/02/15(水) 13:54:43.89もっと他の概念が必要
0297デフォルトの名無しさん
2012/02/15(水) 13:56:18.28いや人が多くなってきたらさ、各人がコーディングする前の役割分担が必要じゃん
その役割分担をするときの共通言語みたいのが欲しいじゃん
0298デフォルトの名無しさん
2012/02/15(水) 14:19:34.00ある程度の抽象度でいいなら出来るだろうしやってるのもあるだろ。
ある意味YahooPipeとかもその一例。
けどどこまでを表現できるかで、やりすぎれば結局汎用言語とおなじになりそな気がす。
いろいろな場面に応じたDSL＋細かくしたい時は汎用言語でもかけてシームレスに繋げられるがいいとこな気がす。
0299デフォルトの名無しさん
2012/02/15(水) 14:23:35.070300デフォルトの名無しさん
2012/02/15(水) 16:27:09.25そんなものあったら仕事なくなっちゃうよ
0301デフォルトの名無しさん
2012/02/15(水) 17:19:09.94コードに要求される品質が仕様書に求められる事になって
トータルの生産性は変わらないんだよな
複雑にしすぎるほど小回りが利かなくなる
何度も書くコードの関数化
マクロ化なんてだれでもやってる事
0302デフォルトの名無しさん
2012/02/15(水) 17:43:21.71いずれ仕様書のコンパイラが開発されるなw
なんだかんだ歴史の中では段階を踏んで抽象化がされてきて、その間のを繋ぐものも存在してるんだよな
CPUと機械語の間にはADDA変換、機械語とアセンブリ言語の間にはアセンブラ、アセンブリ言語とプログラミング言語の間にはコンパイラ
プログラミング言語と要件定義所の間を繋ぐものは、自然言語という観点から他とは大きく違うけど
人間が自然言語から離れるのが一番簡単な解決策な気がしてきた
0303デフォルトの名無しさん
2012/02/15(水) 17:53:55.15その発想は何十年も前からあって、出てきたのがCOBOL
0304デフォルトの名無しさん
2012/02/15(水) 18:09:34.16ドラえもん「出来上がり」
客「何これ？こんなの要求した覚えないぞ？」
仕様さえあればＯＫなどと甘ったれていては答えは出ぬ。
0305デフォルトの名無しさん
2012/02/15(水) 18:13:01.19PG＝仕様書コンパイラ
お前たちはただのアプリケーションです
0306デフォルトの名無しさん
2012/02/15(水) 23:12:10.55よっぽど冗長で自由度が低くて手間がかかるずらーってのがよくあるオチだよね。
そもそも要件定義とプログラミングをつなぐものって、自動生成ツールとか
そういう方向じゃなくてパワポで作った紙芝居だとかスクリプト言語でちゃちゃっと
作ったプロトタイプだとかそういうもんだと思うよ。
0307デフォルトの名無しさん
2012/02/15(水) 23:21:36.92普通に作ったらデザインパターンのどれかを再現してるはず。
もちろんデザインパターンの存在を知らなくても。
つまりオブジェクト指向による設計とはデザインパターンの導入といえる。
デザインパターンを否定する人にはこう聞いてみればいい。
オブジェクト指向で設計したこと無いの？って。
オブジェクト指向言語を使ったからって、設計まで
オブジェクト指向になるわけじゃないので注意な。
0308デフォルトの名無しさん
2012/02/15(水) 23:24:43.46俺らみたいに詳しい人は、アルゴリズム勉強しろ！という
でも馬鹿は、アルゴリズムなんて不要なんていう。
アルゴリズムを導入しても難しくなるだけという。
俺らからすれば、コード書いていれば何かしらのアルゴリズム
使うわけで、不要とか意味不明なわけだが、その意味不明さもわかっていない。
こう例えればわかりやすいよね。
0309デフォルトの名無しさん
2012/02/16(木) 00:14:38.67> 仕様 -> デザイン
> ってやった場合にデザインは一意であるべき。
誰がやっても同じ結果しか産まないことになってる作業は単価が安いんだけどなw
0310デフォルトの名無しさん
2012/02/16(木) 06:32:56.00オブジェクト指向言語で、クラスを使っただけでオブジェクト指向設計の原則守れてない人多い
最悪の場合はデータ隠蔽すらしてない
オブジェクト指向言語で構造化プログラミングの時代と同じ物作れるからな
構造化プログラミングのC言語でもGOTO乱用して、非構造化プログラミングできるのと同じように
0311デフォルトの名無しさん
2012/02/16(木) 06:43:57.28まったく根拠のないものが多い
理詰めで考えるとちっともよくないとかむしろ手間が増えてるなんてものもある
そろそろ誰かがこの辺の見直しに入ってもいい頃だと思うがな
仮にさ
デザパタやオブジェクト指向を使って開発したなら
そうでない場合よりどのくらいの工数が削れるよ・・・って説明できる奴いんの？
0312デフォルトの名無しさん
2012/02/16(木) 06:55:26.50どれくらい工数削れるか説明してくれ
0313デフォルトの名無しさん
2012/02/16(木) 07:04:29.78>説明できる奴いんの？
俺は一般論ではない自分だけの話ならできる。
しかし人によって書き方も効率も違うからね。
工数という概念とプログラムの開発効率の間には個人差がある。
だから工数なんてものは経験的な目安に過ぎない。
0314デフォルトの名無しさん
2012/02/16(木) 08:31:05.71引数とか根拠のないものつかうより、グローバル変数使った方が手間が少ないじゃん
って言っているようなものだな。
0315デフォルトの名無しさん
2012/02/16(木) 08:53:11.310316デフォルトの名無しさん
2012/02/16(木) 11:29:02.56正直コマンドパターン使わないでUndo/Redo実装するとか想像つかんわ。
というか普通にこうするのが合理的だろってモデリング考えたら自然とオブジェクト指向になるよね？
自分は今はオブジェクト指向にと関数型のハイブリッドでやってるけど。
0317デフォルトの名無しさん
2012/02/16(木) 11:36:59.74責任があいまいになるでしょ
0318デフォルトの名無しさん
2012/02/16(木) 11:53:25.27ただ関数全部の最初の引数を同じ扱いにしましょってだけ
0319デフォルトの名無しさん
2012/02/16(木) 11:54:29.78単価を安くするんだよ。その分をツールを作る俺がもらうんだよ
0320デフォルトの名無しさん
2012/02/16(木) 13:02:12.11んー言わんとすることはわかるけどわからんでもないがちょっと違うと思うよ？
本来はアクター的な自立分散したものが協調して動くという意味も概念には入ってるだろうし。
まぁその辺はどこまでをどう定義に含めるかって話になるけれど。
0321デフォルトの名無しさん
2012/02/16(木) 13:14:25.20perl厨？self ishだなｗ
0322デフォルトの名無しさん
2012/02/16(木) 17:24:29.39作った後の保守メンテ
責任の所在をはっきりさせる考えだからな
組むだけだったり、一人で作るならオブジェクト指向にこだわる必要は無い
複数人で作るつもりならオブジェクト指向に慣れておけ
0323デフォルトの名無しさん
2012/02/16(木) 18:14:49.22単純な工数の削減というより、拡張時の安全性、効率性と保守性が主
あとは自分が作成したクラスを安心安全に他社に使って貰う仕組み
構造体だと好きに変更できちゃうけど、クラスならデータ隠蔽することにより危険な変更を制限できる
間違った使い方をしたら例外が投げられる
構造化プログラミングの時代はこの制限を仕様書に書いていたけど、オブジェクト指向の時代からは言語に組み込まれるようになった
0324デフォルトの名無しさん
2012/02/16(木) 18:16:21.05それはオブジェクト指向というよりクラスの概念
ポリモーフィズムはそれだけでは実現できない
0325デフォルトの名無しさん
2012/02/16(木) 18:16:49.630326デフォルトの名無しさん
2012/02/16(木) 18:21:50.05ごめん言い方が悪かった
構造体を使ってもオブジェクト指向のデータ隠蔽などは実現できる
構造体を否定したかったのではなく、構造化プログラミングの書き方では実現できないということ
0327デフォルトの名無しさん
2012/02/16(木) 18:33:12.33いくらでも多態できるだろ
実装者によってちぐはぐになるから
無理というならそうだけどさぁ
0328デフォルトの名無しさん
2012/02/16(木) 19:35:11.31oopと非oopを比較したいのか
ooplと非ooplを比較したいのか
はっきりしてくれ
0329デフォルトの名無しさん
2012/02/16(木) 19:35:50.040330デフォルトの名無しさん
2012/02/16(木) 19:42:09.90スレとしてはOOPと非OOP
今語られてるのは、OOPLだろうとなかろうと>>311からするとOOPは根拠がないことらしいから、それに対する反論でしょ
0331デフォルトの名無しさん
2012/02/16(木) 19:52:20.500332デフォルトの名無しさん
2012/02/16(木) 20:14:39.02お前さんが見過ごしてるだけで見直しは常に入ってるよ。
たとえばクラス設計でも大昔は継承使いまくって差分プログラミングしたり
複雑で自律したクラスこそが正しいOOだって言われたけど、今は真逆で
委譲やインターフェース使って責務の少ない単純なクラスを作るのがいいって
形になってるし、Javaのフレームワークなんかでも昔は超重量級のデザパタ
どっさりな出来だったけど、今はアノテーションやリフレクションを使って
オブジェクト指向的ではなくても簡単に組めるのが流行ってる。
言語の機能なんかでも関数型言語ライクにクロージャや型推論使って
手短に書けるのが最高って流れだろ。
0333デフォルトの名無しさん
2012/02/16(木) 21:32:19.920334デフォルトの名無しさん
2012/02/16(木) 22:15:46.24デザパタを始めるまでは、オブジェクト指向なんてどうせ本を売りたいために学者系の
エンジニア達が騒いでいる程度に考えていたぞ。
0335デフォルトの名無しさん
2012/02/17(金) 00:15:55.25A.Bってやつを定義したらそれを誰にでも、a.B、b.B、c.Bって使えるってのが本来の意味じゃね？
0336デフォルトの名無しさん
2012/02/17(金) 01:27:32.89使わなくて済むならそれに越したことは無い。使わざるを得ないから使うのであって。
0337デフォルトの名無しさん
2012/02/17(金) 01:32:33.89SVOCのOな。Sだと勘違いやつらが多い気がする
0338デフォルトの名無しさん
2012/02/17(金) 02:17:49.49バカすぐるならとりあえず黙っとけ
0339デフォルトの名無しさん
2012/02/17(金) 02:21:45.64閉鎖的すぎる。じゃあな
0340デフォルトの名無しさん
2012/02/17(金) 02:42:51.43説明できなかったけど今ならライブラリ(フレームワーク)を
例にしてこんな風に説明するな。
オブジェクト指向を使わない普通のライブラリだと
上からただ処理を呼び出して利用することしかできない。
でもオブジェクト指向で作ったライブラリだと呼び出し側から
ライブラリの中に自前の処理＋処理に紐付く属性を埋め込む
ことができる。このライブラリの中の処理の呼び出し側と
呼び出される側の関係の逆転こそがオブジェクト指向の
最大のメリットであり本質。
あと、クロージャを使ったりCで構造体+関数ポインタを使っても
同じことが出来るけど、オブジェクト指向言語ってのは
それ専用に構文を用意してて統一されたルールのもと
みんなが再利用し易いようにしてる。
0341デフォルトの名無しさん
2012/02/17(金) 02:54:52.40何馬鹿なことを聞いてるんだ？
まず、オブジェクト指向でちゃんと設計したら
それはデザインパターンになるんだよ。
デザインパターンを知らなくても普通に作ったらそうなる。
だって、そもそも「よく使われるパターン」なんだから。
工数が減るかどうかは、自分でパターンを考えて思いつく時間と
本に書いてあるパターンを参考にするのとどっちが早いかを考えれば
答えはわかるだろ。
アルゴリズムと一緒だよ。自分でクイックソートを思いつくのと
クイックソートの実装をパクるの。どっちが早いよ？
0342デフォルトの名無しさん
2012/02/17(金) 02:55:47.53そいつはオブジェクト思考の恩恵ではあるが本質からは微妙に外れている。
「ライブラリに使用者が振り回されている」という忌々しい過去からの脱却に過ぎない。
0343デフォルトの名無しさん
2012/02/17(金) 03:06:14.80デザインパターン云々ではなく、
単に技術力が低いから
工数かかってるだけ。
0344デフォルトの名無しさん
2012/02/17(金) 03:14:51.47新人や古臭いオッチャンに説明するときは、まずはじめに
メリット説明しないと理解してくれないって。
あと古臭いけど昔は勉強熱心だったオッチャンの場合だと
その説明に加えて、クラスはモジュール凝集度の
情報的凝集度を実現するためのものだって説明すると
ああそいうことだったのかって言って本質も理解してくれる。
0345デフォルトの名無しさん
2012/02/17(金) 03:33:46.45凝集度ってのは本質的な言葉だな。
ただどう凝集度を上げるかって具体的な事がわかっているかは別だが。
0346デフォルトの名無しさん
2012/02/17(金) 03:40:58.06簡単に騙せる
0347デフォルトの名無しさん
2012/02/17(金) 05:05:17.01こんなのを教えられる新人やおっちゃんがかわいそうだ
0348デフォルトの名無しさん
2012/02/17(金) 06:30:14.30お前等、その技術使ってどのくらい工数減らせるの？
現場で聞かれるのはいつもこんな声ばっかりなわけだが・・・
役に立つのかね？君らの技術って
0349デフォルトの名無しさん
2012/02/17(金) 06:38:58.98凝集度結合度の話なら、機能拡張しても既存モジュールに影響を与えない開放閉鎖原則と、実装への依存を避けられる依存関係逆転の原則を伝えるのが一番
企業の研修では昔ながらの関数レベルでの凝集度結合度の説明はするのに、オブジェクトレベルでの話が一切ないんだよな
0350デフォルトの名無しさん
2012/02/17(金) 06:45:43.75またループか
0351デフォルトの名無しさん
2012/02/17(金) 06:49:26.05上に色々書いてある
それらについてはどう思うの？
もし勉強不足で判断材料がないなら本を読んで勉強しろ
そもそもどうして自分は知らなくていいと思ってるのかがよくわからない
オブジェクト指向言語はこれだけ当たり前になっているんだから、とりあえず知るとこから始めないと判断できないでしょ
よくわからないから否定するっていうのはおかしい
0352デフォルトの名無しさん
2012/02/17(金) 07:09:49.75だってソフトが完成しないってまあ大抵ないじゃん
んで工数は多くとれたらとれた分だけ目一杯使うわけだから
したらはじめの見積もりの根拠がソフト開発のすべてといっていいよね
だったら既存のやり方から±いくらの根拠を持たせられるかが
ソフトウェア技術の価値のすべてだと思わない？（金を出す側からしたら）
どんなにすばらしい技術を使ってたって見積もりの時点で１ｈも工数が減らせないんじゃなんの価値もない
0353デフォルトの名無しさん
2012/02/17(金) 07:26:52.10どんなに素晴らしい見積もりをしても出来上がった物が
バグだらけじゃ意味ないって社長がお前に言ってますよｗ
0354デフォルトの名無しさん
2012/02/17(金) 08:12:54.92「仕様です」
0355デフォルトの名無しさん
2012/02/17(金) 08:27:20.00ソフトウェア開発が最初から最後まで1つもトラブルなく進むのなら、オブジェクト指向だろうがあまり関係ない
現在は、純粋な開発よりもデバッグやテスト、拡張など品質を保持することが多くの時間を割いている
オブジェクト指向はこれらの対応を容易にする
まずバグがある
オブジェクト指向ではスコープを限定して問題を限定的にして保守性を上げるための方法論がある
これによりデバッグ効率が上がる
更に要求の変更もある
これにより機能を拡張しなければいけないことが多い
このときオブジェクト指向では拡張を容易にする仕組みがある
でそれをどうやってオブジェクト指向で実現するのかがわからないと思うから勉強しろと言ってる
自転車を与えられても、乗り方がわからず自転車を手で押して歩いていたら重いだけで、速く移動できるというメリットがわからないのと同じ
オブジェクト指向言語を与えられても、使い方がわからず構造化プログラミングだけで書いていたら余計な機能が増えただけで、品質が上がるというメリットがわからない
乗りこなし方を勉強しろ
0356デフォルトの名無しさん
2012/02/17(金) 08:35:39.85実際に工数は減るよ。
例えば、開発全体の中でデザインパターンが適用できる部分がｎ％あるとする。
デザインパターンを参考に実装するのと
自分で考えて実装するのでは、参考にしたほうがｍ倍（1以上）早くなる。
つまり全体のｎ％の部分が1/ｍの時間ですむ。
ｎとｍは開発内容と技術力で変わってくるが、
工数が増えるってことはない。
0357デフォルトの名無しさん
2012/02/17(金) 08:55:46.33プロジェクトが大失敗する方法も存在すると思う。
特許庁の新型基幹システム開発失敗なんかもそうなんじゃないかと推測する。
ttp://sankei.jp.msn.com/politics/news/120124/plc12012417070013-n1.htm
新しい物や人材を取り入れず酷く保守化している企業に未来は無い。
古来から伝わる普遍の法則「栄枯盛衰」である。
俺は滅び行くものに対して>>355のようにたしなめようとは思わない。
0358デフォルトの名無しさん
2012/02/17(金) 08:59:50.10二度と来なくていいよ。お前にはまだ早すぎる。
0359デフォルトの名無しさん
2012/02/17(金) 12:51:35.88現実問題日本では滅びないどころか最大手だけどな
特許庁の件でTSOLは、疎結合にするためにコピペでコード書いていたらしいからな
しかもその反省点が「コピペしたコードの管理が甘かった 管理するためのシステムの導入が必要」だからなw
終わってる
0360デフォルトの名無しさん
2012/02/17(金) 13:30:20.270361デフォルトの名無しさん
2012/02/17(金) 14:17:10.66同じ議論のテーブルにのせちゃいけない
0362デフォルトの名無しさん
2012/02/17(金) 17:29:29.57これが日本の現実ですw
特許庁のシステムはコピペコード量産で 作ろうとしていた？ nnasakiのブログ http://nnasaki.hatenablog.com/touch/entry/2012/01/30/010629
0363デフォルトの名無しさん
2012/02/17(金) 17:52:49.79コピペコード以外書きようなくね
多少はフレームワーク拡張かけるけど
なにも言われなくても独立保守運営できるようにするのが常識だし
まともな客なら三層やMVC指定してこね？
0364デフォルトの名無しさん
2012/02/17(金) 18:18:04.87客というのが元請けならありえるが
0365デフォルトの名無しさん
2012/02/17(金) 19:25:26.89設計専門のSEは千人、設計資料は図表だけでも九万を超えてたみたいだから、変更があったら大変だっただろうね。
0366デフォルトの名無しさん
2012/02/17(金) 22:50:48.12全機能作ろうとしたの？
現場の人間のオツムがハムスター並に貧弱だったか、ボンクラを
現場に押しこむ才能に長けた超優秀な営業がいたかどっちかだな。
0367デフォルトの名無しさん
2012/02/17(金) 23:23:18.82んな余計な構造挟むぐらいならシンプルに仕様書の構造をまんまクラスに落とせよ
0368デフォルトの名無しさん
2012/02/17(金) 23:58:41.25最初の主張を繰り返すんじゃなくて反論に対する反論を書けよ
話が前に進まねーだろ
0369デフォルトの名無しさん
2012/02/18(土) 00:10:52.66俺んとこだと
3-1) ○○をアニメーション表示し、avi形式で保存できること。
3-2) アニメーション表示はコマ送り再生でき、刻み幅を指定できること。
みたいな調子なんだが。だから仕様書の構造をそのまんまクラスに、ってのがピンとこない。
0370デフォルトの名無しさん
2012/02/18(土) 00:16:12.94流れとしてはこんな感じみたい。
最後まで「業務要件確認書」は提出されなかったってあるから、ウォーターフォールで失敗するときによく見る例。
1. 60人体制で設計開始。遅延のため450人体制まで増強。完成した設計書は要件に一致しておらず品質もバラバラのため作り直し。
2. 新規に設計し直し。徐々に増強して1,300人体制へ。
出来上がった設計書を公開して、開発業者に入札を求めたが、品質不十分のためすべての業者が開発不可能と回答、入札延期。
4. 700人体制に一旦削減後、最終的に1,000人体制で設計したが、完成した設計書はまたも品質不十分で開発業者現れず、入札延期。
5. 第三者によって設計書の一部を調査した所、残件を2,600件発見。更に調査すると7,000件へと増加。
未だ要件確定しておらず、残件の全数把握は不可能と判断。
設計業者から修正に2年追加必要との回答があったが、その見積方法も確実性も不透明のためプロジェクト停止を決定。
「特許庁情報システムに関する調査委員会」からの調査報告書の提出について
http://www.meti.go.jp/press/20100820003/20100820003.html
特許庁情報システムに関する技術検証委員会
http://www.jpo.go.jp/cgi/link.cgi?url=/shiryou/toushin/kenkyukai/jyouhou_iinkai.htm
0371デフォルトの名無しさん
2012/02/18(土) 00:30:57.75それは仕様でも、要件定義とか外部設計じゃない？
たぶん >>367 の言ってるのは、その先の仕様(内部・詳細設計)じゃないかな？
>>370 みたいに上流(要件定義, 設計)と下流(開発=実装)が分かれてる場合だと、細かく設計してくれるのかも。うちも見たことない。
0372デフォルトの名無しさん
2012/02/18(土) 00:44:12.71プロマネに人月の神話をプレゼントしたい
0373デフォルトの名無しさん
2012/02/18(土) 01:29:36.89東芝ソリューションのどん臭い開発の進め方に担当者の心証最悪で
まとまる話もまとまらず無駄なドキュメントだけが量産される毎日。
６０Mステップで見積もり出してきて規模がなぜそんなに膨らむんだ
って突っ込んだら３０Mステップで出来るでできるけど設計書の修正に
２年かかりますよって舐めた回答に特許庁はブチギレ。
間に入ってる悪センチュアも結局東芝に責任押し付けて逃げ切りで
国民の血税はドブに捨てられました、チャンチャン。( ；∀；) ｲｲﾊﾅｼﾀﾞﾅｰ
0374デフォルトの名無しさん
2012/02/18(土) 01:54:27.940375デフォルトの名無しさん
2012/02/18(土) 02:28:24.62いや英語で書いてもおなじかもしれないが
というか、今や共通語たる C/C++ でドキュメント書いたほうが
0376デフォルトの名無しさん
2012/02/18(土) 04:46:12.500377デフォルトの名無しさん
2012/02/18(土) 05:40:36.68確信犯か故意犯かはわからないけど、仕様書くんは、繰り返し同じことしか言わないから相手にしないほうがいいな
とりあえずみんなにGoF本だけでなく、オブジェクト指向のこころを読んで欲しい
0378デフォルトの名無しさん
2012/02/18(土) 07:09:41.07オブジェクト指向だったら元はシミュレーション目的なんだから使い方は仕様書君のが正しいだろうな
デザパタのような中間クラスを挟むときはなんらかの説明は必要
0379デフォルトの名無しさん
2012/02/18(土) 07:14:11.49デザパタでのクラスの作り方は根本から違ってる気がする
現場の大半の人間はデザパタなど知らないし
通常は憂鬱本と同じ作り方をする
憂鬱本の作り方だとデザパタを入れるタイミングがまったく不明なのはたしかだな
0380デフォルトの名無しさん
2012/02/18(土) 07:35:46.50説明のできないクラスなんてデザインパターンに限らずあってはいけないだろ
0381デフォルトの名無しさん
2012/02/18(土) 14:16:24.97ドメインレベルのクラス設計をそのままコードに落としてたようなきがする
デザインパターンが出てくるのは実装レベルのクラス設計、混ぜるな危険な関係
0382デフォルトの名無しさん
2012/02/18(土) 14:43:25.36アンタも見たことないですかい。
見てみたいもんだね、コードに直に落とせるレベルの仕様ってものを。
大手の会社はそーいうのあるのかな。
0383デフォルトの名無しさん
2012/02/18(土) 15:21:53.46大手ではないけれど、現実の業務アプリの設計書/ソース一式が、
以下のリンク先で完全公開されている
・Ruby × TPJ｜高額合算システム（松江市様）
http://www.tpj.co.jp/ruby/case001_01.html
このページの設計書(specification.zip)に含まれる詳細設計書というPDFが、
その「コードに直に落とせるレベル」の仕様書の具体例になる
あと自分は大手メーカの業務アプリ開発に関わったことがあるけど、
そこでも上記リンク先と同じ「コードに直に落とせるレベル」の
詳細設計書を書いた、いや正確には、泣きながら書かされたw
0384デフォルトの名無しさん
2012/02/18(土) 15:25:57.62こういう手書き時代の処理設計書をそのまま引き継いだようなドキュメントを
Excel方眼紙上でチマチマ書いてる現場が日本にはまだ沢山存在するらしいぞ。
DBに変更が入るたびにExcel方眼紙上のカラム名を変更して回ったりと
賽の河原の石積みみたいな作業を何の疑問も感じず続けてるらしい。
お客さんにシステムを提案する前にお前らの開発を効率よくするシステムを
作ったほうがいいだろって思う。
http://www.asu.ac.jp/nkato/hd2/sys/gazo/zu2-6.gif
0385デフォルトの名無しさん
2012/02/18(土) 15:47:15.16だーかーらー設計とは別だっての。仕様書はデザインパターンを考慮しなくていい。
デザインパターンを考慮するのは設計書であって仕様書ではない。
0386デフォルトの名無しさん
2012/02/18(土) 16:00:58.83呼ばれて、開発者向けの資料を設計書だの内部設計書と呼ばれてるな
0387デフォルトの名無しさん
2012/02/18(土) 16:05:06.530388デフォルトの名無しさん
2012/02/18(土) 16:36:46.43だーかーらーwikiとWikipediaとは別だってのw
0389デフォルトの名無しさん
2012/02/18(土) 18:08:39.890390デフォルトの名無しさん
2012/02/18(土) 18:10:41.96オブジェクト指向が普及する以前でも、仕様書を元に設計を行って、
それからコーディングするのが基本だった事実をどう思ってるのか。
0391デフォルトの名無しさん
2012/02/18(土) 18:17:09.31以前でも、だと今もそうであるかのように誤解を産むな
0392デフォルトの名無しさん
2012/02/18(土) 18:20:40.64まぁ、フレームワークガチガチで設計しようのない案件は増えてるけどさ。
0393デフォルトの名無しさん
2012/02/18(土) 18:23:18.83ズレてるな
> 仕様書を元に
の部分だよ。みなまで言わなくても分かると思うんだが
0394デフォルトの名無しさん
2012/02/18(土) 18:29:16.23仕様書じゃなかったら何を元に設計するんだ？
0395デフォルトの名無しさん
2012/02/18(土) 18:29:48.95お手数かけてスマン！ありがとね！
高額合算システム詳細設計書_別紙３）プログラム仕様書.pdfを見ればいいのかな？
「コードに直に落とせる」気がまったくしないがｗ
>>384
自分もお役所と仕事はしたことがあるが、帳票や画面のレイアウト、
引っ張ったデータの計算方法は別表として随時ざっくばらんに貰ってたなあ。
全部をチマチマ書類にするとなると、それするほうが異常に大変＆文書バグ混入の恐れアリって感じだが。
0396デフォルトの名無しさん
2012/02/18(土) 18:30:59.44じゃあ仕様書は何を元に作ってきたんだよ
0397デフォルトの名無しさん
2012/02/18(土) 18:38:36.69いわゆる企画書とか要件定義書じゃね？
まぁちいさなものであれば、その辺曖昧ですぐに仕様書起こすこともあるけど、
0398デフォルトの名無しさん
2012/02/18(土) 18:39:26.92オブジェクト指向と絡める意味が分からんが、昔の世代が詳細設計を
しっかりやってたのはマシンがとろくさくてビルドに時間が
かかって実機上だと試行錯誤できなかったから紙上でしっかりやらざるを
得なかったんだろうな。あと今みたいにIDEのリファクタリング機能
とかないから手戻りもでかかった。
ついでに詳細過ぎる設計書を作らないでコーディングに入るってだけで
設計自体をしないってわけじゃないぞ。
0399デフォルトの名無しさん
2012/02/18(土) 18:44:59.300400デフォルトの名無しさん
2012/02/18(土) 18:46:29.37多少開発効率が落ちてもあった方がいいよ。
0401デフォルトの名無しさん
2012/02/18(土) 18:48:52.94シンタックスハイライトやらタグジャンプやらリファクタリング機能やら充実してるし
コード&コメントからドキュメントを自動生成できるし
自然言語で書かれた詳細設計書なんて不要すぎる
0402デフォルトの名無しさん
2012/02/18(土) 18:50:33.32贅沢を言えばemacsと言語のリファレンスがあればなおよい。
0403デフォルトの名無しさん
2012/02/18(土) 18:56:35.39詳細設計書が不要なのは、同意する
けど、コードをみればわかることばかりじゃないよね？
そういったコードに表れないことを書き記したドキュメントは、必要なんじゃね？
0404デフォルトの名無しさん
2012/02/18(土) 19:06:00.120405デフォルトの名無しさん
2012/02/18(土) 19:10:08.15それを、詳細設計書に書くのがいいのか？という点は議論の余地がある
0406405
2012/02/18(土) 19:11:08.710407デフォルトの名無しさん
2012/02/18(土) 19:19:19.82コードを書いて初めて気づいたり
コードを書いてる最中に発生したり
コードを書いたあとに発生したり
するのが殆どだ
しかし、コードを書く前に詳細設計書を書くよつなレガシーな開発スタイルでは、
詳細設計書を書く人間がコードを書かない(しばしば書けない)人間
とが異なるため(しばしば会社も違う)
詳細設計書に追記されることがない
0408デフォルトの名無しさん
2012/02/18(土) 19:33:48.91用意するってのは重要なのは誰でも分かる。
でもそれ作るのってコーディング前である必要はないよね。
開発中の開発者同士のコミュニケーションのための資料ならQA表に残すなり
プロジェクトのWikiや共有フォルダに画像やメモ書き置いとくだけで十分な気がする。
ただ全然違う場所で作業する別会社の人間に実装作業を依頼するときは
詳細設計書をしっかり作っとけよ。１００％自分が意図したものと
違うものが帰ってくるから。
0409デフォルトの名無しさん
2012/02/18(土) 20:05:24.58重大な勘違いをしている
0410デフォルトの名無しさん
2012/02/18(土) 20:13:25.82詳細設計書がヘボくても
書いた本人が現場で監督すれば１００％自分の意図したものになるのに。
0411デフォルトの名無しさん
2012/02/18(土) 20:23:10.40当然、意図したものと違った設計書が上がってきたら書き直し。
0412デフォルトの名無しさん
2012/02/18(土) 20:55:23.27何のために作るんだw
0413デフォルトの名無しさん
2012/02/18(土) 20:56:14.200414デフォルトの名無しさん
2012/02/18(土) 20:56:43.230415デフォルトの名無しさん
2012/02/18(土) 21:05:42.200416デフォルトの名無しさん
2012/02/18(土) 21:05:53.48普通それテストでやるよねー
0417デフォルトの名無しさん
2012/02/18(土) 21:59:37.74当たり前だが、ソースコードを書かないと動くものはできない
そのソースコードの設計というものが存在する。
これはプロジェクトを成功させたいなら絶対にやらないといけない作業。
このソースコードの設計というものは、大雑把な要求や開発や基本方針のみで設計するもの。
たとえばデスクトップアプリなのかウェブアプリなのかモバイルアプリなのか
サーバーは一台でやるのか、複数台使うのか、クラウド使うのか、
言語は何を使うのか、フレームワークは何を使うのか、珍しい機能、特徴的な機能は何か
これらの大雑把な開発方針からソースコードの設計を行う。
このソースコードの設計プロセスからできあがるものは、実際に動くスケルトンシステムだ。
動くものを作るのだから、ソースコードを書ける人がやるしかない。
作るシステムの機能は備えていないが、その機能を実装することが容易な設計。
そして開発プロセスまで含まれる。機能開発よりも先にそこまで作りあげてなきゃいけないんだよ。
ボタンを押したらどういう処理が行われるとか、そんなのはあとで考える事。
ありえないと思うかもしれないが、フレームワークはどうだ？ 先に作られているだろう？
このソースコードの設計を詳細設計とか言ったり、詳細設計に含めたりするからいけない。
コードを書けない素人にも出来る作業だと思われてしまうし、要求分析、設計の後でやるものだと思われてしまう。
俺は（システム）アーキテクチャとか言っているが、
もっと適切な、コードを書ける人にしかできない設計という名前をつけたほうがいいだろう。
0418デフォルトの名無しさん
2012/02/18(土) 22:08:06.130419デフォルトの名無しさん
2012/02/18(土) 22:09:12.28フレームワークが先に作られているのを、ありえない、なんて思う奴なんていないだろ
0420デフォルトの名無しさん
2012/02/18(土) 22:10:26.630421デフォルトの名無しさん
2012/02/18(土) 22:15:07.20あと。絶対やらなくてはいけない、なんてこともない
0422デフォルトの名無しさん
2012/02/18(土) 22:16:10.81なんか似たようなものを何回も作ったな、次も同じコード書くの面倒だし
じゃあまとめて次は楽してみよっかなノリで作られる。
0423デフォルトの名無しさん
2012/02/18(土) 22:16:20.37やっぱり作る必要ないよね、っていうソリューションもあるからだ
0424デフォルトの名無しさん
2012/02/18(土) 22:17:45.62そのわりに能動態じゃないんだなw
0425デフォルトの名無しさん
2012/02/18(土) 22:20:52.79俺が言ってる「ありえない」というのは、
詳細な機能が固まってないうちに
コードを書くということ。
もちろんこれは機能実装のコードではい。
0426デフォルトの名無しさん
2012/02/18(土) 22:24:01.64その意味でもありえなくはない
詳細な機能を決めるためにコード書くだろ
0427デフォルトの名無しさん
2012/02/18(土) 22:26:17.84失敗するところは、それをやってないんだよ。
使う言語とフレームワークを適当に選んで終わりとかな。
0428デフォルトの名無しさん
2012/02/18(土) 22:28:29.210429デフォルトの名無しさん
2012/02/18(土) 22:29:13.12一度リタイヤした怠け者が使い物になる程緩やかな変化の業種でもないし
0430デフォルトの名無しさん
2012/02/18(土) 22:31:18.95変化が早いと感じるのはまだまだ２流
さらにベテランになると、昔似たもの見たなって感じにしかならなくなる
0431デフォルトの名無しさん
2012/02/18(土) 22:32:52.97それどころか要件定義もしてたりする
設計だけエセは実はコードを書けない
必然的に設計が下手なまま
それどころか要件定義もおそまつ
これが過去数年間で明らかになったこと
0432デフォルトの名無しさん
2012/02/18(土) 22:34:05.47そう感じるんだとしたら成長してないってサインと捉えるんじゃないかな普通
0433デフォルトの名無しさん
2012/02/18(土) 22:35:22.29その設計の中でも、コアな部分が80で補助的なのが20。
コアな部分ってのは、メモリの大雑把な使用方針だったり、
整備しなきゃいけなくなるだろうフレームワークの方針だったり。
だから個人的には設計っていうといつも、トイレの中とか、
風呂とか自転車乗ってる時とかに、ぼんやり考えてるだけのことを指すと思ってる。
文章なんて書いたりしないし、図も描かない。
書いたとしてもチラシの裏にチョロチョロっと走り書きする程度。
設計ってそんなもんじゃね？
0434デフォルトの名無しさん
2012/02/18(土) 22:35:57.02人間が使える時間で頭に入れられるものなんて有限でたかが知れてるから
先人の足跡を辿るだけで精一杯になる時代がそう遠くないうちに来る
そこまで来たらもう大した進化はできない
0435デフォルトの名無しさん
2012/02/18(土) 22:38:31.16一面的にすぎる
メンテナンスが長いんだよ
0436デフォルトの名無しさん
2012/02/18(土) 22:42:13.93コーディングを2つに分ける。
一つはコア部分。一つは機能部分。
そして出来る限り多くものものを
機能部分から取り除いてコア部分に入れる。
コア部分は徹底的にリファクタリングする。
そうすれば、新しい機能を付け加えるときも
最小限のコードでいいし、コア部分は
長く多く使うから必然的に安定する。
これをしないで、はい、コーディングしてねってやると
コードは統一がとれくなりめちゃくちゃになり
無意味に量が増えバグも増え破綻する。
0437デフォルトの名無しさん
2012/02/18(土) 22:49:17.73共通部分を先に先行して作ったりするのはよくある話だけど
よっぽどセンスある人が作んないと開発の後半には
ダセー＆使いにくいの非難の嵐だぞ
0438デフォルトの名無しさん
2012/02/18(土) 22:50:22.34普通それで抽出されるものはライブラリになってるだろ
車輪の再発名は趣味ならともかく業務コードでやる奴は何もわかってない
0439デフォルトの名無しさん
2012/02/18(土) 22:51:19.47臭い部分を解体するためにリファクタ本読んで、
見通しが良くならない箇所を打開するヒントを求めてGoF本読んで、
柔軟さとは何ぞや、直交性とは何ぞやと迷いOOSCをナナメ読みしてみる。
これでもういいんじゃないか？ と思えるものが出来るまでは何度も何度も書き直す。
全部捨てて何度もスクラッチから書き直す。
人にもよるだろうな。俺は最初に時間かけてないと怖くて仕方ないから。
0440デフォルトの名無しさん
2012/02/18(土) 22:52:17.88として見るのがモダンな開発スタイル
0441デフォルトの名無しさん
2012/02/18(土) 22:53:27.840442デフォルトの名無しさん
2012/02/18(土) 22:55:11.940443デフォルトの名無しさん
2012/02/18(土) 22:58:56.94独自フレームワークだのアーキテクト気取りだのあったけど
今は廃れたよねってこと位は知ってた方がいいと思う
正面から叩くのは少し気が引けるけどスレタイ的にはね
0444デフォルトの名無しさん
2012/02/18(土) 23:00:31.45周辺部分のつじつま合わせは全部部下にやらせてしまいたいところだな。
0445デフォルトの名無しさん
2012/02/18(土) 23:04:36.17プログラマにとってその自己満足は何よりのご褒美。
プログラマ以外でそれを分かってくれるのは建築家とかだろうか。
0446デフォルトの名無しさん
2012/02/18(土) 23:06:32.11整然としてて
要件変更何でも来いって感じがたまらん
0447デフォルトの名無しさん
2012/02/18(土) 23:17:26.88コアの部分がカッチリしっかりしなやかに作られて無いと、もたない。
納期がジワジワ迫ってくるのに、コードがトッ散らかってる時の恐怖を一度味わうと潔癖症になる。
糞みたいな意味不明なクラスや、役割があやふやな糞ネーミングの糞クラスを量産して、
どんどん見通し悪くして、最適化入れにくく、変化にも弱い動脈硬化状態もよくあること。
若い頃は何度も何度も気が狂いそうになってた…。
0448デフォルトの名無しさん
2012/02/18(土) 23:53:59.72廃れたのは独自フレームワークであって、
最初に土台を作り上げるというのは廃れていない。
独自ではない有名所のフレームワーク使うという行為だって
最初に土台を（誰か他の人が）作ってるのと同じわけだし。
今は自分でフレームワークを作らなくて良くなった。
だからといって何もする必要がなくなったわけじゃなく
そのフレームワークの考え方、その考え方に合わせたコードの書き方、
フレームワークじゃないないときの拡張の仕方などに変わってる。
0449デフォルトの名無しさん
2012/02/18(土) 23:56:10.28× フレームワークじゃないないときの拡張の仕方などに変わってる。
○ フレームワークの機能だけじゃ足りないときの拡張の仕方などに変わってる。
0450デフォルトの名無しさん
2012/02/19(日) 00:06:33.21> 共通部分を先に先行して作ったりするのはよくある話だけど
> よっぽどセンスある人が作んないと開発の後半には
> ダセー＆使いにくいの非難の嵐だぞ
うん。それは分かってる。だから俺のモットーは変なモノを
作らないようする物を作るということ。矛盾しているようだけどねｗ
世の中にはすでに便利なものがたくさんある。だが実践ではそれをそのまま適用できるとは限らない。
だから作るべきもののおおまかな要求を元に、それを既存の便利なものが使えるように構成していく。
時間をかけて作ったものが、”普通なら”当たり前にできることだったりするから謎だよｗ
でも、要求が ”普通” じゃないんで当たり前にできない。それを当たり前にできるように持っていく。
意味わかんないと思うけど、具体的な内容は話せないからゴメンね。
俺がやってることと全く関係ないことで例えるなら、Railsでレールにのってない仕様のアプリを
レールに乗ることが出来るようにするものを作ってるということ。
0451デフォルトの名無しさん
2012/02/19(日) 00:16:20.51久々に読み返したけどオブジェクト指向の本の最高傑作だな＞憂鬱本
この通りに作ればなにも問題ない
余計なクラスを作りすぎてることにちと反省
0452デフォルトの名無しさん
2012/02/19(日) 00:16:58.390453デフォルトの名無しさん
2012/02/19(日) 11:15:46.52デザインパターンみたいな表層部分はできてるように見えても
デバック効率や想定開発環境が狭かったりしてうんこ
0454デフォルトの名無しさん
2012/02/19(日) 11:15:56.43いったい何が違うんでしょうか
0455デフォルトの名無しさん
2012/02/19(日) 11:28:58.51あほかｗ，
デバッグ効率や想定環境まで
考慮するのが一流のアーキテクトだろ。
0456デフォルトの名無しさん
2012/02/19(日) 11:31:11.120457デフォルトの名無しさん
2012/02/19(日) 11:47:18.51そんなの当たり前の話で、いちいち考えることじゃないでしょ。
0458デフォルトの名無しさん
2012/02/19(日) 12:22:48.73コピペ君にはよく会う
0459デフォルトの名無しさん
2012/02/19(日) 13:15:23.2994 名前: 仕様書無しさん Mail: 投稿日: 2012/02/13(月) 02:34:10.28
自分の知識自慢するために、やたら分かりづらい専門用語を並べて話す奴とかマジでやめて欲しい
そういうのをみてると、「お前、人とコミュニケーションする気あんのか！！」って思う
また、そういう人に限って薄っぺらい話しかできず、目的が見えないのが多い
95 名前: 仕様書無しさん Mail: sage 投稿日: 2012/02/13(月) 10:11:02.80
そういう人間に実装まかせようとすると何かと理由つけて逃げるんだよな
技術が伴っていない証拠
0460デフォルトの名無しさん
2012/02/19(日) 13:16:36.80いったい何が違うんでしょうか
0461デフォルトの名無しさん
2012/02/19(日) 13:18:14.32こういう具体的な質問には、パパッと答えが出てこないところが、
このスレのレベルを表してるな。
まあ、俺も似たようにモンだから、誰か答え書いてくれ。
0462デフォルトの名無しさん
2012/02/19(日) 14:09:20.10本の件はともかく
デザパタ知らない奴の方が珍しいわ
0463デフォルトの名無しさん
2012/02/19(日) 14:11:53.73技術的専門用語は、エンジニアにとっては
読み書きそろばん
出来て当たり前知ってて当たり前だろ。
バカに合わせる必要が常にあるわけじゃない。
少なくとも専門的な話題のスレでは特に
0464デフォルトの名無しさん
2012/02/19(日) 15:20:02.15シングルトンとか入ってるところとか他のパターンも大丈夫なの？
って思う
0465デフォルトの名無しさん
2012/02/19(日) 15:25:20.62パターンが悪いんじゃなくて、使う側の設計が悪い。
0466デフォルトの名無しさん
2012/02/19(日) 15:26:34.08ProxyとAdaptorの違いがわからんというレベルだと
あまりに話にならなくて答える木にならんのだろう
0467デフォルトの名無しさん
2012/02/19(日) 15:37:36.90それも含めてダメだってことだよね
0468デフォルトの名無しさん
2012/02/19(日) 15:38:52.64なぜ？ それが説明できないなら
お前には使えないってだけだよ。
0469デフォルトの名無しさん
2012/02/19(日) 15:39:06.46全く違うだろ
0470デフォルトの名無しさん
2012/02/19(日) 15:39:46.280471デフォルトの名無しさん
2012/02/19(日) 15:40:26.18>>470は>>467へのレスね。
0472デフォルトの名無しさん
2012/02/19(日) 15:41:10.70だって見る側が勘違いしちゃうんだよ？
少なくとも使用者はデザパタ本読んでそういう実装になったんだから
0473デフォルトの名無しさん
2012/02/19(日) 15:41:30.82みろ
デザパタ信者はアンカーもロクに使えない
0474デフォルトの名無しさん
2012/02/19(日) 15:42:32.420475デフォルトの名無しさん
2012/02/19(日) 15:43:00.000476デフォルトの名無しさん
2012/02/19(日) 15:46:44.60いったい何が違うんでしょうか
0477デフォルトの名無しさん
2012/02/19(日) 15:46:49.72代理に留まらず機能追加までするクラスに～Adapterって名称ついてること
結構みかけるんだが、ムズムズする
0478デフォルトの名無しさん
2012/02/19(日) 15:47:30.75上でレスついてたろ。本嫁
0479デフォルトの名無しさん
2012/02/19(日) 15:48:19.73AdapterじゃないProxyな
0480デフォルトの名無しさん
2012/02/19(日) 15:49:34.840481デフォルトの名無しさん
2012/02/19(日) 15:53:11.58なんでいきなり信者とか言っちゃってるの？ｗ
0482デフォルトの名無しさん
2012/02/19(日) 15:56:49.400483デフォルトの名無しさん
2012/02/19(日) 16:00:02.81Proxy インターフェースを変えたいのと同時に少し制限や拡張を加えたい時に使う
インターフェースとなるオブジェクトは機能を実装しているオブジェクトとは基本異なる
Handle-Body ただのコンパイル防壁、実装隠蔽手段
0484デフォルトの名無しさん
2012/02/19(日) 16:02:24.49Proxxはインターフェース変えちゃ駄目だろ
0485デフォルトの名無しさん
2012/02/19(日) 16:03:32.770486デフォルトの名無しさん
2012/02/19(日) 16:03:37.440487デフォルトの名無しさん
2012/02/19(日) 16:03:58.71そんな制限ないよ
0488デフォルトの名無しさん
2012/02/19(日) 16:04:56.87名前とやってることが違うのはいかがなものか
0489デフォルトの名無しさん
2012/02/19(日) 16:06:23.11呼び出し元が本体とProxyとどっち呼んでるか意識しないんだから
インターフェースが変わるわけないだろ
0490デフォルトの名無しさん
2012/02/19(日) 16:08:05.47そうそう。そこが肝だよな。呼び出し側から実装を意識させない。
代理なのか本体なのかをね。
0491デフォルトの名無しさん
2012/02/19(日) 16:10:23.92そういう場合はインターフェースが変わる
0492デフォルトの名無しさん
2012/02/19(日) 16:12:44.08それはProxyじゃないものを勘違いor無知ゆえにProxyと名付けた輩がいたってだけだろ
0493デフォルトの名無しさん
2012/02/19(日) 16:14:35.260494460=483
2012/02/19(日) 16:19:24.99レスの流れで少し理解が深まりました
やはり自演で適当なこと言って「間違いを指摘ししてどや顔したがる人を釣る」のが2chでの一番良い質問法だと確信しました
今後とも宜しくお願いします
0495デフォルトの名無しさん
2012/02/19(日) 16:20:20.380496デフォルトの名無しさん
2012/02/19(日) 16:21:20.22はやく死んだらいいのに
0497デフォルトの名無しさん
2012/02/19(日) 16:22:43.220498デフォルトの名無しさん
2012/02/19(日) 16:24:48.050499デフォルトの名無しさん
2012/02/19(日) 16:24:56.68コテつけてそれをやる輩がいて困る
0500デフォルトの名無しさん
2012/02/19(日) 16:25:28.66自分が「わかってない奴」だと発覚しそうになったときに
本当は「わかってた」ことにして沽券を保ちたい時に使います
0501デフォルトの名無しさん
2012/02/19(日) 16:25:59.090502デフォルトの名無しさん
2012/02/19(日) 16:31:21.29プロ串
凸冷田
0503デフォルトの名無しさん
2012/02/19(日) 16:33:07.01じゃなくて、オブジェクト設計
なのはどんな意図が込められてるんだ？
0504デフォルトの名無しさん
2012/02/19(日) 16:34:43.990505デフォルトの名無しさん
2012/02/19(日) 16:35:41.910506デフォルトの名無しさん
2012/02/19(日) 16:37:10.320507デフォルトの名無しさん
2012/02/19(日) 16:37:31.180508デフォルトの名無しさん
2012/02/19(日) 16:37:41.56うーん、どーなんだろう
0509デフォルトの名無しさん
2012/02/19(日) 16:38:50.57おまえもデザパタに親を殺されたのか
0510デフォルトの名無しさん
2012/02/19(日) 16:55:35.100511デフォルトの名無しさん
2012/02/19(日) 16:59:12.23呼ばれてたヤツか。
あんなもん腐ったC++の仕様に合わせた小手先のテクなのに混同した理由が分からん。
0512デフォルトの名無しさん
2012/02/19(日) 17:17:53.59クラスベースじゃないオブジェクト指向言語だって
あるのだから何の問題もない。
クラスを使わなくともオブジェクト指向設計は出来る。
0513デフォルトの名無しさん
2012/02/19(日) 17:21:23.57そーいう意図でそーしてるんなら全く問題ないけど
実際はクラスベースな話ばっかりしてるような
0514デフォルトの名無しさん
2012/02/19(日) 17:27:06.38へー。単にpimplのことだったのか。ググるのすらめんどいから放置してたｗ
0515デフォルトの名無しさん
2012/02/19(日) 17:38:19.960516デフォルトの名無しさん
2012/02/19(日) 17:49:54.320517デフォルトの名無しさん
2012/02/19(日) 17:50:17.16なんでクラス名に～Observerって名前じゃなく～Listenerって名前つけるんだ？
あるいは、なんでリスナーパターンって呼ばないんだ？
0518デフォルトの名無しさん
2012/02/19(日) 17:52:21.100519デフォルトの名無しさん
2012/02/19(日) 18:02:00.160520デフォルトの名無しさん
2012/02/19(日) 18:04:44.330521デフォルトの名無しさん
2012/02/19(日) 18:06:56.010522デフォルトの名無しさん
2012/02/19(日) 18:13:00.79監視されるほうからみたら監視者にメッセージを送るってのは
ちょっとおかしいから、監視されるほうが利用するインターフェースの
名前にはListenerって付けたんじゃないかな。
0523デフォルトの名無しさん
2012/02/19(日) 20:09:31.19実際、この命名してるフレームワークもあった。
いまはもう息してないけど。
0524デフォルトの名無しさん
2012/02/19(日) 20:21:23.530525デフォルトの名無しさん
2012/02/19(日) 20:24:05.84デザパタは必要ないってこと。
やっぱり不要なものだな。
0526デフォルトの名無しさん
2012/02/19(日) 20:27:06.480527デフォルトの名無しさん
2012/02/20(月) 08:24:09.590528デフォルトの名無しさん
2012/02/20(月) 09:21:41.720529デフォルトの名無しさん
2012/02/20(月) 18:54:29.450530デフォルトの名無しさん
2012/02/20(月) 23:48:49.46デザパタなんて使ってる現場なんてねぇってのに
ＮＥＣでもＮＴＴでも三菱でも富士通でも富士電機でもコニミノでもキャノンでも
シャープでも松下でも沖電気でもコマツでも使ってないのに一体どこで
使われてんでしょうかねぇ？ｗ
0531デフォルトの名無しさん
2012/02/20(月) 23:50:07.680532デフォルトの名無しさん
2012/02/20(月) 23:53:50.320533デフォルトの名無しさん
2012/02/20(月) 23:55:52.70その技術でお前いくつ工数削れたよ？
これだけは頭に入れとけ
0534デフォルトの名無しさん
2012/02/21(火) 00:00:48.030535デフォルトの名無しさん
2012/02/21(火) 00:01:54.58本当に何も分かってないんだな
0536デフォルトの名無しさん
2012/02/21(火) 00:03:57.21その中の４つに派遣されたことあるけど、
全部デザパタつかってたよ。
(使ってない部署もあったけど)
0537デフォルトの名無しさん
2012/02/21(火) 00:15:52.64若者に恥かかされて
2chでネガキャンしてるんだ
察してやれよ
0538デフォルトの名無しさん
2012/02/21(火) 00:48:52.37ソースってのはそれを削る事を意識して書くもんだ
0539デフォルトの名無しさん
2012/02/21(火) 00:55:57.96設計書の条件を満たしているのはソースコードだけ
というのは知ってた方がいいかもね
0540デフォルトの名無しさん
2012/02/21(火) 08:57:50.84読みやすいソースがアレば他は何もいらないよな
0541デフォルトの名無しさん
2012/02/21(火) 09:11:04.72ユニットテスト無しならテスト工数は確実に増えるぞ
0542デフォルトの名無しさん
2012/02/21(火) 09:57:34.25自分は読みやすいソースでも主要なクラスの全体的な絡み方、主要な流れについてのしょぼいインタラクティブ図ぐらいはほしい。
それがあるとないとでは全体感の把握の速度がぜんぜん違う。
0543デフォルトの名無しさん
2012/02/21(火) 17:42:52.29この中のどれかの人間だが使ってるぞ
0544デフォルトの名無しさん
2012/02/21(火) 17:55:39.180545デフォルトの名無しさん
2012/02/21(火) 20:29:48.71一枚っぺら位のクラス図なんかで、アーキテクチャ説明あると（・∀・）ｲｲ！
0546デフォルトの名無しさん
2012/02/21(火) 22:34:24.64それは正しくない。
ソースコードは詳細設計書
プログラミングは設計
コーディングは入力
コンパイルは製造
おｋ？
0547デフォルトの名無しさん
2012/02/21(火) 22:39:43.96意味が解からん。そもそも設計書は、入力と出力(GUIの振る舞いや通信もI/Oに含める)、
データ構造を定義したもんだ。プログラム内部がどうなってるかは、設計書には入らん。
ソースコードじゃどの結果が正しいかは表現しないから設計書にはならん。
まぁ、テストケースである程度設計を補助することはできるけどな。
0548デフォルトの名無しさん
2012/02/21(火) 22:43:38.93それは、インターフェース設計というかもしれないが
ここで一般的な意味の設計ではないな。
たとえばテレビのインターフェースとして
HDMI入力、出力、RCA端子とか、その内部データを定義したとしても
それを、「テレビの設計書」とは言わんだろう？
テレビの設計書とは、それを見て材料さえ手に入れば
他の人でも同じものが作れるようなレベルのものだよ。
0549デフォルトの名無しさん
2012/02/21(火) 22:44:02.00定義だって事を知らんヤツは学生だろ。少なくとも入札で受注したような
システム開発の経験は無いんじゃね。
0550デフォルトの名無しさん
2012/02/21(火) 22:45:15.46お前は素人だ。
0551デフォルトの名無しさん
2012/02/21(火) 22:48:27.38ソフトウェア設計だと別だろ。生産物に当てはめりゃいいってもんじゃ無い。
日本のソフト開発じゃ「共通フレーム２００７」とか要求されてる設計書が設計書の定義だ。
0552デフォルトの名無しさん
2012/02/21(火) 22:52:37.42お前の会社が間違っているか、お前の日本を間違って認識
しているかのどちらかだ
共通フレーム
http://www.atmarkit.co.jp/aig/04biz/slcpjcf.html
用語の説明に設計という単語すら出てこないものを
設計とよぶな。
0553デフォルトの名無しさん
2012/02/21(火) 22:54:05.65設計書というよりは、仕様書と言ったほうが正確だったかもな。
客に約束した入出力結果を定義した文章。
そして、開発チームがコーディングにより目指すべき入出力結果を
書いてある文章。(定義は客に約束した内容と同じ)
携帯電話や、テレビの仕様書と客に約束している分似てはいる。
0554デフォルトの名無しさん
2012/02/21(火) 22:59:21.35そこら辺の馬の骨をソースにするとか素人かよ。
IPAが発行する「｢共通フレーム2007 第2版」の開発プロセスの章を引用して反論しろよ。
0555デフォルトの名無しさん
2012/02/21(火) 23:01:41.29そもそも共通フレームって何する際に求められるかしってる？
0556デフォルトの名無しさん
2012/02/21(火) 23:10:43.22感じでTVの回路図だってIn-Outのお約束の組み合わせでできてるよね
オッサン臭い話になるけどIn-Outベースの設計のキホンの感覚が
掴めてないのにデザパタだとか実装の小手先ばっかり
目が行くのはどうかと思うよ
0557デフォルトの名無しさん
2012/02/21(火) 23:11:14.96W3CがだしてるHTML Specificationとか、AdobeのPDF Specificationとか、
まともな人間が書けばどっこも似たようなもんだ。
0558デフォルトの名無しさん
2012/02/21(火) 23:13:41.79別に小手先の話をするのはいいんじゃね
問題は、小手先と設計を混同した上人を馬鹿にしてる点なわけで
0559デフォルトの名無しさん
2012/02/22(水) 00:08:40.20それは仕様。
0560デフォルトの名無しさん
2012/02/22(水) 00:16:43.26本来の設計をせずに作業をしてしまって大変なことになってるのも
よくみる(本人は難しい仕事をやってると満足してるんだが)。
0561デフォルトの名無しさん
2012/02/22(水) 00:26:49.67車のパーツの位置がおかしかったら、
設計がおかしいと言うだろ。
0562デフォルトの名無しさん
2012/02/22(水) 00:46:57.60中学レベルの日本語読解力さえあれば
＞仕様書を書くこと自体は設計だ。
＞仕様書を書くこと自体は設計だ。
＞仕様書を書くこと自体は設計だ。
この部分見ただけで，なーんかおかしいーなーって違和感を感じとれるものだけどなあ
0563デフォルトの名無しさん
2012/02/22(水) 00:51:30.0320世紀の化石くんが2010年代に生きる人間に混じりに来るのは、
スレのテンプレで踏み絵を用意しないのが悪いのかもな
放置するとスレのレベルが下がるぞ
0564デフォルトの名無しさん
2012/02/22(水) 00:53:48.620565デフォルトの名無しさん
2012/02/22(水) 00:55:27.95これから作るものに必要とされる機能や性能などを検討し、どのような構成で作るのかを仕様として決定すること。
ほとんどの場合、決定した事項は設計書や仕様書などの文書にまとめられる。
要件定義：
システムやソフトウェアの開発において、どのような機能が要求されいて、
実装されるべきなのかを明確にしていく作業のこと。開発者側と依頼者側の双方の協力により定義が行われ、
その成果は「要件定義書」としてまとめられる。開発を始める前に行う作業であるが、最も重要なプロセスのひとつである。
設計：
これから作るものに必要とされる機能や性能などを検討し、どのような構成で作るのかを仕様として決定すること。
ほとんどの場合、決定した事項は設計書や仕様書などの文書にまとめられる。
0566デフォルトの名無しさん
2012/02/22(水) 00:56:18.23ソフトウェアや情報システムの開発工程の一つで、利用者に提供する機能や操作感などを定義する工程。
方法論の違いにより、外部設計に当たる工程を「基本設計」あるいは「概要設計」と呼んだり、
これらの一部に外部設計を含めたりする場合もある。
内部設計：
ソフトウェアや情報システムの開発工程の一つで、全体の構成や行うべき処理の詳細など実装に必要な仕様を定義する工程。
方法論の違いにより、内部設計に当たる工程を「詳細設計」と呼ぶ場合もある。
詳細設計：
ソフトウェアや情報システムの開発工程の一つで、全体の構成や行うべき処理の詳細など実装に必要な仕様を定義する工程。
方法論の違いにより、詳細設計に当たる工程を「内部設計」と呼ぶ場合もある。
0567デフォルトの名無しさん
2012/02/22(水) 00:56:49.190568565
2012/02/22(水) 00:59:42.920569デフォルトの名無しさん
2012/02/22(水) 01:00:23.47ちゃんと書いてあんじゃん
0570デフォルトの名無しさん
2012/02/22(水) 01:01:41.98～や
～場合もある
アホのエース降臨だな
0571デフォルトの名無しさん
2012/02/22(水) 01:04:09.960572デフォルトの名無しさん
2012/02/22(水) 01:09:28.72しばらくするとそれにも飽きて過疎る運命
楽しかった。みんなありがとな
0573デフォルトの名無しさん
2012/02/22(水) 01:10:54.90現実問題境界は曖昧で、要求事項寄りが仕様書、
画面デザインや、動作寄りなのが設計書と呼ばれる。
客寄りか、製作者寄りかで便宜的に別れてるだけで、
要求と結果に対する定義という点じゃ変わりゃしない。
試験仕様書とか書いたことがあれば、このへんが
曖昧なのはよく解るだろう。
0574アホエース
2012/02/22(水) 01:11:20.88ttp://e-words.jp/
からの転載でした。省いてコピペしたんで、原文は上記サイトで見てくんろ。
0575デフォルトの名無しさん
2012/02/22(水) 01:13:00.39どうでもいいけど、ホントにマの仕事したこと無いの？
0576デフォルトの名無しさん
2012/02/22(水) 01:17:02.75そこに有益生を見出さない奴は何しに来てるんだ？
興味ない者は存在がスレチなんだから、わがわざ鼻つまみ者になりに来るんじゃなく、別のスレ立てたらいかがか？
0577デフォルトの名無しさん
2012/02/22(水) 01:18:52.25要求と結果に対する定義さえ決めればいいと思ってるんなら、
設計をやったこと無いんだろうな。
0578デフォルトの名無しさん
2012/02/22(水) 01:21:01.20デザパタスレ、オブジェクト志向スレ、設計手法スレ
って三つ巴だもんな
0579デフォルトの名無しさん
2012/02/22(水) 01:24:28.98少なくともコードデザインを設計書や仕様書に書いたことはないな。
プログラマー同士の打ち合わせにUML出してデザインを決めたりするけど設計書とは呼ばないし。
0580デフォルトの名無しさん
2012/02/22(水) 01:26:46.11そもそも設計を否定してるわけじゃないだけどね
設計書や仕様書にデザパタが上がるってのがおかしい訳で
0581580
2012/02/22(水) 01:28:08.35×そもそも設計を否定してるわけじゃないだけどね
○そもそもコード設計を否定してるわけじゃないだけどね
0582デフォルトの名無しさん
2012/02/22(水) 01:29:12.08もう混沌としてるじゃん。俺はそういうの好きなんだけどさ
0583デフォルトの名無しさん
2012/02/22(水) 01:29:47.44？
0584デフォルトの名無しさん
2012/02/22(水) 01:36:04.53コード設計は担当者の頭の中にあるだけで、どこにも残さない主義か。
正直、迷惑だからやめてほしい。
0585デフォルトの名無しさん
2012/02/22(水) 01:41:05.64では聞こう。具体的に何を書いて欲しいんだ？
0586デフォルトの名無しさん
2012/02/22(水) 01:49:27.23UMLは書くつってんじゃん。
あと、Javaであればjavadocとか残す。
ただ、これらを設計書や仕様書には含めん。
プロジェクトファイルの一部にメモとして入れてたりするぐらい。
0587デフォルトの名無しさん
2012/02/22(水) 01:55:51.27いわゆるスケッチだね
チーム文化維持しながら人員が緩やかに変化する場合は一番効率いいよね
0588デフォルトの名無しさん
2012/02/22(水) 02:01:30.72そのコードがどのような構造になっていて、
どういった意図を持って存在するのかがわかるような設計資料だな。
後から構造を解読する時間がもったいないんでね。
お前だってせっかく綺麗に設計したプログラムが、他の担当者に
ぐちゃぐちゃにされて戻ってくるのは嫌だろ？
0589デフォルトの名無しさん
2012/02/22(水) 02:05:19.39設計した内容を設計書に記述しない理由がわからない。
何か不都合があるのか？
0590デフォルトの名無しさん
2012/02/22(水) 02:13:34.63586じゃないけど横から。
コード読めば分かることなら、蛇足でしかない。書く時間が丸っと無駄。
コード読んでわからなくても、聞いた方が早いことなら、書く時間が勿体ない。
書き残さなきゃならないことは、実はそれ程多くない。
たとえば、何を書いて欲しいんだ？
0591デフォルトの名無しさん
2012/02/22(水) 02:18:49.19なるほど、その観点なら同意見だな。
引き継ぎ前に、数枚程度に収まるアーキテクチャ説明書を残すよ。
どちらかっていうと、相手の理解が楽になるように。
綺麗な設計がグチャグチャにされるのを防ぐには、どっちかてと設計そのもので防ぐ派かな。あり得てドキュメンテーションコメント。
それはドキュメントじゃ無理とまで言わないけど不向きだと思ってる。
0592デフォルトの名無しさん
2012/02/22(水) 02:19:25.56>>589にも書いたけど、コード読んでもわからないことを書け。
> 聞いた方が早いことなら、書く時間が勿体ない。
周りから質問攻めにあって忙しいそうにしてる奴を見たことあるが、
(おれもそういう状況に置かれることはままあるが)
「あんたがちゃんとしたドキュメント書いてないからだよ」
としか思えなかった。
0593デフォルトの名無しさん
2012/02/22(水) 02:23:31.15リングキューをグルグル回してるけどどういう契機で何のために
使ってるんだよとかパッと見分かんねえし。
あとスレッドまわりも分かりにくいからちゃんと文章での解説付きの
シーケンス図を残してくれ。
0594デフォルトの名無しさん
2012/02/22(水) 02:24:24.65では、自分も横レス
>コード読んでわからなくても、聞いた方が早いことなら、書く時間が勿体ない。
これが正しいのは、聞く相手が不揮発性記憶の達人で、かつ常に隣にいるという
前提がある場合に限られると思われ
なお>>590中の単語「コード」をすべてコメント(注釈)に置き換えたなら同意
0595デフォルトの名無しさん
2012/02/22(水) 02:27:15.10そこは、そのプロジェクトのマネージメント文化で結構変わると思う。
個人的には、チームが大事にしてることとか、直にコミュニケーション取って伝えた方が、チーム文化は維持し易いと思ってる。
チームビルドはしばしば辛抱強い時間が必要なことなのに、壊すのはあっと言う間だから。
良いプロジェクトほど、文化伝承にきちんと時間を割く傾向があると思ってる。
それに、予めきっちり残しておかなくても、その場で相手の理解度に応じて書いて伝わることは多い。
目的はあくまでチーム全体の最適化だから、必要にならないドキュメントを書くデメリットは軽視出来ないと思う。
コードの意図とか、その場でクラス図書きながら伝える方法で問題が出るようなら、
そこが複雑になりすぎてるサインとも言える。
0596デフォルトの名無しさん
2012/02/22(水) 02:29:34.73ホワイトボードに書いた絵を携帯カメラでパチリ
0597デフォルトの名無しさん
2012/02/22(水) 02:30:25.68コミュニケーションとれない場合は仕方ないから、力入れて残すよ。もちろん。
0598デフォルトの名無しさん
2012/02/22(水) 02:34:45.93コミュニケーションがとれる場合でも、
書き手本人が不揮発性記憶の達人でなければ同じ事
書き捨てプログラミングであれば無問題だけどね
0599デフォルトの名無しさん
2012/02/22(水) 02:36:20.29コードの細部はいくらでも忘れても、
設計意図はめったやたら忘れないだろ
0600デフォルトの名無しさん
2012/02/22(水) 02:44:59.55保守のことを忘れていないか？
0601デフォルトの名無しさん
2012/02/22(水) 02:47:10.30その疑問は、作り逃げ、みたいなスタイルのとき？
0602デフォルトの名無しさん
2012/02/22(水) 02:51:55.20そうでもない。
忘れるというより、一回聞いただけで全て理解できるわけじゃないというのが正しいが。
無理やりデザパタの話につなげると、名前を言えばお互いに同じパターンを思い描ける
というのは、理解の助け(省力化)になっているのは間違いない。
0603デフォルトの名無しさん
2012/02/22(水) 02:56:06.56メンバーの交代はあるだろ
その時、設計の内容は出て行ったメンバーの頭の中にしか残らない
0604デフォルトの名無しさん
2012/02/22(水) 03:01:45.53それがリスクになるためには、前提があるよね。
・重要な設計理念が、コードやアーキテクチャからは、読み取れないようなコードベースになっている。
・重要な設計が、単一の人間の頭の中にしかない。つまり多重化を一切行っていない。属人化といって差し支えない状況。
・引き継ぎしない
たぶん、先に改善した方がいいことが他にあるような。。。
0605デフォルトの名無しさん
2012/02/22(水) 03:01:52.00もちろん作り逃げみたいなスタイルも含まれる
でもそれ以外だって、いつまでも保守「だけ」を続けるわけないよな？
保守フェーズに入れば、次の別のプロジェクトが立ち上がる
0606デフォルトの名無しさん
2012/02/22(水) 03:08:14.55うん。プロジェクトにより匙加減やカスタマイズは当然必要。
どんなプロジェクトに対しても単一の手法で臨める、なんてわけはないから。
0607デフォルトの名無しさん
2012/02/22(水) 03:24:36.34>たぶん、先に改善した方がいいことが他にあるような。。。
そういったリスク回避策の中で、スレの主旨に沿い、かつ
最も重要で基本的な改善が、設計書であると自分は思うけどな
0608デフォルトの名無しさん
2012/02/22(水) 03:42:46.62オブジェクト指向で整然としたコードなら把握しやくどこに何があるか予想もつく。
デザパタのような共通の知識の力を借りれば設計そのものが自らその意図を語ってくれる。
0609デフォルトの名無しさん
2012/02/22(水) 03:44:44.50縦割りで自分の担当以外知りません！みたいな事にならないと思う
0610デフォルトの名無しさん
2012/02/22(水) 05:03:03.44> オブジェクト指向で整然としたコードなら把握しやくどこに何があるか予想もつく。
> デザパタのような共通の知識の力を借りれば設計そのものが自らその意図を語ってくれる。
そんな甘い考えは捨てたほうがいい。
どちらも「使ってないよりはマシ」な程度の効果しかない。
0611デフォルトの名無しさん
2012/02/22(水) 05:31:14.22自分は>>607だけど、オブジェクト指向やデザパタには、
マシ程度どころかソフトウェア設計にとってとても大切な概念だと思っている
ただし、「コードがあれば設計書は不要」とか「コードが仕様である」といった
考えを批判しているだけ
オブジェクト指向やデザパタは大切だからこそ、
その意図をキチンと設計書という文書で残すことが重要と考える
ということで、そろそろスレ主旨に沿った議論に戻る事をキボン
0612デフォルトの名無しさん
2012/02/22(水) 07:23:57.611.「共通フレーム2007」などで定められる納品に必要な設計書で無くなるから
2.UMLだの作ってるのは、俺の勝手で客の要求事項では無いから
3.コード設計は、設計書の内容と違いウチの一実装であって、
今後保守する業者に押し付けられる訳ではないため、
契約上の強制力がある設計書には含められないから。
0613デフォルトの名無しさん
2012/02/22(水) 08:20:55.74内部設計書には、何を書けばいいんだろうか
クラス単位のjavadocみたいなAPIマニュアルが必須なのもわかるが、これは設計前に必要なものではなく実装完了後に必要なもの、実装として複雑な部分をソースにコメントを記述するのもわかる
あとはクラス間のやりとりの説明として簡易化したクラス図やシーケンス図もあったら便利か
これが内部設計書に書くもの？
設計書というからには、コード書く前に必要なものだと思うんだけどあまり思い浮かばないな
0614デフォルトの名無しさん
2012/02/22(水) 10:01:11.33顧客とのやり取りを決めたフレームワークを持ち出して
「うちの開発では顧客に出さないものは設計書として残しません」
ってのは変だと思わないのか？
> 2.UMLだの作ってるのは、俺の勝手で客の要求事項では無いから
当然です。
請負でもない自社製ソフトを作る場合や自社サービスを立ち上げる
場合には設計書を書かなくてすむね♪
0615デフォルトの名無しさん
2012/02/22(水) 10:08:20.76一人で設計するなら内部設計書なくて「設計は俺の頭の中にある」でいいと思うけど、
複数人で設計する場合は随時設計書として残していかないとすぐに破綻すると思う。
0616デフォルトの名無しさん
2012/02/22(水) 10:12:28.83俺的にはコードに適度な粒度でコメントは書け。
ソース上ではどうしても複数の要素間の前提、作用などは書きづらいので仕組み的なものについては別に書け。
ある程度聞かれる可能性のあることは書け。
って感じかね。どこまでってのはあるがざっくりある程度としか言えん。
自分は自分のためにソース上ではざっとみて内容がわかるレベルのコメント、クラス図と相互作用図を合わせたようなポンチ絵、その裏にある思想を書いてる。
0617615
2012/02/22(水) 10:17:39.140618デフォルトの名無しさん
2012/02/22(水) 13:43:59.91内部設計書に何を書くのかをまず教えてよ
0619デフォルトの名無しさん
2012/02/22(水) 15:27:50.52「そのままコードに落とせる」ってやつの予感。
見たことないんでワクテカ。
0620デフォルトの名無しさん
2012/02/22(水) 15:35:36.62横レスだけど、もし一人で設計する(=個人のプログラミング)であるなら、
>>616が>>613へのそのものズバリな答えになっているんじゃないのかな
自分は>>613をそのまま賛同するけど、これに何か不足な点があるのかな？
0621デフォルトの名無しさん
2012/02/22(水) 15:36:56.80X: 自分は>>613をそのまま賛同するけど、
O: 自分は>>616をそのまま賛同するけど、
0622デフォルトの名無しさん
2012/02/23(木) 22:43:50.74デザパタ無用になるというのは自明の答えではあったが、どうも>>302の言った
>いずれ仕様書のコンパイラが開発されるなw
が相当現実に近づいているようだ。このスレもまだまだ２～３年は惰性で続くだろうが、
ゆっくりと収束に向かうのだろうね。
0623デフォルトの名無しさん
2012/02/23(木) 22:45:43.20横からだが、内部設計書に何を書くのか俺も興味あります…。
0624デフォルトの名無しさん
2012/02/23(木) 23:44:25.33付きまとうけど、上位の仕様書で足りないなと思った情報を残業しない
程度に好きに書けばいいと思うよ。
ER図やテーブル定義書、ファイルや通信の仕様がなければ書けばいいし
チームで進捗を把握しつつ分担して作業を進めるにはある程度意味を持って
モジュール分けしてそれぞれがどういうモジュールなのか説明する資料も
欲しいよねとか見えてくるだろ。
デザインパターンを使って素晴らしいライブラリを作ったと思うなら
コーディング標準として縛って必ず使いやがれとチームのメンバーに
強制させるムカつくドキュメントを書いてもいい。
0625デフォルトの名無しさん
2012/02/24(金) 00:48:06.50自明なわけないな。考えなしさが良く伝わってくる。
0626デフォルトの名無しさん
2012/02/24(金) 00:52:20.24もうこの板学生しか居なくなったの？
ISerと仕事したときとかに、使用言語やら依存ライブラリ
要求事項ごとの動作、エラーコードなどのコード類を
まとめた文書を作らされるでしょ。詳細設計書って名前で。
0627デフォルトの名無しさん
2012/02/24(金) 00:54:10.470628デフォルトの名無しさん
2012/02/24(金) 00:56:50.780629デフォルトの名無しさん
2012/02/24(金) 00:58:18.030630デフォルトの名無しさん
2012/02/24(金) 01:02:07.65SIから要求されるじゃんXer○xとかIB○とか。
自社製品作るときは別だけどさ。
0631デフォルトの名無しさん
2012/02/24(金) 01:02:26.340632デフォルトの名無しさん
2012/02/24(金) 01:05:34.22基本設計書と詳細設計書を書かされるらしいな
詳細設計書はソース書き換えるたびに書かないといけないらしい
聞いた話
0633デフォルトの名無しさん
2012/02/24(金) 01:05:40.08さっき上げたところと目立は詳細設計書で納品してる。
0634デフォルトの名無しさん
2012/02/24(金) 01:09:34.61コメントで残すとかw
ねーよ
0635デフォルトの名無しさん
2012/02/24(金) 01:11:05.73普通はsvnみたいのやるの？
0636デフォルトの名無しさん
2012/02/24(金) 01:11:18.65そりゃねぇ。
基本フローが変わったり、エラーコードが増えたり、
吐き出すメッセージが変わったり、外部に影響のある
変更したらその都度直すよ。そうしないと、バグか意図してるのか
解んないからね。絶対基準は設計書でソースは付随物でしかないから。
0637636
2012/02/24(金) 01:12:39.50リリースノートとかはあるけど。
0638デフォルトの名無しさん
2012/02/24(金) 01:14:26.595年単位でシステム変えるから5年単位で仕事が来る
でも変更点はちょびっとっていうおいしい仕事らしい
0639デフォルトの名無しさん
2012/02/24(金) 01:22:31.17・自分の仕事の内容を約束し確定させるため
・仕様が実現可能かどうか検証するため
・実装工数見積の根拠を示すため
・開発者のコミュニケーションのため
・後工程のテストや保守のため
・なんか上から要求されてるからなんとなく書いてる
とか色々ありそうだけど目的が違うならそもそも話合わなそう。
0640デフォルトの名無しさん
2012/02/24(金) 01:28:40.40・開発者のコミュニケーションのため
・後工程のテストや保守のため
・納品物だから
こんな所かな。エラーコードとか、
細かいメッセージとか、雑多な仕様ってのは
基本設計書に乗らない。そういうもんが
詳細設計書に行く。
0641デフォルトの名無しさん
2012/02/24(金) 01:29:40.10・プロジェクト規模を水増しし金を多くぶんどるため
0642デフォルトの名無しさん
2012/02/24(金) 01:31:14.230643デフォルトの名無しさん
2012/02/24(金) 01:32:28.13あんまり名前の響きほどエンジニアリングなもんじゃない
0644デフォルトの名無しさん
2012/02/24(金) 01:33:15.30仕事始めたあとに契約書を書くの？
0645デフォルトの名無しさん
2012/02/24(金) 01:33:31.21どんな感じに？
0646デフォルトの名無しさん
2012/02/24(金) 01:33:32.520647デフォルトの名無しさん
2012/02/24(金) 01:34:28.48修正範囲が広がる
手書きドキュメントはコンパイラの自動検出の恩恵を受けられない
0648デフォルトの名無しさん
2012/02/24(金) 01:39:43.43それは関係ないんじゃない。
コンパイラがあろうがなかろうが仕様
間違いの自動検出なんてできないもの。
あと設計書がなかったらどう直すべきかも解らないよね。
例えば、10桁まで表示できる事って設計書に書いてたら、
10桁にするしか無いじゃない。設計書がない状態で
何桁にするかどう合意を取っていくの？
0649デフォルトの名無しさん
2012/02/24(金) 01:44:52.95その内部設計書だか詳細設計書だかは、上の方で、
客に見せない開発者だけが読むドキュメント
とかいってなかったか？
あの定義だと、その内部設計書だか詳細設計書だかに書いても合意はとれないよねf^_^;)
0650デフォルトの名無しさん
2012/02/24(金) 01:48:31.61言ってないでしょ。
0651デフォルトの名無しさん
2012/02/24(金) 01:49:35.63どのレスの事言ってる？
0652デフォルトの名無しさん
2012/02/24(金) 01:49:35.67> 例えば、10桁まで表示できる事って設計書に書いてたら、
> 10桁にするしか無いじゃない。設計書がない状態で
> 何桁にするかどう合意を取っていくの？
仕様書？ 仕様書に桁数が書かれていなければ任意。
0653デフォルトの名無しさん
2012/02/24(金) 01:50:44.40いや関係あるだろ
仮にその10桁という情報ひとつとっても
プログラムなら設定ファイルか定数クラスに一箇所書くだけ。修正も一箇所。
設計書はどうやって一箇所にするんだ？別ファイルの特定ページの(特定シートの？)ドキュメントを指すように書くの？
現実的に無理っしょ
0654デフォルトの名無しさん
2012/02/24(金) 01:51:55.47印刷しないところはそれで済むかもね。
てか、その対応で許される現場があるんだね。
0655デフォルトの名無しさん
2012/02/24(金) 01:52:02.80それに、プログラムと設計書が、
完全に同期してることを保証する仕組みもないよね
0656デフォルトの名無しさん
2012/02/24(金) 01:53:45.69世界は広いんだよ^^
>>655
> それに、プログラムと設計書が、
> 完全に同期してることを保証する仕組みもないよね
なんか話は変わるが、コメント不要論を思い出したｗ
コメントも古かったりウソ書いたりを防げないしなー。
0657デフォルトの名無しさん
2012/02/24(金) 01:53:47.25そういう話じゃないんだけど。
コンパイラが10桁か15桁かどっちが
正しい仕様か判断できるかってとこが問題だから。
0658デフォルトの名無しさん
2012/02/24(金) 01:54:25.11>>386とか>>408とか？
0659デフォルトの名無しさん
2012/02/24(金) 01:55:53.61同期してないってどういうこと？
設計書に反するなら、それは全てバグだよ。
お客さんや責任者が認めてるのは設計書の内容であって
ソースコードじゃないんだから。
0660デフォルトの名無しさん
2012/02/24(金) 01:58:01.46アホっぽい意見だな
客に価値をもたらすのはドキュメントじゃないよ
0661デフォルトの名無しさん
2012/02/24(金) 02:00:12.92話ずれてるぞ
0662デフォルトの名無しさん
2012/02/24(金) 02:01:49.53そういう会社も有るのかもね。
ウチは、取引先に提出したり上長に提出したりしてるから、
そういう環境の事情はしらない。少なくとも、大手SIやら、
システム部門のある企業から請求される設計書を基準に話してるつもり。
0663デフォルトの名無しさん
2012/02/24(金) 02:05:22.04それには、「あ、そう」としか言えないわ。
それはともかく、設計書と動作が違ったら庇護担保保証で問題になるでしょ。
>>661
ズレてるというか、設計書の視点が違うんだよ。
0664デフォルトの名無しさん
2012/02/24(金) 02:09:11.29多重管理してるのに、同期とる仕組みを持ってないという自覚がないのか
・プログラムだけ直って、ドキュメントが古い
・ドキュメント直したけど、プログラムが古い
時差の問題もあるよね
緊急リリースだ！とかいってソースだけ直された日には何を見たら正かも定まらない
修正コストが増える点ではメンテナンス性は明らかに下がってるよ
0665デフォルトの名無しさん
2012/02/24(金) 02:10:03.81あっそう、とか、それはともかく
とか嘘ぶくのやめたら？それが一番大事でしょーに
どんなアマチュアだよ
0666デフォルトの名無しさん
2012/02/24(金) 02:13:49.30じゃそっちの視点に合わせて答えればいいかな。
文字として直す作業は増えるそれは正しい。
ドキュメント内で整合性が取れないだろうという
事については、そこまで値が散ることはないし、
一番正しい値は表とか一箇所にしか書いてないから
どれが間違ってるかはすぐ解る。
最近はフィールド(散らばった文字でも同期を取れる機能)が
使えるおかげでますます、間違え難くはなってる。
0667デフォルトの名無しさん
2012/02/24(金) 02:15:54.13↓
>>651 どのレスの事言ってる？
↓
>>658 >>386とか>>408とか？
↓
>>662 ウチは、取引先に提出したりしてる
えっ？ 内部仕様書を相手に渡してるのか？
何のための内部・外部の区別なんだろう？と不思議に思う。
0668デフォルトの名無しさん
2012/02/24(金) 02:18:04.28バグフィックスじゃなくて、ドキュメント直さず仕様修正が入るの？
そんな事になったことがないわ。住む世界が違うんだろうね何も言えないなぁ。
0669デフォルトの名無しさん
2012/02/24(金) 02:19:27.25内部外部は組織の意味じゃないけど。
普段どんなお客さん相手にしてるの？
ゲーム屋さん？個人客？
0670デフォルトの名無しさん
2012/02/24(金) 02:24:58.70バグフィックスで「ある」んなら、それ以外でも「ある」だろ
運用始めたら要件のバグが発覚
仕様のバグが発覚
合意のとられた内容に基づいているため実装のバグではない
しかし、実装を変更せず放置し続ける間じゅう顧客に不利益が生じ続ける
0671デフォルトの名無しさん
2012/02/24(金) 02:25:26.78いや、価値をもたらすとかそういう話はしてなかったからさ、
受け答えのしようがないじゃん。
0672デフォルトの名無しさん
2012/02/24(金) 02:27:33.33バグフィックスは設計書に合わせるんだから
設計書の必要ないでしょ。って意味で書いた。
仕様のミスだったら設計書直して、レビューして
確認とってから実装に入るよ。
0673デフォルトの名無しさん
2012/02/24(金) 02:29:15.611.
データベーススレじゃないから気になるんだけど
桁数ってそもそも設計なのか？
2.
内部設計書だか詳細設計書だかを、顧客がみる、とするなら
そのドキュメントには当然、顧客が理解出来ないよーなことは書かないんだろう
設計はいつやるんだ？
0674デフォルトの名無しさん
2012/02/24(金) 02:31:56.57ひょっとしてUIや帳票レイアウトの部分が外部？
では、相手に渡す 内部 とは？
0675デフォルトの名無しさん
2012/02/24(金) 02:35:31.71桁数はお客さんと話して決めて設計書に書くよ。
帳票出力で何文字まで印刷できるかは非常に重要。
表示できなきゃいけない名前が切れてるとか、
金額が途切れてるとかなったら大問題だし。
質問するのはいいんだけどさ。
君はどういう現場で働いてんの？
発言の根拠が全然伝わってこないよ。
0676デフォルトの名無しさん
2012/02/24(金) 02:37:31.070677デフォルトの名無しさん
2012/02/24(金) 02:38:24.76いらん書類を積み上げて仕事した感になるのは、
この業界の一部だけのことじゃないぞｗ
0678デフォルトの名無しさん
2012/02/24(金) 02:38:51.59なくても困らないなら、なくていいんじゃない
開発ターゲットも様々なんだし、一概に要不要を語れないと思うんだけど
0679デフォルトの名無しさん
2012/02/24(金) 02:40:16.43そういう、何文字まで、みたいなのって結局試してみるまでわからないよね
その場ですぐ修正するヨーな現場だよ
必要なら即リリースも安全に出来る。もちらん次回リリースに載せても問題ない。
要件がレフポンス良く反映されることを、喜んでもらえてますよ
0680デフォルトの名無しさん
2012/02/24(金) 02:41:15.72内部外部じゃなく、基本設計、詳細設計なんだけどね。
基本設計は、エンドユーザーや管理者に影響する仕様。
何度も書くけど、詳細設計は処理フローやエラーコードとか雑多な仕様。
お客さんのシステム部門が目を通す内容だよ。
0681デフォルトの名無しさん
2012/02/24(金) 02:44:58.76ああ、内部つっても、処理の流れとかエラーコードとかか。
それなら基本設計側にめりこんでるふうにすら感じる。
内部っつうから、まさかとは思うが、クラスライブラリのAPIとかつけてんのかと。
んなこたないわけね。
0682デフォルトの名無しさん
2012/02/24(金) 02:45:27.91揚げ足とるわけじゃないけど
エラーコードなるものがあるとしたら、それは管理者に影響するでわ
0683デフォルトの名無しさん
2012/02/24(金) 02:46:07.540684デフォルトの名無しさん
2012/02/24(金) 02:46:22.080685デフォルトの名無しさん
2012/02/24(金) 02:50:01.21ありがとう。あと客層を教えて欲しいんだけど。
特につか掛かってるつもりじゃないんだけど、
そういうお客さんってどういう所なのか純粋に気になる。
>>682
まぁ、基本と詳細の境界付近は曖昧だからねぇ。
0686デフォルトの名無しさん
2012/02/24(金) 02:50:22.84このスレはスレタイと中身が違い杉
おまえらエンジニアとして落第点だな
0687デフォルトの名無しさん
2012/02/24(金) 02:51:27.11リファクタリングが設計書に影響しちゃ如何だろ
仕様や振る舞いを変えずに内部構造を変えるのがリファクタリングでしょ
0688デフォルトの名無しさん
2012/02/24(金) 02:54:15.39Webでもの売ったりしてる会社
新商品扱ったりキャンペーン打ったりデザイン変えたりで
仕様変更が通常のフローみたいな
結構よくある開発だと個人的には思ってる
小まめのリリースとデカ目のリリースとで、やることは適宜変える感じで
0689デフォルトの名無しさん
2012/02/24(金) 02:59:59.63社外に公開してるWeb屋さんについては
さっぱり解からんわ。なるほどね。
0690デフォルトの名無しさん
2012/02/24(金) 03:08:01.10誰もお前がそれを分かるかどうかなんて興味ないですよ？
0691デフォルトの名無しさん
2012/02/24(金) 03:17:22.02しかしこのスレの内容が意味ないとは全く思わないが
ム板ってよりマ板なレスが多いようだな
次スレ立つ前には、
スレ分けするなり旨く誘導なりしないと
今のままだとワケワカメだ
0692デフォルトの名無しさん
2012/02/24(金) 03:33:11.50では、スレ誘導ということで、マ板の該当スレを紹介
・仕様書、設計書について
http://kohada.2ch.net/test/read.cgi/prog/1322274416/
・設計書を作ってるせいで生産性落ちてないか？
http://kohada.2ch.net/test/read.cgi/prog/1169735232/
0693デフォルトの名無しさん
2012/02/24(金) 06:15:20.40自分が気に入らない話題になるとすぐに追い出そうとするのは悪い癖だぜ
そもそも書かれた仕様書に対してどのようにしてソースを組み立てるか？は
できた物より大事なこと
まったく同じソースでもそれが出来た過程によって糞にも宝石にも評価はかわる
それがわかってない奴は設計なんて語るレベルにないと思う
0694デフォルトの名無しさん
2012/02/24(金) 07:20:15.63スレ分けた所で根本的な解決にはならないよ
普段設計書書かないヤツがコード設計と設計書を混同する
↓
普段詳細設計書を書いてるヤツが設計書の定義を書き始める
↓
なぜか話が平行線に伸びる
0695デフォルトの名無しさん
2012/02/24(金) 07:43:10.73エラーコードとかを書くのは設計書なのか？
内部設計書=APIドキュメントのこと？
0696デフォルトの名無しさん
2012/02/24(金) 07:49:23.59要件定義書に書かれているものではないの？
パスワードは6文字以上とか
これって客の要求な気がするんだけど、基本設計以降で開発者が勝手に決めて良いことではないよね
0697デフォルトの名無しさん
2012/02/24(金) 08:55:13.22冷静に眺めていたら気が付いたんだが、
内部設計を詳細設計と呼ぶ例があるというのと、
その人が詳細設計について語っているのと、同時に考えちゃいけないのかもしれない。
その人は、内部設計ではなく詳細設計だけについて語っているようにも見える。
つまり、その人に内部設計について聞いても、その人にとっての詳細設計の返事が返ってきてる可能性あり。
>>696
俺もまったく同意。用件定義書、あるいは仕様。あるいは仕様の別表。
0698デフォルトの名無しさん
2012/02/24(金) 11:01:49.94＞プログラムなら設定ファイルか定数クラスに一箇所書くだけ。修正も一箇所。
そんなふうに思ってた時期が自分にもありました・・・
0699デフォルトの名無しさん
2012/02/24(金) 11:03:03.690700デフォルトの名無しさん
2012/02/24(金) 11:20:50.46> 緊急リリースだ！とかいってソースだけ直された日には何を見たら正かも定まらない
その緊急リリースに問題がありそうだということが発覚した場合、
ドキュメントがないと、さらに何が正なのかもわからない。
0701デフォルトの名無しさん
2012/02/24(金) 11:21:40.410702デフォルトの名無しさん
2012/02/24(金) 11:31:37.590703デフォルトの名無しさん
2012/02/24(金) 12:55:07.290704デフォルトの名無しさん
2012/02/24(金) 12:55:53.240705デフォルトの名無しさん
2012/02/24(金) 15:23:24.18コードこそが客が本当に欲しがっている価値があるもので
資料はあくまで資料でしか無いのだよ。
0706デフォルトの名無しさん
2012/02/24(金) 16:33:37.58オブジェクト指向とデザパタの話しろお前ら。
おれは関数型に移行したのでだいぶどうでもいいが。
0707デフォルトの名無しさん
2012/02/24(金) 16:35:14.180708デフォルトの名無しさん
2012/02/24(金) 17:00:21.240709デフォルトの名無しさん
2012/02/24(金) 19:28:03.49ハードウェアを作る時のような慎重さは求められてないかも。
少人数でイケたりもするしね。設計書が果たす効果が小さいね。
設計書を大人数の輪の中心に置いて、橋とかビルとか作るのとはまた違うよね。
0710デフォルトの名無しさん
2012/02/24(金) 19:42:30.70プログラマが書いているソースコード
それが設計書そのもの。
0711デフォルトの名無しさん
2012/02/24(金) 19:47:57.57おーっ。ひさびさにスッとふに落ちる意見じゃないか。なるほどな。
0712デフォルトの名無しさん
2012/02/24(金) 22:28:02.170713デフォルトの名無しさん
2012/02/24(金) 23:06:55.16ＭＳがワードかエクセルかVisioあたりもごちゃまぜにして
仕様書も設計書も含めたＶＳを作ってくれるといいんだけどな
仕様書に書いて部分をダブルクリックすると関連する設計書やソースコードが青く光る！
みたいな統合具合だったら仕様書ももっとやる気でると思う
0714デフォルトの名無しさん
2012/02/25(土) 03:09:37.950715デフォルトの名無しさん
2012/02/25(土) 03:25:53.880716デフォルトの名無しさん
2012/02/25(土) 07:03:23.63自分が好きな話したいなら自分で話題ふれよ
文句だけ言ってるようじゃなにやってもダメ
0717デフォルトの名無しさん
2012/02/25(土) 10:34:42.76そういう事はルールを守ってから言え(´・ω・｀)
0718デフォルトの名無しさん
2012/02/25(土) 13:03:56.09お前がでてけ
>>692がお前の巣だ
0719デフォルトの名無しさん
2012/02/25(土) 18:00:15.61今度は自治議論になって余計荒れるだけ
結局は話の流れを変えるしかない
0720デフォルトの名無しさん
2012/02/25(土) 18:46:52.04自由にやりたい事をやればいい。
俺も自由にやる。命令しても無駄ｗ
0721デフォルトの名無しさん
2012/02/25(土) 19:09:19.39機能を追加するときはどうすんのが一番いいのかな
インターフェースを差し替え？それともインターフェースを変えずに機能追加する方法があるの？
0722デフォルトの名無しさん
2012/02/25(土) 19:39:59.98それが問題になるなら、別の方法を取ればいいだけ。
0723デフォルトの名無しさん
2012/02/25(土) 23:26:33.75二年ほど前になんかの展博に行ったときに、CATS がその手のツールを出してたような気がする。
詳しくは聞かなかったから、実際どこまでできるかはよく知らんが。
0724デフォルトの名無しさん
2012/03/06(火) 21:32:34.85仕様書はI/O動作の定義書いてるだけだからどうあがいても無理だろ。
ソースデザインはUML連動ツールで我慢しなさい。
0725デフォルトの名無しさん
2012/03/06(火) 23:00:00.68単に仕様書の文をクリックしたら該当部分のソースコードに飛んでくれるだけの機能でいいんだけどね
0726デフォルトの名無しさん
2012/03/06(火) 23:26:23.99以下は、Smalltalkを題材にした書籍の一部
・オブジェクト指向を支援する道具
http://aokilab.kyoto-su.ac.jp/documents/IntroductionToOOAOOD/chapter5/index-j.html
あと業務システム開発で主流のCOBOL系だと、リポジトリと呼ばれる
設計データベースを中核にした統合CASEツールが昔から使われている
たとえばSADS(富士通)やSEWB(日立)など
今時なら、Javaでそんな製品があるのかもしれない(自分は知らない)
それからRuby限定だけど、ソースから詳細設計書を自動生成し、
その時に設計書とソースとの間のリンクも生成してくれるツールがある
・TmDoc - Rubyソフトウェアの保守ドキュメントを作成
http://www.h6.dion.ne.jp/~machan/tmdoc/index-ja.html
0727デフォルトの名無しさん
2012/03/07(水) 01:26:02.35でもそれって仕様とコードの対応付けできないよね。
ソースと仕様を対応付けたいなら、まず仕様と対応するのは
テストコードだから、仕様書から対応するテストコードにリンク、
もしくは外部参照貼るしか無いんじゃないか？
リンクなら、HTMLやらWordやらPDFやらで使えるし、
外部参照ならDTP系ツールで使えたりする。
0728デフォルトの名無しさん
2012/03/07(水) 04:33:23.070729デフォルトの名無しさん
2012/03/07(水) 06:09:29.14そうそう
仕様書とプログラムのリンクが物理的に外れちゃうからややこしいことになるのであって
いっしょにくっついてりゃわざわざヘンテコなことする人いないよ
0730デフォルトの名無しさん
2012/03/07(水) 06:56:45.37あれはあれでヘンテコな気がするが
0731デフォルトの名無しさん
2012/03/07(水) 08:27:31.14そういう妄想もつような現場は
どーせこーなる↓
xxx機能
link1：Aaa.java
link2：Bbb.java
：
link98：Xxx.java
0732デフォルトの名無しさん
2012/03/07(水) 21:04:24.42せめてDoxygenの改造みたいな奴で頼む
0733デフォルトの名無しさん
2012/03/07(水) 21:12:49.95<argument type="int" name="argc"/>
<argument type="char**" name="argv"/>
<body>
<section id="function1" annotation="Hello World表示機能">
puts( "hello" );
</section>
<section>
return 0;
</section>
</function>
こっからXSLTを使ってHTMLとソースコード生成。
現実に可能ではある。
0734デフォルトの名無しさん
2012/03/08(木) 12:31:14.770735デフォルトの名無しさん
2012/03/08(木) 18:55:50.96>でもそれって仕様とコードの対応付けできないよね。
それというのが何か分からないけど、
たとえば>>726の最後に紹介したRuby文書化ツールであれば、
DocBookと呼ばれるXMLベースの技術系文書向けマークアップ言語を採用している
・DocBook 5: The Definitive Guide
http://www.docbook.org/tdg5/en/html/docbook.html
で、DocBookのxrefタグでリンク先の章/節に付けたid属性を指定すれば
(xrefタグが)その章/節の題名にリンクを付けたテキストへ自動変換されるし、
汎用リンクとしてのlinkタグやURLを指定するulinkタグもある
また、外部参照もolinkタグで実現できるよ
>リンクなら、HTMLやらWordやらPDFやらで使えるし、
>外部参照ならDTP系ツールで使えたりする。
これらで指定できるのはソースファイルへのリンクであって、
該当する行番号へのリンクまでは指定できないんじゃないかな？
またマニュアル/パンフレットならともかく、
仕様書/設計書の作成のためにDTP系ツールを使う人なんていないと思う
普通はWord/Excel(あるいはHTML)を使うんじゃないのかな？
結局、>>713の発想を実現するには、VSとOfficeの統合が必要になる
0736デフォルトの名無しさん
2012/03/08(木) 23:40:19.10だからちょっと応援しちゃうのさ
一旦でればエクリプスや他の統合開発環境にもすぐに溶け込んじゃうと思う
次のイノベーションは間違いなく仕様書とソースコードのシームレス化
ＭＳのお手軽ＤＢ機能（ＤＢバインド機能？）なんて後でいいからさっさとＶＳとＯｆｆｉｃｅの統合からやってほしいんだよね
0737デフォルトの名無しさん
2012/03/09(金) 01:29:59.370738デフォルトの名無しさん
2012/03/13(火) 18:28:25.98フロー書くとcobol経由で実行ファイルに落としてくれてたな。
1日3本とか作れて楽だったし、時給5000円ぐらい貰えた。
0739デフォルトの名無しさん
2012/03/18(日) 02:09:04.56仮想ラスタライズ用クラスに、仮想ラスタライズクラスを参照する内部クラス(インターフェース)を、
持たせれば、簡単に空間の再帰構造を実現できるんだけど、図形要素を追加したくなったら
仮想ラスタライズ用クラスにいちいち、描画用メンバーを追加せにゃならんのが面倒い。
0740デフォルトの名無しさん
2012/03/18(日) 07:42:15.860741デフォルトの名無しさん
2012/03/18(日) 10:04:36.30struct Rasterizer
{
struct Group
{
virtulal bool Shell( Rasterizer &device ) = 0;
};
virtulal bool Shell( const Group&, const Algebra::Matrix& ) = 0;
virtulal bool Shell( const Shape::Path& ) = 0;
virtulal bool Shell( const Shape::Image& ) = 0;
virtulal bool Shell( const Shape::Text& ) = 0;
};
0742デフォルトの名無しさん
2012/03/18(日) 10:23:03.650743デフォルトの名無しさん
2012/03/18(日) 10:30:20.45Groupはローカル空間の図形集合で、内部でRasterizerに対して
Pathとか、Image、Groupの描画を行います。
0744デフォルトの名無しさん
2012/03/18(日) 10:31:32.46エスパーして俺が設計しなおすと
TParam = class
現在の変換行列とか描画対象とか
end;
TClass1 = class
private
子のリスト
public
property pos
property rotate
property scale
procedure draw(p: TParam); virtual;
end;
ってやって
TRect = class(TClass1)
public
property width
property height
procedure draw(p: TParam); override;
end;
って追加していくんじゃだめなの？
delphiのカスタムコントロールそのままの設計だけど
子の描画が絶対ならdrawとdrawcoreにわけて、drawcoreだけprotectedにしてvirtualにしてもいいけどな
子を描画してその描画結果に対して何らかの処理を施すみたいなのがあると、draw自体を変える必要があるから↑で書いたのが柔軟性があるけど
0745デフォルトの名無しさん
2012/03/18(日) 10:34:24.87すぐに破綻する
描画専門のクラスを作ってそいつに描画するものぶち込む設計にしないとうまくいかない
render.draw(描画したいモノ);
の形で
0746デフォルトの名無しさん
2012/03/18(日) 10:38:43.34描画専門の作ってそこに自分自身を投げ込むようにすればいいな
0747デフォルトの名無しさん
2012/03/18(日) 10:42:43.22?
TClass1の位置づけが、描画する側なのか、描画される側なのか
はっきり断定できないよ。TClass1の具体的な名前で教えて。
あと、Rasterizerの実装は、png画像だったり、svgのベクトルデータだったり、
GDIの描画APIだったりするから、デバイスと描画が癒着されると困るよ。
0748デフォルトの名無しさん
2012/03/18(日) 10:47:45.36使い方は同じだね。
boost::shared_ptr<Rasterizer> render = device->CreateRasterizer();
render->Shell( Text( いろいろ ) );
render->Shell( Image( いろいろ ) );
Path path;
path += Move.New( いろいろ );
path += Line.New( いろいろ );
render->Shell( path );
0749デフォルトの名無しさん
2012/03/18(日) 10:49:00.99いんじゃね？
0750デフォルトの名無しさん
2012/03/18(日) 10:49:25.91描画専門クラスにTClass1投げ込むのはやっぱりだめだわ
描画専門クラスはTRectのことなんて知る必要も無いから
問題をふたつに切りわけようぜ？
・描画のプラットフォーム非依存
・入れ子。本質的な部分
描画のプラットフォーム非依存は、ラッパー作ればいいだけ(お前の考えるRasterizerの役割な)
ほとんどのプラットフォームで実現できるであろう描画関数を用意しておく
入れ子に関しては↑で俺が書いた方針
TRectとかはラッパーで用意された関数を駆使して自分を描画する
TParamをRasterizerに変えちゃって。行列の情報とかもついでに持たせてもいいかも
GDI+とかOpenGLみたいな感じで
0751デフォルトの名無しさん
2012/03/18(日) 10:53:00.89>>739 にも書いたんだけど、これだと新しいShell関数を追加しようと思ったら、
Rasterizerに直接追加するしか無いんだよね。Rasterizerを継承してShell関数追加ってのが出来ないんだよ。
0752デフォルトの名無しさん
2012/03/18(日) 10:53:08.98Shell関数の出来が悪いとしかいいようがないじゃん
構造とかそういう問題なのか？
0753デフォルトの名無しさん
2012/03/18(日) 10:56:24.10じゃあポリゴンでしか扱えないのもバカげてるだろ？
だから
TCustomPolygon = class(TClass1);
TSeisankakkei = class(TCustomPolygon);
TRect = class(TCustomPolygon);
TPolygon = class(TPolygon)
ってやっていく
-------------------------------------
ラスタライザっていうのはデバイスに近いでしょ？低レベルなわけ
デバイスにできることって限られてんじゃん。その限られたことを全部最初に書いておけばいいだけ
よりハイレベルな、正三角形描画みたいなのは↑で実現する
0754デフォルトの名無しさん
2012/03/18(日) 11:06:00.74後出しになってごめんね。
Shellの引数に渡してるオブジェクトは、図形情報もってるだけで、複合図形でなければ
描画自体はしないんだ。Rasterizerに値をわたすだけなんだよ。
描画ターゲット非依存自体は、ある程度解決出来てるんだけどねぇ。
結局、Rasterizerに考えうる限りShell関数用意するしかないのか。
>>753
高レベルなのは、それでいいんだけどね。
0755デフォルトの名無しさん
2012/03/18(日) 11:11:53.67問題なのは、低レベルな部分の対処なんだよ。
たとえば、SVGは、パスや、線分、文字、行列変換とか数十以上の
図形情報をそのままファイルに書き込めちゃう。
もし、自前で行列変換した結果を渡すとかしちゃうと無駄が発生しちゃう。
0756デフォルトの名無しさん
2012/03/18(日) 11:17:27.13ちなみに、そういう高水準な例だとPathクラスを継承することでカバーできてるよ。
0757デフォルトの名無しさん
2012/03/18(日) 11:19:41.67SVGにあわせればいいんじゃない？
Rasterizerに
・begin入れ子
・end入れ子
っていう命令を追加してさ
GDIとかはそれをエミュレートして描画するのよ
0758デフォルトの名無しさん
2012/03/18(日) 11:21:44.53後で最大公約数が増えた日には・・・
0759デフォルトの名無しさん
2012/03/18(日) 11:25:03.60あれじゃん、Rasterizerの派生にもう一回派生クラス用のGroup定義すり済むだろ
どうせRasterizerのGroup使ってるクラスは、Rasterizerの図形描くことしか考えてないわけだし
0760デフォルトの名無しさん
2012/03/18(日) 11:33:05.43確かにね。
ついでに、GroupとRasterizerの相互再帰を解消する方法ってないかなぁ。
別にオブジェクト的に相互再帰してるのは構わないんだけど、クラスレベルで
直接相互再帰してるのはなんか嫌だわ。
0761デフォルトの名無しさん
2012/03/18(日) 11:36:19.76何が設計で解消できるものか線引きができてないってことだろ
この問題に関していうと全部書くしかない
0762デフォルトの名無しさん
2012/03/18(日) 11:38:26.36group内のshellって何すんの？
0763デフォルトの名無しさん
2012/03/18(日) 11:39:41.59図形を網羅するかは、>>759の派生にいちいちGroupを定義する事で解消できそう。
あとは、大して問題じゃないけど相互再帰を解消出来たらなぁ。
0764デフォルトの名無しさん
2012/03/18(日) 11:46:50.54bool Group::Shell( Rasterizer &render )
{
render->Shell( image1 );
render->Shell( text );
render->Shell( image2 );
・・・・以下略・・・・
}
説明だけは前にも書いたけど、
こんな感じで、図形を内部に複数持ってて、
Rasterrizerに描画するの。
この時、Rasterizerの座標空間やその他のコンテキスト情報が
直接RasterizerのShell呼んだ時とは別物に変更されてる。
0765デフォルトの名無しさん
2012/03/18(日) 11:51:09.91ダサくね？
Rasterizerは黙って
・ポリゴン描画
・変換
・入れ子開始
・入れ子終了
だの"命令の羅列"だけを実行するべきじゃない？
Groupなんてものはこっち側っていうかアプリケーション側っていうか高レベルなことじゃん
人間にとっては分かりやすいけど、SVGとかGDIにとっては不要なもの
それをRasterizerに持たせるのはダサい
なんで俺のTClass1のようにRasterizerとハイレベルな部分を分離しないんだ？
0766デフォルトの名無しさん
2012/03/18(日) 11:54:29.24それなんかrenderのもつ権限がおかしくないか？
他の人にすごく迷惑かかると思う
0767デフォルトの名無しさん
2012/03/18(日) 11:56:48.63頭の良い奴が書いたコードはパッと見理解できなかったりする
頭の悪い奴が書いたコードもパッと見理解できない
お前のコードはパッと見理解できないわけだが
どっちなんだ
0768デフォルトの名無しさん
2012/03/18(日) 12:00:50.77他人に理解できないコードをたくさん書いたほうがいいよ
他の人に対処されると自分の居場所がなくなるからね
0769デフォルトの名無しさん
2012/03/18(日) 12:02:10.44このコードって何言語？
0770デフォルトの名無しさん
2012/03/18(日) 12:02:45.070771デフォルトの名無しさん
2012/03/18(日) 12:03:20.30実質あんまり変わらない気がしてねぇ。
>>766
>>764 bool Groupって書いちゃったけど、あくまでRasterizer::Groupの派生クラスで定義してるんだよ。
それでもダメかい？
実際ユーザーサイドで使う使い方はこんな感じ。
GroupList group;// GroupListは、Rasterizer::Groupの派生
group += Image::New( いろいろ );
group += Text::New( いろいろ );
render->Shell( group, matrix ):
render->Shell( Text( いろいろ ) );
0772デフォルトの名無しさん
2012/03/18(日) 12:06:53.78前にも書いたけど、複合的な高水準図形は、GroupやPathの派生で済むよ。
0773デフォルトの名無しさん
2012/03/18(日) 12:13:13.39横からだが、>>765氏はシンプルに
「GroupをRasterizerに持たせるのはダサい」と言っているのでは？
0774デフォルトの名無しさん
2012/03/18(日) 12:15:40.07多分そうだと思う。
・入れ子開始
・入れ子終了
結局問題点は、Groupをこれに変えろということなんだろうな。
0775デフォルトの名無しさん
2012/03/18(日) 12:17:48.82糞設計やな。頭悪い奴が書いて理解できなかったパターンか
俺が例に出した正三角形はどうやって実現するんだ
俺が言ったやり方だとセピア調にするエフェクトだの。モザイク書けるエフェクトだの
もっとできることの集合が広がる
これを機に設計について考えてみたほうがいいぞ？センスが標準以下
//ImageとTextもGroupの派生クラス
Group group;// Groupは、Rasterizerの配下には無い
group += Image::New( いろいろ )
group += Text::New( いろいろ )
group.matrix = matrix;
group.draw(render);
ってできるわけよ？
さらには
Group sepia = Sepia::New;
sepia += group;
sepia.draw(render);
ってやればセピア調エフェクトができるわけよ
>>772
Groupの派生で済むのは分かるが。なんでそいつがRasterizerと癒着しなくちゃいけないんだよ
ピタゴラスの発見した正三角形なんていう高尚なものがだよ、日本の一へたれプログラマが設計したRasterizerなんかに振り回されないといけないの？
0776デフォルトの名無しさん
2012/03/18(日) 12:26:50.61そうよ。RasterizerがGroupを持っていたとしても、実際に描画するときにはデコードされるわけよ
意識してないかもしれないけど。再帰によって
ファイルに書き込むときのことを考えれば分かりやすいか
そのデコード処理もRasterizerと分離させれば分かりやすいってことよ
0777デフォルトの名無しさん
2012/03/18(日) 12:28:05.670778デフォルトの名無しさん
2012/03/18(日) 12:28:14.70Groupの部分については、開始と終了をもちょうっと掘り下げてほしいな。
SVGの<g>タグとか<path>タグとかどう表現するかとか。
<g>タグと<path>タグってのはこんなのね。
<g もろもろ属性>
<g>
<path g="M10,20 L20,30 Z" />
</g>
</g>
render->Shell( Trigon( 図形情報) ): // 呼び出してるのはShell( const Path& )
正三角形とかってのはこれで済むよ。
0779デフォルトの名無しさん
2012/03/18(日) 12:30:00.88ここで聞いておいで
C++相談室 part94
http://toro.2ch.net/test/read.cgi/tech/1329512856/
0780デフォルトの名無しさん
2012/03/18(日) 12:30:14.17で、お前の作ろうと思ってるRasterizerは.NETのバイトコードみたいな感じでさ
お前はその.NETのバイトコードに大胆にも構文木を盛り込もうって思ってるわけよ
対応できる言語の幅が狭まるわな
0781デフォルトの名無しさん
2012/03/18(日) 12:31:34.40それ入れ子間違えたら面倒だろ・・・
0782デフォルトの名無しさん
2012/03/18(日) 12:33:10.66㌧
せめてRubyにしてくれんとわからん
0783デフォルトの名無しさん
2012/03/18(日) 12:34:33.59pathの入れ子の中でグループの入れ子が入らないこと保証しないの？
ひたすら実行してテストあるのみ？
0784デフォルトの名無しさん
2012/03/18(日) 12:39:23.84Group g(m);
g.add( Text::New("def") );
g.add( Image::New() );
Device * device = deviceFactory.getdevice();
Render render( device );
render->Shell( &g );
render->Shell( Text::New("abc") );
//-----
Render::Shell( IShape* item )
{
device->Shell( item );
}
Render::Shell( IGroup* g )
{
device->push_context( g.context() );
foreach(device->Shell( i ));
device->pop_context();
}
まあ擬似コードだけどな。
Groupをレンダラの内部クラスにする理由がちょっとわからんな。
ブリッジでデバイスと切り離しておけば、レンダラに必要なのはShell(IShape)とShell(IGroup)だけ。
新しいShapeを追加するときはIShapeを継承させて、デバイスにそのクラスのメソッドを追加すればいいんで
レンダラには手を加える必要がない。
0785デフォルトの名無しさん
2012/03/18(日) 12:48:04.28>Groupをレンダラの内部クラスにする理由がちょっとわからんな。
Groupの中にGroupがある事を想定していて、GroupとRenderの相互再帰を行うためだよ。
Groupを前方宣言してもできるにはできる。Javaとか最近の言語だと、特に小細工しなくとも
相互再帰できるから、C++で単純に相互再帰出来ないこと知らない人には不思議かもしれない。
0786デフォルトの名無しさん
2012/03/18(日) 12:49:19.08そもそもお前の目的は、pngだろうとgdiだろうとSVGだろうと同じコードで走らせたかったんだろ？
RasterizerとGroupの派生クラス達をみっつも書くのは辛いだろ。したっぱがたくさん居れば何の問題も無いけどなwww
俺のやり方なら分離できてRasterizerだけをみっつ書けばいいって言ってるのに。素直に吸収しようぜ？
>>781 >>783
確かにそれは心配だな。解決策はすぐには思いつかん
派生クラスから使えないようにすればいいけど、少し自由度が下がる気がする
あれか、C++ならデストラクタでやることにすれば多少安全か
C#ならIDisposableでな
Delphiは残念ながらInterfaceの自動破棄で強引にやるか、try finallyでやるしか無い
>>784
俺のTClass1の設計と根本的には変わらないな
push_contextとpop_contextの対応の問題がある
0787デフォルトの名無しさん
2012/03/18(日) 12:52:20.71単なるラスターデバイスならそれでいいだろうけど、
ベクターならdeviceは、図形から個々の情報取り出す必要があるでしょ。
画像とか、文字の区別をdevice側でどう付ける気？
まさか、ダウンキャスト？
0788デフォルトの名無しさん
2012/03/18(日) 12:57:24.20どのみち三つ書かなきゃいけないっぽいしねえ。
派生Groupで書くのは、Rasterizer派生で増えたメンバー分だけでしょ。
そこは気にならないけど。
問題点は内部クラスの分離だし。
0789デフォルトの名無しさん
2012/03/18(日) 12:57:51.03GroupのなかにGroupがあるってことは単純にIShapeのコンポジットってかんじか？
それでも相互再帰を行う理由がよくわからん。
>>786
対応の問題とは？
0790デフォルトの名無しさん
2012/03/18(日) 13:02:14.18deviceがRenderにカプセル化されてて
外から、deviceの入れ子を変更できないなら
対して問題じゃないだろ？
push, popが集中するからRenderから直接呼び出せるよりは
圧倒的に安全だ。
0791デフォルトの名無しさん
2012/03/18(日) 13:02:22.88デバイスでは具体的な型を引数に取るShell()が宣言されるよ。
ダブルディスパッチで適切なメソッドが選択される。
ってか、そういうことを言ってるのではない？
0792デフォルトの名無しさん
2012/03/18(日) 13:04:16.35>>781とか>>783とか
まあ、IGroupの派生クラスからはpushとpopを呼べなくすればいいんだけど。それで少しやれることの集合が狭まるからトレードオフなのかなって
>>790
その通りよ。でも自由度が狭まる気がしたのよ
0793デフォルトの名無しさん
2012/03/18(日) 13:04:30.19>>791は忘れて。
0794デフォルトの名無しさん
2012/03/18(日) 13:05:29.35じゃあ、ダブルディスパッチする先のインターフェースは？って事になる。
問題は、ダブルディスパッチ先のインターフェースで起きてる事と同じで、
問題となる部分が、見えやすい部分にあるか、隠れた部分にあるかの違いしかないでしょ。
0795デフォルトの名無しさん
2012/03/18(日) 13:18:14.47珍しくまともに議論してると思って見てたのにイラッとくる
0796デフォルトの名無しさん
2012/03/18(日) 13:31:27.75/〃// / 〃l lヽ∨,〈ヽﾞ､ﾒ〈 }} ;l ﾘ ハ ｌ｀!ヽ.
//' /,' ,' 〃 ｌ l川/,ﾍ丶＼;;ヽ/:'/〃∧ l ﾄ､:l !
〃,'/ ; ,l ,'' ,l| ﾚ'/Ａ､.`､＼;;ヽ∨〃/,仆|│l }. |､
i' ,'' l| ,ｌ ' ｌ. !| l∠ﾆ_‐＼ヽ;＼,//,ｲ| ｌ | l ﾄ/ λ! 、
. ｌ ; :|| ,'i:/ ｌ| |:|: |｀`'^‐｀ヾ∨｀ﾞ/／|斗,l ! | ,ﾀ /l.| ｌ 三__|__
l ' l |｣,' l' lﾊ |'Ν ￣´ ／｀ ,|l_=ﾐ|! ly' ,〈 :|| | 口 |
|ｌ .l H|i: l | ﾞ､| l _.::: ,!: l厂`刈/ /!} :ｌ| ‐┬‐
|! :ｌ |)!| ! | ヽ '´ ’/'_,. ノｲ.〃/|! │田│
l|ｌ |ｌ 「ﾞ|l |`{ .. _ |}/,ﾊ l ￣￣
|!ｌ |l､| !l :|. ‘ｰ-‐=＝ニ=:､__ｊ:） ｌ'|/|l ﾘ ､ マ
ヽ￣ﾆ‐､__.｣乢!L!lヱL｣__ ー､ `'''´ 从「 / 了 用
＼ ｀ヽ＼ /l | /￣´ // '"`ー‐
. ,、 l ﾞ､ / ' |､ { /l/ ,
'} ｌ ﾞ, / |:::＼ } ,.ｲ/ ﾚ |
ｌ l l ,.ｲ l:::::::::＼__ `'-‐::"// |′ ノ
l ! Ｋ ヽ,、 ＼「`''''''''"´:::::::;;:" //
. l ｌ ﾄ､＼( _.... ヽ .:.::::::::;;″ /' ＿
＼ | ｌ| 八､ヽi´ | .:.:::::::::::::i' .:/'"´￣￣￣ ,.へ＼
0797デフォルトの名無しさん
2012/03/18(日) 13:32:42.31内部クラスかどーかみたいな言語よりの話しはオブジェクト指向てきに、どーでもいいだろ
0798デフォルトの名無しさん
2012/03/18(日) 13:35:28.510799デフォルトの名無しさん
2012/03/18(日) 13:37:40.60Googleなみの検索エンジン作れ
0800デフォルトの名無しさん
2012/03/18(日) 13:44:40.36設計の下手さにコンプレックス抱いてる奴ってどのくらい居るの？
それともみんな自信だけはあるの？
0801デフォルトの名無しさん
2012/03/18(日) 13:46:15.75クローラーと検索。文字情報を保持する奴
しかもネットワークでクラウド
まあ、ここに居るやつらなら15分で設計し終わるな
0802デフォルトの名無しさん
2012/03/18(日) 13:53:33.44添削してやっから
ソース出せ
0803デフォルトの名無しさん
2012/03/18(日) 14:11:27.40結論から言うと流行らない
0804デフォルトの名無しさん
2012/03/18(日) 14:12:32.91分量によってはそれシンドイぞｗ
クソみたいなコードが山盛りで来たらどうするよｗ
0805デフォルトの名無しさん
2012/03/18(日) 14:22:01.87構文上の問題じゃないだろ
内部クラスで実現してるか、単にクラス同士直接参照してるかはどうでもいい話だが
クラス間の相互参照が問題なんだろ
interface A
{
void method(B arg);
}
interface B
{
void method(A arg);
}
Javaで書けば、これがおかしいつってんだから言語固有の問題じゃない
0806デフォルトの名無しさん
2012/03/18(日) 14:30:38.97相互再帰解消可能なクラスデザインできる
まともなヤツはいねぇよ
0807784
2012/03/18(日) 14:41:28.34ちょっと直してみた。
いまのおれにはここまでしかできんな。
0808デフォルトの名無しさん
2012/03/18(日) 14:47:32.43前の方がよかったんじゃない？
CompositShape以外からもpush_context、pop_contextアクセスし放題やで
0809デフォルトの名無しさん
2012/03/18(日) 14:49:44.12newDeviceでRasterizerカプセル化したCompositShape返せばいいんじゃね？
0810デフォルトの名無しさん
2012/03/18(日) 14:52:47.33Rasterizerの代わりにCompositShapeを返すならいい線いってる気がする。
描画ロジックは、CompositShapeのメンバー以外見なくて済むようになる訳だかね。
0811デフォルトの名無しさん
2012/03/18(日) 15:00:51.01>class Text;
>class Path;
>class Image;
>class Rasterizer {
サンプルだから揚げ足とり見たいなはなしになるけど、
ここ問題となった相互参照しまくってるよね。
入れ子でない図形だからTextとかインターフェースに
きっちり分離することで解消できそうな部分じゃあるけど。
0812デフォルトの名無しさん
2012/03/18(日) 15:07:07.25まず責務を明確に日本語で記した方がいいんじゃないかな
0813デフォルトの名無しさん
2012/03/18(日) 15:14:27.170814デフォルトの名無しさん
2012/03/18(日) 16:39:29.28インターフェースの処理結果が抽象化できるとは限らない。
例えば、データ分析のプログラムを開発しているとしよう。
Analyzerクラスをインターフェースにして各種分析方法の実装クラスを定義する。
インターフェースをAnalyzer::Analyze( data : double[] ) とする。
この場合、分析結果が vector< double >型 だったり double型 だったりするケースは普通にあると思う。
戻り値が異なる場合は、どう抽象化するのが最適解なのだろう？
0815デフォルトの名無しさん
2012/03/18(日) 16:49:58.380816デフォルトの名無しさん
2012/03/18(日) 16:53:09.99戻り値を得る部分をインタフェースに含めない、が正解かもしれない。
GoFのビルダパターンも原本ではそうかいてある。
よく、ビルダクラスにgetResult()みたいなのをくっつけちゃってる後追い本があるが、
本来は作業工程を呼び出し側（ディレクタ）と呼び出される側（ビルダ）に分離させるのが肝。
ビルダに手順以外のインタフェースを持たせない。結果部分はこのレベルで扱わない。
クライアントは抽象化されたディレクタとビルダを用いる箇所を持ち、
実際に何を得るかは具象クラスを知るクライアント自身がそれに問い合わせれば良い。
MenuBuilder b = new DefaultMenuBuilder // or DebugMenuBuilder
MenuDirector d = new FileMenuDirector
d.construct(b)
Menu m = b.getMenu // or String s = b.getDebugLogString
0817816
2012/03/18(日) 16:57:12.74MenuBuilder b =
じゃなくて、クライアントは具象クラスを知っていて使うのだから、
DefaultMenuBuilder b =
でいいし、あるいは、
MenuBuilder b =
Menu m = ((DefaultMenuBuilder)b).getMenu
でも十分。
ディレクタがビルダを見るとき、そこが抽象化されていれば十分だから。
MenuDirector#construct(MenuBuilder b)であれば十分だから、
クライアントは胸を張ってそれぞれの具象クラスを使う。
0818デフォルトの名無しさん
2012/03/18(日) 16:59:19.91キャストが醜く感じる
0819デフォルトの名無しさん
2012/03/18(日) 17:03:39.14GOF本うんぬんは置いといてさ
Builderが何かを作る目的が、結果を取り出されるために作るんなら
結果の取り出され方を含めて手順だろ。
そこをインターフェイスから外すとかわけわかめ
Builder<T>でgetResultがT型返せばOK
0820デフォルトの名無しさん
2012/03/18(日) 17:06:33.67レス有難う。御意です。
GoFを見返したのですがProduct（私の例で言う分析結果）の抽象化のメリットは小さい、と書いてありますね。
抽象化するとどうも具象を扱ったりダウンキャストを毛嫌いしてしまいます。
作るほうが柔軟にならなきゃ、ですね。
0821デフォルトの名無しさん
2012/03/18(日) 17:07:10.770822デフォルトの名無しさん
2012/03/18(日) 17:12:58.27結果をIFにすると、ダウンキャスト必須になりますね。
プログラムのセマンティックを明示するという意味ではありだと思います。
0823デフォルトの名無しさん
2012/03/18(日) 17:16:55.04template<class type> type Anarizer<type>::Anarize();
template<> double Anarizer< double >::Anarize(){ 処理 }
template<> std::vector<double> Anarizer< std::vector<double> >::Anarize(){ 処理 }
OO関係ないけどC++なんだからテンプレートで返したら？
そもそも、std::vector<double>だけですむものを、doubleで返す意味が解らないけど。
ハゲは、個体じゃなくできるだけ集合で扱えといっとったぞ。
0824デフォルトの名無しさん
2012/03/18(日) 17:23:44.57テンプレート化しても受け手が具象型を扱わなければいけないので実質的な利益はないですね。
クールなコードだと思うし、私もそういう方が好きです。
しかしこういうコードを書くと、40過ぎの前近代的マーのオッサンが切れ始めて、
違う意味でややこしくなります。
0825デフォルトの名無しさん
2012/03/18(日) 17:30:21.11受け手の都合で、型を変えるなら
1.引数で返す
2.テンプレの引数で指定する
3.変換演算子をオーバーライドした一時オブジェクトを挟み込む
4.関数名の中に型名を含める(テンプレ引数の劣化判
これぐらいしか無いでしょ。暗黙だろうが何だろうが、
何らかの方法で呼出側から型情報を渡さなきゃならない。
呼出側に型を選ばせたく無いならダブルディスパッチを使うという方法もあるが。
0826デフォルトの名無しさん
2012/03/18(日) 17:39:53.62ハゲって誰だよw
0827デフォルトの名無しさん
2012/03/18(日) 20:42:34.80また abstract factory と builder の違いも。
誰か説明して頂けませんでしょうか？
というか、どなたかもっと分かり易い名前を
つけてくれる方はいないでしょうか？
実際、こういうプログラミングイディオムに対して、
分かり易い名前を付けるという仕事は、
社会的な需要があると思うのですが・・・。
0828デフォルトの名無しさん
2012/03/18(日) 20:47:04.04ビャーネ・スッポスッポじゃね？
0829デフォルトの名無しさん
2012/03/18(日) 20:49:32.370830デフォルトの名無しさん
2012/03/18(日) 20:50:10.02正確な発音議論でスレを使い切っちゃうだろ
0831デフォルトの名無しさん
2012/03/18(日) 21:07:18.26ファクトリメソッドは、テンプレートメソッドに近い（？）。
インスタンス作成をサブクラスに任せる。サブクラスでする実装が、インスタンスの生成というだけのこと。
サブクラスがFoo create()で実際に、return new AbabaFooするか、return new BuboboFooなどする。
インスタンスを返すメソッドと、サブクラス化によるその実装という対応に着目。
アブストラクト～のほうはまず大きな違いとして、インスタンス群を扱う。
createFoo, createBar, createBazをもつような工場クラスを考え、
今度はその工場を入れ替えて使えるように、抽象的な工場として扱う。
AbstractFactory af = new AbabaFactory // or BuboboFactory
Foo f = af.createFoo
Bar b = af.createBar
などとして使う。その名の通り、抽象的な工場。部品を抽象化し、工場自体も抽象化。
ビルダは手順だけを外に示す。内部でなにをどうやって作るかを全部隠す。
段階的にモノをつくりたい場合にも生きてくる。JavaやC#のStringBuffer, StringBuilderとか。
ビルダインスタンスはディレクタ（やクライアント）に何度も細かい指示を受けて、最後に結果を返す。
0832デフォルトの名無しさん
2012/03/18(日) 21:31:00.38丁寧な解説ありがとうございます。
でも、なんかピンとこないんですよね。
分類癖過剰とでも言うのでしょうか？
どうも分類すること自体に意味を見いだしている感が否めないのです。
昔々、論理学が未発達の頃、３段論法の論理の立て方は
偉い先生方によって細かく分類されていたそうです
（選言的三段論法、定言的三段論法等。本当はもっと細分化されたらしい）。
今時そんなことやる人は、学者さんの中にすらいないですよね？
デザインパターンも、同じ轍を踏んでいるのではないでしょうか？
0833デフォルトの名無しさん
2012/03/18(日) 21:35:49.50factory method ・・・ 継承元classのために、派生classがobjectを作成する。
abstact factory ・・・ 継承元classを利用するclassのために、派生classがobjectを生成する。
builder ・・・ 上の二つとは別次元のもので、派生classが値を加工してobjectを生成する事を主目的とする。
上の二つとは、排他的関係ではない。
0834デフォルトの名無しさん
2012/03/18(日) 21:36:27.69プログラミングの複雑さ＞デザパタ自体の複雑さ
という場面でのみ使えるから心配いらない。
使える場面以外で使う必要ないし、
メリットを感じない場面で感じようとする必要も無い。
0835デフォルトの名無しさん
2012/03/18(日) 21:38:50.88目的に応じて名前がついてんの。ソースコードの形態そのものに名前が付いてるわけじゃない。
例えば、DisplayとMonitorは見ようによっては同じだけど、言葉がとらえてる部分は違うでしょ。
0836デフォルトの名無しさん
2012/03/18(日) 22:15:54.54丁寧な解説ありがとうございます。
でも、やっぱりピンとこないんですよね。
これらは、所詮エンジニアリングの道具ですから（ですよね？）、
厳密な定義など、全て机上の空論に過ぎません。
それよりも直感に働きかけること（つまりピンとくること）が重要だとおもいますし、
それこそがデザインパターンの存在意義だと思っていました。
>>834
もちろん「使えなければ使わなくて良い」と簡単に言えれば良いです。
でもその判断を行うのは、全て完全に"覚えた"上での話だと思います。
そして、GoF に追従しようとする人達によって、
新たなパターンが雨後の竹の子のごとく量産されているのが実情です。
まるで、お役所が日夜新たな政令を生み出しているかの様に、です。
>>835
私には、"abstact factory" という名前は、
「平成十三年九月十一日のアメリカ合衆国において発生したテロリストによる
攻撃等に対応して行われる国際連合憲章の目的達成のための諸外国の活動に対して
我が国が実施する措置及び関連する国際連合決議等に基づく人道的措置に関する
特別措置法」と、対して変らないものに見えます。
というかデザインパターンの意義は、上でも述べたように、
各パターンの概念にあるのではなく（概念は既にあるものだから、
デザインパターンの功績ではない）、それに適切な名前をつけた事に
あるものだと思っていました。
実際、"abstact factory" って適切な名前だと思いますか？
0837デフォルトの名無しさん
2012/03/18(日) 22:17:52.38不勉強なお前の自説なんか興味ねーよ
0838デフォルトの名無しさん
2012/03/18(日) 22:24:20.94実際チームで仕事してるときに、何でこういう構造にしたか
説明する時にしょっちゅう使ってる。ある目標の裏付けとして
説明するにゃ便利なのさ。まぁ、集団で自社製品の開発とか
経験しないと価値は見出せんかもな。
0839デフォルトの名無しさん
2012/03/19(月) 02:20:13.15デザパタはコミュニケーション残すとを減らすのが目的だよ。
分かりきったものは、いつも同じパターンで書けばバグも減るし、変更するときも話が早い。
一人でやっててもまあ意味ないわ。
0840デフォルトの名無しさん
2012/03/19(月) 05:11:14.200841デフォルトの名無しさん
2012/03/19(月) 06:38:33.70概念は既にあったとしてもその概念というか使用目的という単位でラベル付けした功績が大きいんだよ
上のレスもあるけどクラス構造に名前をつけてるわけじゃない
そんなこと言ったらほとんどが部分的にはStrategyパターンになる
名前がわかりにくいのは確かに初期の学習するうえでは障害になると思うが、理解してからは特に問題にならない
中身を理解していれば名前はhogeパターンやfooパターンでも問題ない
0842デフォルトの名無しさん
2012/03/19(月) 06:59:28.65正直日本の多くの「就職してから研修でプログラマ始めました」という人間にはデザインパターンのハードルは高いよ
専門職なんだから基礎は大学で学んできて当然のはずだが、日本の大学では品質は重視されず動けばいいという姿勢だから設計など気にしないし、SI企業は文系採用するしでグダグダ
0843デフォルトの名無しさん
2012/03/19(月) 09:15:40.06小学校から始めた俺達みたいなサラブレッドにはどうしたって適わないわけだ
0844デフォルトの名無しさん
2012/03/19(月) 09:16:58.66教え甲斐がある。あいつらが三人集まったらヤバイ
0845デフォルトの名無しさん
2012/03/19(月) 17:50:48.17同期の東大と一緒に研修受けたが理解力の差に愕然とした
普通は10聞いて5わかればいいところを、10聞いて20理解してる感じ
0846デフォルトの名無しさん
2012/03/19(月) 18:11:04.330847デフォルトの名無しさん
2012/03/19(月) 18:12:11.02①『監査法人 (2008)』反体制・反社会
②『最後の戦犯 (2008)』反日・天皇制度廃止・反体制・反社会
③『リミット -刑事の現場２- (2009)』反体制・反社会
日本放送協会 、、 〒150-8001 東京都渋谷区神南2-2-1
韓国放送公社(KBS) 〒150-0041 東京都渋谷区神南2-2-1NHK東館710-C ←よく痴漢やヤクで捕まるのはここの工作員
テレビが言えない民主党のスポンサー=韓国北朝鮮
あとはもうわかるよな
民主党は朝鮮人だらけ。前科者前原やキムチイオン岡田が平気で嘘を付き、口だけなのもそういう裏があるから。
野田はどうだろうか。韓国人の集いに出席し、韓国人暴力団から賄賂を貰っている野田は
0848デフォルトの名無しさん
2012/03/19(月) 19:33:34.92理解できないとか以前にデザインパターンを理解しようというやつがほとんどいないから終わってる
0849デフォルトの名無しさん
2012/03/19(月) 20:09:40.82シングルトン以外で。
0850デフォルトの名無しさん
2012/03/19(月) 21:05:59.500851デフォルトの名無しさん
2012/03/19(月) 21:18:19.67この一言で、話が通じるのが
デザインパターンの凄さだよな。
もし、「シングルトン」という言葉がなければ、
どう表現していただろうか。
0852デフォルトの名無しさん
2012/03/19(月) 21:20:40.20GoFは前書きでデザパタはたくさんあるが、その極一部を紹介すると書いてる
0853デフォルトの名無しさん
2012/03/19(月) 22:08:02.24Interpreter
こーゆーのは、素直にCompiler Compilerや、Parser Conbibatorに任せるべきだと思う。
0854デフォルトの名無しさん
2012/03/19(月) 22:23:35.08>昔々、論理学が未発達の頃
>デザインパターンも、同じ轍を踏んでいるのではないでしょうか？
>新たなパターンが雨後の竹の子のごとく量産されている
うん。これらはどれも言い当ててる。
こいつ只ものじゃないぞ。
他のデザパタ雑魚どもはよく話を聞いておけ。
0855デフォルトの名無しさん
2012/03/19(月) 22:32:12.04おれもGoF読むたびにInterpreterは使う機会がなさそうだなーと思ってた
0856デフォルトの名無しさん
2012/03/19(月) 23:24:54.17ここの奴等はなぜかデザパタが入る工程があっちゃうんだよね
それが長年の疑問
描いた構成の通りにクラス作るだけなのになんでわけのわからない中間クラスが生まれるの？
黙ってクラス入れるとリーダーに殺されない？
0857デフォルトの名無しさん
2012/03/19(月) 23:28:37.780858デフォルトの名無しさん
2012/03/19(月) 23:29:42.74色んな職場（派遣なので当然大手ばっかり）まわったけど
デザパタなんて使ってるところ１つも当たったことない
0859デフォルトの名無しさん
2012/03/19(月) 23:34:35.970860デフォルトの名無しさん
2012/03/19(月) 23:34:50.75デザパタの想定してる汎用性の方向って業務でいらねぇよ
0861デフォルトの名無しさん
2012/03/19(月) 23:38:14.68レンダリングまわりはGPUに任せるから
そんなに出番は無いけど、ファイルの抽象化とかじゃ
Feature、Figureの管理、画面制御に活躍しとる
0862デフォルトの名無しさん
2012/03/19(月) 23:40:04.51↑これさなんでswitch-caseで並べちゃダメなの？
見難いじゃん
0863デフォルトの名無しさん
2012/03/19(月) 23:44:31.24複数箇所に分岐が必要なとこがあったらメンテナンス性が落ちる
Stateパターンなら修正時に気にするところは１箇所ですむ
0864デフォルトの名無しさん
2012/03/19(月) 23:44:46.57デザパタがさも標準語であるかのように語るのやめて欲しいよな
0865デフォルトの名無しさん
2012/03/19(月) 23:47:32.88State Machineはそんな単純な事に使うもんじゃない。
例えば↓の文字列を記号と数字と文字列コメントに分解するとする。
"int main(int, char**){/*comment*/ return 0;}"
そもそもswitch caseじゃ書けないし、ifとループを駆使するのは辛い。
OOPLが出る前なら、構造体と関数ポインタで解決するのが定石だった。
0866デフォルトの名無しさん
2012/03/19(月) 23:48:43.83それを「使っていない」と言う。
さらに言うと、これって○○パターンの亜種じゃね？とか、
○○パターンを応用した「ようなもの」じゃね？とか言い出す奴においては、
デザパタ本を読んでもそのツボを正しく理解することには至らない。
さわりの部分でなんとなくの理解を得て帰っていってしまう。
0867デフォルトの名無しさん
2012/03/19(月) 23:50:54.24むしろそれぐらいならループの中でswitch文とif文駆使したほうが楽だろ
もっと後から状態が追加されたりするようなケースで使うべき。
0868デフォルトの名無しさん
2012/03/19(月) 23:55:25.47具体的にどうやって書くよ？
コメント部(/**/)とかあれば文字列部("")とか
数値や記号を切り離す時とは全然違う。
こういうパターンが来たときswitchの視点で言えば
ジャンプテーブルの書き換え見たいな方法を取ることになる。
それをどうやって簡単に書く。
0869デフォルトの名無しさん
2012/03/19(月) 23:55:29.54こいつらのせいでプログラミングが複雑に見えるようになった
0870デフォルトの名無しさん
2012/03/19(月) 23:58:20.57いや。デザパタは知ってるのよ。だけど知るずっと前から概念は理解してたから何をいまさらって感じで
もう俺にとってはエスペラント語みたいな位置づけよwww
0871デフォルトの名無しさん
2012/03/20(火) 00:06:22.350872デフォルトの名無しさん
2012/03/20(火) 00:23:48.84てかそんな戦術レベルの話はどうでもいいだろ
設計なんだから戦略レベルの話をしろよ
0873デフォルトの名無しさん
2012/03/20(火) 00:30:13.37戦術と呼べそうなのはSingletonとAbstract Factoryを組み合わせぐらい
MVCやエディタ設計のレベルでないと戦略的と呼べるものは無いだろ
0874デフォルトの名無しさん
2012/03/20(火) 00:31:13.78正：
戦略と呼べそうなのはSingletonとAbstract Factoryを組み合わせぐらい
誤：
戦術と呼べそうなのはSingletonとAbstract Factoryを組み合わせぐらい
0875デフォルトの名無しさん
2012/03/20(火) 01:56:09.20今更是非について話すことはないと思ってたけど、世間は広いな。
0876デフォルトの名無しさん
2012/03/20(火) 02:20:09.71Cで書こうと思って途中でめんどくさくなったんでJavaScriptで
書いたけど大体こんな感じじだろ。トリッキーなテクに頼らなくても
別段書きにくいor読みにくいことはないと思うが。
function tokenize(inStr) {
var i = 0; var c = null; var tkn;
function step() { c = (inStr.length <= i) ? null : inStr[i++]; }
function push() { tkn += c; step(); }
function skipWhiteSpace() { while (c == ' ' || c == '¥t' || c == '¥n') { step(); } }
function numberLiteral() { push(); while (c >= '0' && c <= '9') { push(); } }
function comment() {
push();
while (c) { if (c == '*') { push(); if (!c) { break; } if (c == '/') { push(); break; } }
push();
}
}
function identifier() { push(); while (c >= 'a' && c <= 'z') { push(); } }
function scan() {
tkn = ""; skipWhiteSpace();
if (!c) { return false; }
if (c >= '0' && c <= '9') { numberLiteral(); return true; }
if (c >= 'a' && c <= 'z') { identifier(); return true; }
if (c == '(' || c == ')' || c == ',' || c == '*' || c == '{' || c == '}' || c == ';') { push(); return true; }
if (c == '/') { push(); if (c == '*') { comment(); return true; } else { return true; }}
return false;
}
var result = ""; step(); while (scan()) { result += tkn + "¥n"; } return result;
}
alert(tokenize("int main(int, char**){/*comment*/ return 0;}"));
0877デフォルトの名無しさん
2012/03/20(火) 03:19:15.49お前例の馬鹿だろｗ
> 描いた構成の通りにクラス作るだけなのになんでわけのわからない中間クラスが生まれるの？
> 黙ってクラス入れるとリーダーに殺されない？
デザパタは、「描いた構成」に含まれるもので
リーダーが入れるもので、それができない奴は無能なだけ。
黙って入れるのがダメなら、断ってからいれればいい。
お前がおかしいだけって、まだ思い知ってなかったのか？
0878デフォルトの名無しさん
2012/03/20(火) 05:52:05.14そんな実装よりの話はおかしいやろｗ
0879デフォルトの名無しさん
2012/03/20(火) 05:55:52.35具体的にな
0880デフォルトの名無しさん
2012/03/20(火) 05:59:14.830881デフォルトの名無しさん
2012/03/20(火) 06:01:56.19常識ですが？
デザインパターンの実装例の話と
ごっちゃにしてませんか？というかしていますよね？
0882デフォルトの名無しさん
2012/03/20(火) 06:04:02.88なんかやけに戦術レベル過ぎない？
オブジェクト指向が役に立つレイヤーじゃない気がするんだけど・・・？
0883デフォルトの名無しさん
2012/03/20(火) 06:04:44.13それはあなたが全く理解してないだけですね。
0884デフォルトの名無しさん
2012/03/20(火) 06:05:17.23憂鬱本理解できた？
有名な本だから知ってると思うけど
普通はああやって作るんだよ
0885デフォルトの名無しさん
2012/03/20(火) 06:08:56.02設計者の考えで自由に取り入れるもの
実装者が担当する箇所であれば
実装者の考えで自由に取り入れるもの
ここまではいいですか？
デザインパターンは、実装者が担当するものであれば、
実装者が自由に取り入れていいわけです。
設計者が「デザインパターンを使うな」と言っている時点で、
設計者がデザインパターンを担当する。つまり設計と認めているようなものです。
0886デフォルトの名無しさん
2012/03/20(火) 06:09:46.83いや、仕様書どおりに作れよ
0887デフォルトの名無しさん
2012/03/20(火) 06:10:54.69それ評価悪いよ。
0888デフォルトの名無しさん
2012/03/20(火) 06:12:57.48さっきも言ったけど、ここは
設計の話するスレなんすけど？
0889デフォルトの名無しさん
2012/03/20(火) 07:17:10.12http://engawa.2ch.net/test/read.cgi/poverty/1332079527/
読売新聞社の全国世論調査（２月２５～２６日実施、面接方式）で、憲法を「改正する方がよい」と答えた人は５４％となり、
昨年９月調査（４３％）から１１ポイント上昇した。「改正しない方がよい」は３０％（昨年３９％）に下がった。
支持政党別でみると、改正賛成派は無党派層で５５％（同４０％）、民主支持層で５１％（同４５％）、自民支持層でも５３％（同５１％）に上がった。
（2012年3月18日22時27分 読売新聞）
http://www.yomiuri.co.jp/politics/news/20120318-OYT1T00619.htm
0890デフォルトの名無しさん
2012/03/20(火) 08:23:20.34まあ盛り上がるからいいか
0891デフォルトの名無しさん
2012/03/20(火) 12:17:37.77同じ事しか言ってないけどなｗ
0892デフォルトの名無しさん
2012/03/20(火) 15:53:47.18コードの中に立ち入った仕様書なんてねぇだろ
仕様書ってのは入力(キー入力、ファイル入力、画面操作、
イベント、他)が有ったとき、どういう出力(メッセージを出す、
ファイルを吐く、ファイル操作レジストリ操作をおこなう、
DBを操作する、画面を書き換える)を出すかを定義したもんだ。
コードの中に立ち入るってどこで使われてる仕様書だよ
0893892
2012/03/20(火) 15:58:10.510894デフォルトの名無しさん
2012/03/20(火) 16:01:33.050895デフォルトの名無しさん
2012/03/20(火) 16:06:48.940896デフォルトの名無しさん
2012/03/20(火) 16:14:19.76設計書ではなく詳細だ。
0897デフォルトの名無しさん
2012/03/20(火) 16:18:10.16ひどけりゃ各者各様だからな
同じ組織にでもいなきゃ
共通のものを想定して会話なんてできんわ
0898デフォルトの名無しさん
2012/03/20(火) 17:36:06.03仕様とは外側(客や上司)向けのもの（パワポなどで体裁を整える事も多い）
設計とは内側(開発者側)向けのもの（場合によっては手書きでもかまわない）
同一人物がそれらを行う事は多いがごちゃ混ぜにするのは素人。
0899デフォルトの名無しさん
2012/03/20(火) 17:41:19.05>>692でやれ
0900デフォルトの名無しさん
2012/03/20(火) 17:42:19.09機能仕様は外向けの内容だから機能設計ではなく機能仕様と言うんだ。
0901デフォルトの名無しさん
2012/03/20(火) 17:42:34.73OOはできる奴がマトモに使うと絶大な効果を挙げるレベル
関数型は馬鹿が引っかかるレベル
0902デフォルトの名無しさん
2012/03/20(火) 18:26:22.28プログラム。
仕様ではない。
クラスは客が興味がある物。
だからプログラマが作る。
0903デフォルトの名無しさん
2012/03/20(火) 18:40:43.200904デフォルトの名無しさん
2012/03/20(火) 18:44:15.01仕様書作成とか設計書作成は
省くことは可能だが、
動作するプログラム作成は省けない。
0905デフォルトの名無しさん
2012/03/20(火) 18:45:47.180906デフォルトの名無しさん
2012/03/20(火) 18:47:53.14だからどうしたという話。
0907デフォルトの名無しさん
2012/03/20(火) 18:47:57.650908デフォルトの名無しさん
2012/03/20(火) 18:48:30.580909デフォルトの名無しさん
2012/03/20(火) 18:55:57.76で？
0910デフォルトの名無しさん
2012/03/20(火) 18:57:48.83一方未完成な仕様書からアプリを完成させるのは
日常的に行われている。
仕様書は未完成でも良い。そもそも期待してない。
0911デフォルトの名無しさん
2012/03/20(火) 19:19:49.510912デフォルトの名無しさん
2012/03/20(火) 19:21:34.21仕様書に付いて語りたいなら本スレいけよ
0913デフォルトの名無しさん
2012/03/20(火) 20:07:01.24仕様書がーっが湧いたらスルーしろよ
0914デフォルトの名無しさん
2012/03/21(水) 00:29:17.540915デフォルトの名無しさん
2012/03/21(水) 00:33:03.040916デフォルトの名無しさん
2012/03/21(水) 00:35:05.34もう１０年も派遣やってるからさすがにそれはないｗ
0917デフォルトの名無しさん
2012/03/21(水) 00:45:19.12おまえのレベルが低くすぎて
そういう現場にいれてもらえてないだけだぞ・・・
0918デフォルトの名無しさん
2012/03/21(水) 00:49:59.70馬鹿みたい
現実みろよｗ
0919デフォルトの名無しさん
2012/03/21(水) 00:50:49.40この論理性皆無な思考に疑問を覚えない時点で末期
0920デフォルトの名無しさん
2012/03/21(水) 00:54:05.50お前の中では、ソレが現実なんだろう
お前の中ではな・・・
現実世界で運がないにしても
facebookでもtwitterでも何でもいいから、まともなエンジニアと繋がりもてば
勘違いに気づけるだろうに
0921デフォルトの名無しさん
2012/03/21(水) 00:59:23.98またこの展開かｗ
そうやって発言を権威付けなきゃならない、素のロジックの弱さを知れ。
0922デフォルトの名無しさん
2012/03/21(水) 01:00:46.56韓国ソウルのガソリンスタンドで販売されている平均ガソリン価格が史上初となる１リットル当たり２１００ウォン
（約１５５円）を突破したと韓国メディアが一斉に報じている。
１５日、韓国石油公社が運営する原油価格の情報サイト「オフィスネット」によると、１５日午前１１時現在、ソウル
の平均ガソリン価格は前日より０．５８ウォン値上がりした２１００．０６ウォンを記録した。ソウルの平均ガソリン
価格が２１００ウォンを超えたのは史上初めてだ。
2012/03/16 [16:41]
http://www.krnews.jp/sub_read.html?uid=1152§ion=sc10
韓国人アルバイトの46.8％、「最低賃金ももらっていない」 民衆の声
韓国での労働者のうち、半数近くが最低賃金（韓国は4320ウォン）以下の給料で働かされていることが分かった。
1681人を対象に実施したアンケート調査の結果を発表した。46.8％が最低賃金の時給4320ウォン（約320円）より低い賃金だったと述べた。
賃金のほかにも、勤労基準法違反はさまざまなものがあった。76％が勤労契約書を作成しておらず、
事故が起きた時に守ってもらえなかったと答えた人は 65.9％に達した。
また、56.7％が「雇用主から一方的に勤労条件を変更させられた」と答え、「賃金未払いおよび削減」のケースは 26％に達した。
セクハラや身体的な暴力を含む人格冒涜を経験した人は30.9％に達し、
また不当な待遇を受けた時は誰かに助けを求めたケースはたったの7.7％だった。
www.vop.co.kr/A00000412011.html
0923デフォルトの名無しさん
2012/03/21(水) 01:01:34.38プロジェクトジェノサイダーとしての地位を固めつつある
0924デフォルトの名無しさん
2012/03/21(水) 01:02:56.22普通に働いてたら使ってるだろ
それに気づけない経歴なんだとしたら
それが経験出来ない奴自身に問題があるとしか
0925デフォルトの名無しさん
2012/03/21(水) 01:03:53.39１０年も大手転々としてみたことねぇから聞いてんじゃん
0926デフォルトの名無しさん
2012/03/21(水) 01:06:47.15いや、OOP否定肯定両陣営に対して横から言ってんだよｗ
技術的に語ることから逃げて
カンタンに権威付けに走り出すようなのはどーなのよっ？てこと。
0927デフォルトの名無しさん
2012/03/21(水) 01:09:33.15権威なしじゃとかおまえのピントがズレてる
0928デフォルトの名無しさん
2012/03/21(水) 01:10:39.50自分で設計すれば何かしら使って綺麗にするだろ
使わずに過ごすとか2～3年どころか半年ですら難しいわ
釣なんだからスルーしろアホらし
0929デフォルトの名無しさん
2012/03/21(水) 01:13:33.82へぇｗ
じゃあなんで「大手」とか「まともなエンジニア」とか「レベルが低すぎ」とかって単語飛び出してんのよ？
俺の職場じゃ使ってた、使ってなかった、なぜこれ以上に情報を盛る必要がある。
0930デフォルトの名無しさん
2012/03/21(水) 01:16:01.66JavascriptでOO生かして作ってみた。>>876よりは読みやすいと思う。
http://pastebin.com/5zJQVhGT
トークン要素の追加がbeginMatchとendMatchを持ったオブジェクトの追加と
パターン配列の入れ替えで済むようになった分、新しいパターンを作り安くなった。
0931デフォルトの名無しさん
2012/03/21(水) 01:17:59.65開いた第一感、「うそこけ！」が脳裏をよぎった。
0932デフォルトの名無しさん
2012/03/21(水) 01:21:10.61lex
matchTorken
matchSkip
ぐらいで。あとは同じパターンの繰り返しじゃん。
0933デフォルトの名無しさん
2012/03/21(水) 01:23:03.49バカちは使えない
0934デフォルトの名無しさん
2012/03/21(水) 01:27:30.98一定の技術持ってないと紹介すらされない案件があること位
自分で、後輩で、協力会社の人で、直接間接知ってるだろ
それ知らないとかどんだけハブにされてんだっていう
0935デフォルトの名無しさん
2012/03/21(水) 01:46:51.330936デフォルトの名無しさん
2012/03/21(水) 01:53:31.88確かに>>876よりはずっと読みやすいんだけど、それをOOを生かしたからってのは
ちょっと違和感がある
0937デフォルトの名無しさん
2012/03/21(水) 01:55:21.73夏に蚊にたかられれば争いは発生する
山でクマに遭遇すれば争いは発生する
争いは異なるレベルで普通に発生する
0938デフォルトの名無しさん
2012/03/21(水) 01:58:20.29matchTorken
matchSkip
http://pastebin.com/mNCtDLuW
0939デフォルトの名無しさん
2012/03/21(水) 02:02:20.47インデントとかコード整形とかが変態すぎて
感心するレベルで読みづらい
どーしてこーなった
0940デフォルトの名無しさん
2012/03/21(水) 02:03:10.720941デフォルトの名無しさん
2012/03/21(水) 02:09:21.80変数の宣言が変態的なのに、
なんでそうなってるか解らん感じだったので直した。
http://pastebin.com/crmQJbzD
0942デフォルトの名無しさん
2012/03/21(水) 02:12:17.14実装しないで人のコードの書き直しばっかする奴。
0943デフォルトの名無しさん
2012/03/21(水) 02:14:14.490944デフォルトの名無しさん
2012/03/21(水) 02:20:15.36普段書いてる言語で書けばいいぞ
JSで書くならそれらしく書いて欲しい。コードとしてなさすぎ。
率直にいうが汚くて俺がチームリーダなら出荷させないレベル
0945デフォルトの名無しさん
2012/03/21(水) 02:30:29.390946デフォルトの名無しさん
2012/03/21(水) 06:25:53.38見たことあるけど、デザインパターンだと気がついていないだけじゃないのか
0947デフォルトの名無しさん
2012/03/21(水) 06:27:32.37それをデザパタだからとはやはり説明しにくいといっためんはあるな
0948デフォルトの名無しさん
2012/03/21(水) 07:19:23.81批(つき合わせて)判(はんだん)じゃない単なる批難。
批判の結果を示せてない。
0949デフォルトの名無しさん
2012/03/21(水) 08:41:35.08余計な中間クラスってなんのこと？
レビューして入れるべきだって思った
暮らすなら問題ないじゃないか。
0950デフォルトの名無しさん
2012/03/21(水) 08:42:17.77客が、デザパタ入れてくださいとか言うのかよ。
0951デフォルトの名無しさん
2012/03/21(水) 08:48:22.120952デフォルトの名無しさん
2012/03/21(水) 09:01:29.04もう少し旨く釣れるようになりましょう。
がんばりましょう。、
0953デフォルトの名無しさん
2012/03/21(水) 19:36:31.68不要だと思うんならこのスレ来るなよ
使える環境を前提に話してるんだから場違いだ
0954デフォルトの名無しさん
2012/03/21(水) 19:46:30.95客がクラス構成まで指示してくるんなら、
そりゃ客の言うとおりに作らなきゃな。
0955デフォルトの名無しさん
2012/03/21(水) 20:11:25.56客が関数入れろと言わなかったら関数も入れられないな
客が変数入れろと言わなかったら変数も入れられないな
0956デフォルトの名無しさん
2012/03/21(水) 22:34:54.65構造的には綺麗だけどパッと見何やってんのか分かりにくいコードだな
0957デフォルトの名無しさん
2012/03/21(水) 23:41:39.18パターンとしてそういうやり方に慣れてしまえば、ぱっと見で動作を把握するのも早いんだろうけど。
0958デフォルトの名無しさん
2012/03/21(水) 23:51:18.03OOPだろうが、デザパタだろうが、非OOPだろうが、自分のコードごと自分のバックボーンを褒める。
0959デフォルトの名無しさん
2012/03/22(木) 00:04:55.090960デフォルトの名無しさん
2012/03/22(木) 00:13:23.88そうけ？WinAPIのWNDCLASSなんざ、慣れるまでは相当キツかったが
慣れてしまえば他人が書いたもんだろうがスラスラよめるぞ
そういうもんだと思って読んでるからな
0961デフォルトの名無しさん
2012/03/22(木) 00:20:18.78Socket然り、GUI Toolkit然り、Archiver然り、物理エンジン然り
パターンというかしきたりを知ってるか知ってないかはかなりデカいと思ふ
0962デフォルトの名無しさん
2012/03/22(木) 02:35:12.64デザパタは無駄なもの。俺が理解出来ないからね。
http://kohada.2ch.net/test/read.cgi/prog/1332351285/
0963デフォルトの名無しさん
2012/03/23(金) 02:24:35.37次スレﾉ>>1よ
0964デフォルトの名無しさん
2012/03/27(火) 19:08:35.36テンプレート型の関数オブジェクトが今の所のベストだ。
継承を使わずに、コールバックの引数を決めたいのだが、いい方法知らない？
0965デフォルトの名無しさん
2012/03/27(火) 19:22:00.970966デフォルトの名無しさん
2012/03/27(火) 20:29:27.86依存を小さくする一方で型安全も実現したい、です。
0967デフォルトの名無しさん
2012/03/27(火) 20:57:33.79要するに委譲しろ。
0968デフォルトの名無しさん
2012/03/27(火) 22:02:53.39デザパタ勉強しろ
0969デフォルトの名無しさん
2012/03/27(火) 22:45:06.58ストレス溜まってんですね。
0970デフォルトの名無しさん
2012/03/27(火) 22:47:25.210971デフォルトの名無しさん
2012/03/27(火) 23:09:18.36class NotifyInterface { virtual void Notify( void*) = 0; };
でコールバックの呼び出し側が
for each o in objects -> o.Notify( arg );
でOK。void*は実装クラスでキャストすると。
めでたしめでたし。
0972デフォルトの名無しさん
2012/03/27(火) 23:11:47.620973デフォルトの名無しさん
2012/03/27(火) 23:13:31.640974デフォルトの名無しさん
2012/03/27(火) 23:14:47.210975デフォルトの名無しさん
2012/03/27(火) 23:15:01.720976デフォルトの名無しさん
2012/03/27(火) 23:37:02.18shared_ptrかweak_ptrとテンプレート組み合わせたコールバックオブジェクト作って使ってるよ。
boostとかでやってる可変長テンプレートを全展開をまねして、void型だけ特殊化してる。
引数0～2個と戻り値を任意の型に取れれば十分と思う。
いっぱい渡したいならtupleも組み合わせればいいしね。
0977デフォルトの名無しさん
2012/03/28(水) 00:07:49.90なんでいちいち複雑にするかね
0978デフォルトの名無しさん
2012/03/28(水) 00:09:31.09>>976 を静的言語でやると、
それだとオブジェクトのインスタンスを関数オブジェクトに渡す羽目（つまりインターフェース継承と同等）になるか、
テンプレート型毎に分かち書きをする（無いよりましだろうけど）なら何のためのテンプレートよ、って話にならないか。
C++のような静的型付け言語でかっこ良く書くのは厳しい気がする。
動的型システムを持つ言語なら>>974 の言うとおり。
0979デフォルトの名無しさん
2012/03/28(水) 00:11:40.43C++ならboost::function<int(int,int)> delegate;ってな変数作って代入すりゃ
インターフェースに相当するもの書かなくて済む。
0980デフォルトの名無しさん
2012/03/28(水) 00:21:12.84actionscriptでも使ってろ
0981デフォルトの名無しさん
2012/03/28(水) 00:23:56.53最先端JavaScriptを採用したと思ったら
JavaScriptは方向転換してしまった。
0982デフォルトの名無しさん
2012/03/28(水) 00:25:17.60javascriptでも使ってろ
0983デフォルトの名無しさん
2012/03/28(水) 00:29:38.82女の子と付き合ったことある？ キモ。
0984デフォルトの名無しさん
2012/03/28(水) 00:52:01.46C++自体おかしな方向に発展してると思う。
それやんならスクリプト言語使おうよ、形式文法を捏ねくり回すのやめようよ、っていう疑問が沸き起こる。
テンプレートはデバッグしにくいし。
そこまでしてコンパイル時に確定させる必要ある仕事がどれだけあるのよと。
0985デフォルトの名無しさん
2012/03/28(水) 01:02:30.73任意の関数を複数個、自由にコールバック同士で接続できるからね。
一番いいのは継承しなくても使える点かな。shared_ptrが継承しなくても使えるのと同じくらいに便利よ。
0986デフォルトの名無しさん
2012/03/28(水) 01:53:22.43まるっきりboostの趣旨を忘れてないかい？
嫌なら自分で作ればいいだけさ。
0987デフォルトの名無しさん
2012/03/28(水) 07:20:54.55テンプレートはコンパイルエラー見づらくはあるが、デバッグしづらいか？
C++の仕事なんてグラフィックスやエンコーダーといった速度求めるものばっかりだろ。
大して速度必要ないなら他の言語使えばいい。
0988デフォルトの名無しさん
2012/03/28(水) 09:43:53.63C言語でポインターを捏ねくり回すのにウンザリした連中が、
C++言語を推し進めて std 名前空間を中心にコードの標準化を目指した。
その一部の人たちが、今度はテンプレートを捏ねくり回し始めている。
0989デフォルトの名無しさん
2012/03/28(水) 21:47:58.35Digesterみたいにロクに例外処理できないライブラリだったり、ファクトリーでいいものをわざわざリフレクション使って
コンストラクター指定させたり、XML無闇に使ってStrutsの様にView間のモデル共有を破綻させてたり、
ジェームスゴスリンが居たころタブーとされてたことを次々と平気で犯してたりする。
結局、どこの言語だってサードパーティのライブラリは汚い物が多い。
Smalltalk系のライブラリや、関数言語用ライブラリみたいな哲学を踏襲した綺麗なものはなかなか珍しい。
0990デフォルトの名無しさん
2012/03/28(水) 22:17:23.32というかこのスレで議論されてる話題を考えている人間の方が少数派でしょ
0991デフォルトの名無しさん
2012/03/28(水) 23:20:25.01あれほどクソ設計なライブラリも珍しい
出きることなら二度と使いたくないわ
1.Builderクラスをユーザーに作らせて、BuilderにXML情報を渡せばいいのに、
リフレクション使ってBeanのオブジェクトを生成し組み立てる
このためBeanじゃないオブジェクトは作れないし
既に有るオブジェクトに値を入れる事もできない
2.intなど値型をBeanのSetterに指定できるが、読み込み元の値が
数値以外だった場合、何もしないので素直にバリデートチェックできない
3.仕方ないのでSetterを文字列で受けとるように変更するが、
Setterでバリデートチェックしたところで例外を投げられない
無理にやろうとするとRuntimeExceptionを使うという汚い方法になる
よって、Beanの生成後に何らかの方法でバリデートチェックを行う事になる
4.Setterの多重定義ができない
Digesterを使うので仕方なく文字列で値を受け取っていたが、
他では数値型でSetterとGetterを使いたいと言う場合
単に文字列で受け取るSetterに加え数値を扱うSetter、Getterを
用意すればいいと思うが、そうするとエラーを吐く
5.無駄にXMLで定義を書く
XMLの入力属性名をどのSetterに割り当てるか、XML定義に書く分には問題ないが、
どのBeanを使うかは、プログラム内部で固定なので簡単に変えられては困る
ましてや、ソースとXMLで二重管理になるのでトラブルの温床になる
レス数が950を超えています。1000を超えると書き込みができなくなります。