オブジェクト設計＆デザパタ　　　　　

1 ：10/05/02 〜 最終レス ：11/11/24

結局、オブジェクト設計、デザインパターンを使えるのは、ジャカルタ・プロジェクトみたいな
優秀な集団だけなんだよね。
オブジェクト設計がどうした？　デザインパターンがどうした？　とアホ面してStrutsなど使って
たやつって何なのさ。StrutsのActionにスパゲッティソース書いていたので、Strutsが泣いていたよ。
大手の上位層の連中しか使わないのが、オブジェクト設計、デザインパターンなんだろうな。
と、上司に皮肉られた私である。
実際に、自作の、または参画しているプロジェクトで作成しているPGにオブジェクト設計、デザインパターン
を使っている天才諸君、どうやったら使えるようになるの？

2 ：

設計って意図してやると言うより、自然に出来ている物だと思う。
デザパタとかの知識だけ増やしてもあまり意味無い様な…

3 ：

情報工系の大学生なら普通に使ってるだろ。
とくにデザインパターンなんて単なる「あるある」のマトメなんだから、
天才とかどうとかじゃなくてプログラム書いてりゃ普通に身に付くし、よく考えたら当たり前のことだろ。
ジャカルタがどういう体制で開発してるかしらんが、ぬわんじゃこりゃってAPIのライブラリも結構ある。ぬわーファクトリふぬーファクトリクラスとかな（笑）馬鹿かテメェって感じだわ。

4 ：

ま、たしかに言葉遊びのようなもんだけど
騙される方も悪いわな
私怨はマ板で

5 ：

このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

6 ：

やはり、大手ＩＴ企業の天才様はこのようなスレには書き込んでくれないみたいだ。
寝ることにするわ。

7 ：

>>5
頼むから、いちいちアイちゃんの言語訓練に2chを使うなよ。
人の迷惑とか考えないの？
京都大学霊長類研究所って無能の集まりなの？

8 ：

アイちゃんが勝手に立てちゃったんだから
許してやって下さい

9 ：

オブジェクト設計＆デザパタをやって、何かよくなると期待するのが間違い。
何をしようがよい設計をする人はよい設計をするし、
ダメな人はダメなんだから、良くも悪くもならないものだと考えておくべき

10 ：

デザパタなんて基礎中の基礎だろ。
デザパタがわかるからといって、うまい設計ができるわけではない。
もちろんデザパタもわからんカスは設計なんてやるべきじゃない。

11 ：

>>8
PC使わせるなよ、荒らし報告すんぞ

12 ：

知ったかぶり多いな。

13 ：

デザパタの話は大抵そうなる。

14 ：

ほんとうにデザパタを使いこなしているやつらは２ちゃんには来ない。

15 ：

使いこなすというほど大したもんじゃない。

16 ：

>>1
>大手の上位層の連中しか使わないのが、オブジェクト設計、デザインパターンなんだろうな。
　たしかに上司の言う通り。いろんな会社にいったけど、まともなフレームワークを作れるは大
手のR＆D部署ぐらい（製品開発をやっている所ではない）だったな。そういう所は、勉強す
るの好きだったり、経費でコンサルを雇っていたりする。
　少なくとも派遣主体でころころ人が変わる所、休憩時間にゲームや漫画とか読むのが好きな
人が多い所で、そういう開発を実践できているところはいないなあ。

17 ：

オブジェクト設計とかwww
デザパタとかwww
オブジェクト指向なんて不自由な環境にいるから余計なものを有難がってるって早く気づけよwww

18 ：

>>17
大手のＳＥ，プログラマと接触してみる機会をもったら目から鱗です、よwo.

19 ：

犬小屋作りからスカイツリーまで十把一絡げにする人がいる

20 ：

犬子屋作りにオブジェクト設計、デザパタ適用を行う必要はない、と言われている。
そこそこの建物になったら使うべき。ちなみにデザパタは適用なのね。適用≠使用ではない。
レベルの低すぎる人は勉強しよう。という私も低いんだが。。。。

21 ：

Strutsが悪い！

22 ：

scheduled age
heigh ass hole ! happy?

23 ：

>>20
それはおかしくね？
デザパタは別に、規模の大小に関わらず、
あるよくある問題に対する　伝統的解決法やテクニック的な解答の識別子　であって、
規模が小さいから使えないとか、大きいから有効とかって物じゃない。
オブジェクト指向についてなら、まぁ分からなくもないけど、
小さいからこそ、しっかりオブジェクト指向で設計しとくと
他への流動性が上がりやすいんだけどな。
あと、やたらと一からオブジェクト指向で設計せねば！みたいな印象をうけるけど、
リファクタリングの際についでに、とか、ひとまず最低限の要求仕様を満たしたから
次のステップの前に。とかでスクラップアンドビルド的にやる方がマトモだと思う。
つか、人間に一から完全を求めるのはいい加減やめるべき。　

24 ：

デザパタはともかく、MVCをまともに実装してるのを見たこと無い。

25 ：

>>24
まずは、Smalltalk-80のMVCのどこに問題があるのか、そこから語ってもらおうか。

26 ：

>>25
Smalltalkはいいけど、JavaのMVCとか糞じゃん。
MVCで作りましたってコードは大抵ModelとControlerが破綻してるし。

27 ：

MVCどうこう言うより、generics以前のJavaのフレームワークは糞。

28 ：

Javaより、Cocoaのフレームワークの方が綺麗だな。

29 ：

そもそもMVCは糞

30 ：

>>29
ｋｗｓｋ

31 ：

つうか、MVCなんていう30年も昔のフレームワークをドヤ顔で教えて自己満足してるオッサンが
オブジェクト指向の進歩を妨げているのだが、怖くで誰も言えない罠w

32 ：

最新の代替案をkwsk

33 ：

MVCよりはMVVMのほうが理にかなってると思われ。

34 ：

AbstractionModel - DiscourseModel - InteractionModel

35 ：

MVVMってControlerとModelが理解できず、VBのFormとクラス一体のスタイルから抜け出せない馬鹿向けじゃん。
TextModel text = new TextModel();
Menu copyMenu = new Menu();
TextArea textView = new TextArea();
copyMenu.addAction(new TextCopy(textModel,textView));
　例えばこのコードなら、TextCopy Controlerは、ViewとModelが変わっても使いまわしし続けられるけど、
MVVMモデルだと組み合わせごとにTextCopyを毎度ViewModelやらに書くわけだろバカバカしい。

36 ：

香ばしすぎるｗｗｗ

37 ：

MVPの質問(相談)ってここでいい？
Presenterって、Viewを構成するコントロールの具体的(物理的)な種類に
依存すべきでないでない認識だけど、あってる？
たとえば、View上の数値入力欄が ただのテキストフィールドなのか、スピンコントロールなのか、
はたまた スライダーコントロールなのかを、Presenterは知らなくていいよね？

38 ：

知らなくていいと思います。
ただeventから取れる場合はともかく、selfから取る場合には、
実装(というか処理系というか)により適切なコントロールの具象にキャストしないとダメかも知れません。

39 ：

次スレここか？
リーナスのお言葉（青い部分がリーナスの言葉）
http://tabesugi.net/memo/2009/1a.html#152154

40 ：

オブジェクト指向のこころ読み始めたけどよくわかんねえ

41 ：

オブジェクト指向スレは3スレ目位で話題がなくなるな
前あったOOPスレも3スレで終わったし

42 ：

>>41
ちょうど むだなOOPゴミスレも掃除できたし良かったんだよ。
次はここを消費してOOPが消えればいいかも 爆

43 ：

commandやobserverパターンなど、デザパタのうち幾つかは
クロージャとか関数オブジェクトを採用すると不要になったりしないかね？

44 ：

方法そのものが無くなるわけじゃないけど、
「forループ」にわざわざパターン名を付けないように、
言語レベルで概念が用意されてれば、その世界では
パターン名は不要だね。

45 ：

functional design patternとかでググったら色々要らなくなったよって記事が出てきたはず(英語)

46 ：

>>43
名前は忘れ去られるかもしれないが、考え方自体はなくなるのではなく、新たな言語パラダイムが作用して、別のパターンがうみだされるんじゃないかな。

47 ：

オブジェクト指向設計とデザパタを勉強中の者です。
オブジェクト指向設計とデザパタは大手企業はガンガン使いこんでいるが、
一般的には使われていないのではなかろうか？　と最近思い始めています。
使えなくて使わないのか、短納期で設計の時間がなくて使わないのか、
いまいち、その辺の事情がわからんです。
まさか必要がないと判断されているのぉ？？？
情報通の方、この点について教えてください。
必要がないならこんな糞難しいものを勉強するのはやめます。

48 ：

頻出問題に対する一般解答だと思ってくれればいいよ。

49 ：

頻出問題に対する一般解答
うまいこと言うね
デザパタは特定の頻出問題についての上手な実装方法だから
局所的に使われる傾向がある（シングルトンにする必要があれば使うし、なければ使わない）
オブジェクト指向設計ってのは「設計方針」なんで広く浅く普及してると思うよ
今時のフレームワーク使ってたら自然と（とはいえ漠然と）身についてると思う

50 ：

シングルトン使う奴はテストを考えていないイケヌマだと思う

51 ：

シングルトンはどうでもいいやｗ
あれはデザインパターンの練習問題みたいなもの。
シングルトンにしたければフレームワーク側で
制御してくれる。

52 ：

>>47
どんな問題があって、それをどのように解決してるのかだけ、ざっくり頭に入れとくといいよ
じっくり学ぶのは必要になってからでいいじゃん

53 ：

> オブジェクト指向設計とデザパタは大手企業はガンガン使いこんでいるが、
> 一般的には使われていないのではなかろうか？　と最近思い始めています。
逆じゃね？ｗ
大手ほど安い外注に出し、安い外注は安いだけが売り物。
技術は低い。大手だからそんなんでもやっていける。
中小のほうがよっぽどデザパタ使ってるだろ
自分の技術力が即会社の存続にかかってくるんだから。

54 ：

有る程度以上フクザツなもんをスッキリ書こうとしたり、
柔軟さをもっと持たせようとしたら悩むっしょ？
糞設計を山ほど繰り返し、日々悩むっしょ？
そこで手に取るもののひとつがデザパタにすぎない。
設計道の一歩目にすぎない。

55 ：

コールバックを関数ポインタとは言わんからな。
ラムダを自然に使えるようになっても、commandだのobserverだの
名前は使われるんじゃね。

56 ：

>>53
取引相手から金貰うやり方にもよるんだと思うよ。
大企業を相手にソースをリリースしていると「何か変更を加えたときに混入するバグ」を恐れて硬直化する。
修正するのに一々マニュアルまであったりしてオーバーヘッドがすごくなる。
俺が前居た会社だと、一案件変更しようとする毎に
・見積もり書
・外部仕様書
・内部仕様書
・単体試験仕様書
・組み合わせ試験仕様書
をかっちり書かされて大変だった。更に各ドキュメントのページ数やらも管理する。
そのドキュメントでも金貰えてたんだけど。
んなことやってるからリファクタリングなんて夢のまた夢って感じだった。

57 ：

俺はコメントの修正前のコードを残すルールのある会社の仕事したことある
コメントアウトされた修正前のコードがどっさり

58 ：

>>57
なにかバージョン管理システムを使えばいいのにね。

59 ：

オブジェクト指向設計をきちんと覚えたい。
実際に設計しながら覚えたいんだけど，良い例題（と模範解答）はないでしょうか。
入門サイトを見ると，「1+2*3」みたいなのを計算するプログラムが挙げられたりするけど，
その程度だったら再起関数で済むと思う。
わざわざ演算子のInterface定義して，Plus型MINUS型のcalc()を実行！
みたいなサンプルを見かけるけど全然参考にならない。

60 ：

>>59
優れた設計を学ぶには優れた設計に触れるしか無いが、何が優れた設計なのかは実は誰もわかってない。
オプソにしても何を見て学べばいいのかわからないし。

61 ：

>>59
ひとまずデザパタ見れ。
関数型の考え方などから見ると古かったり必要のないものもあるけど、未だにオブジェクト指向のエッセンス詰まってると思う。

62 ：

>>59
デザパタとリファクタリングは車の両輪
リファクタリングがうまくなったら自然とうまい設計がわかってくる

63 ：

>>59
実例はフレームワークのソース見るといいよ。手始めには辛いかもだけど、javaのcollection frameworkなんてどう？

64 ：

>>62
同意。OOPの理解を深めようとするのなら、その二つはまさに両輪。
ただ、悲しいかな、それをつきつめた先に設計の極意があるか、
自分の設計力を高みに持っていけるかというとそれはまた別。
どこまで行ってもクソ設計を繰り返すことになるだろう。
それは、個人の設計力、設計センスよりもいつだって、
プログラミングすべき問題のほうがややこしいから。

65 ：

そうかなあ。
デザパタなんてコロンブスの卵にしか思えんけど。
恐らく散々言い尽くされたことだと思うけど、デザパタには確かに意義があるが、
それは技術サンプルとしての意義じゃなくて、コミュニケーションツールとしての意義だよ。
「ここは○○パターン的な発送で作ってあるよ」と言う事で、意思疎通のコストを縮減できる、
それがデザパタの意義であって、それ以上でも以下でもない。

66 ：

まぁまぁ。そう視野を狭めちゃ勿体無いよ。
騙されたと思ってパターン指向リファクタリング入門読んでみ？

67 ：

>65
今のご時世、プログラミングを始めたときにはすでにデザパタが常識になってたって奴もいっぱいいて、
実際そいつらは、デザパタを通して設計を学んでるわけで
ていうか「意義」をひとつに決めようとする必要ないし

68 ：

デザパタは基礎知識としては重要だけど、それを通して設計を学ぶ類のものでは無いと思う
より上位の設計があって、その設計を実現させるための手段としてデザパタがあるという印象
で、>>59が求めているのはそういう上位の設計なんじゃないか？

69 ：

俺の見た限りデザパタのカタログ的用法は疑わしい。
なぜなら、多くの人にとってのパターンの理解度が単に疑わしい。
その定義やメリットについてMLなどでわりと揉めちゃってるのを見る。
例えば、JavaHouseのログを見るといい。Factory Methodパターンなど。
ほかにも、実際２ちゃんでもAbstruct Factoryパターンを、
単なるファクトリメソッドのオーバーライドとして理解している人を見た。
これらは、カタログとしてデザパタが失敗しているというよりは、
やっぱデザパタそのものの理解が難しい、
さらにやっぱり、そもそもスカッとした設計自体が難しいってことと思う。
でなもんで、おとなしく学習のツールとして使うのもどんどん推奨されるべき。

70 ：

誰が何から設計を学ぶかは君の決めることではないと思うが
選択肢を増やす意見ならともかく、出た案を否定することに意味はあるのか？

71 ：

interfaceの考え方がピンとこなかった初心者が、デザパタを学んでなるほどと思う
またよろこばしからずや

72 ：

>>70
デザパタを学んだことで設計を学んだと勘違いしてしまうと、むしろ害があると思っているから
否定しておきたかったってのはある。
害っていうのは、本来はパターンを使わない方が自然であったり、使うべきでないところに無理やり
パターンを当てはめてしまうようなことがあること。
たぶんデザパタを学んだ多くの人は経験していると思うんだけど。
それを踏まえた上で勉強する分には構わないと思う。
代案を出せればいいんだけど、良い方法を自分も知らないから…。

73 ：

>>72
> 害っていうのは、本来はパターンを使わない方が自然であったり、
> 使うべきでないところに無理やりパターンを当てはめてしまうようなことがあること。
結局ね、実害がない限りそういうのもドンドンやってみるべきなんだよ。
そんでもって、学ぶ。どうまずいのか、どう不自由になっていったのか学ぶ。
そもそも、デザパタ単体で学ぼうとして挫折したやつ多く見た。
小さいサンプル書いてみたところで何が学べようか。
個々のデザパタが何をそれぞれ解決してくれるのかを学ぶには、
デザパタ適応以前の苦痛をしっておきたいところ。納得度が違う。
設計＆デザパタ＆リファクタでもんどりうちながら学ぶ。
いつでも学ぶ。いつでも臭い設計になっちゃうのでまた学ぶ。
悪い設計を目の前にして、右手にデザパタ本、左手にリファクタ本で学ぶ。

74 ：

きれいに実装されたテンプレートパターンなんて見たことねーよ。
単純に if 分岐で関数切り出しでもされてた方がよっぽど見やすいわ。
テンプレートパターンがうまくいくのは
「具体的には違う処理だが抽象的には同一の処理」の塊が
長く続いてるコードだと思うんだがそんな都合のいいシチュエーションって
そうそうないだろ。

75 ：

自分の経験を一般化しすぎるのはどうかと思うが
「俺は綺麗に実装されたテンプレートパターン見たことあるぞ」と言う奴がいれば根拠崩れるぞ
>>73
自分も同趣旨の事書きかけてたけどそっちの方が文章うまいね

76 ：

>>74
少なくともif分岐はないわ-
テンプレートパターンは、今は具象インスタンスから可変ポイントになるもののラムダを渡して実行って感じになってるがやってることは一緒。

77 ：

そもそもデザパタは局所的に使う物でしょ
「この部分は○○パターンでここのこの部分は…」みたいな
使える所があれば使えばいいし、出番が無いこともある
そういうものなんで、リファクタリングしながら適用するのはいいと思う

78 ：

色々アドバイスありがとう。
デザパタについては，浅く理解していると思う。
ただ，デザパタを実際の設計に結びつけれるほどは理解していない。
結びつけられるようになればレベルアップのような気がして，
まずはデザパタも含めて「良い設計」の実例を見てみたかった。
JavaのCollectionFramework参考にしたいと思う！
他にも何か良い例があれば教えて下さい。

79 ：

>>74
Template Method(の事だよな？)は、Straregyのように同一インターフェースだが、多くの実装のバリエーションがある場合に、骨格抽象実装(スケルトンクラス)として、よく利用している。
(つづく)

80 ：

例えば、呼び出し元からメソッドの最後で実行して欲しいコールバック関数が渡された場合に、
全ての末端のクラスでnullチェックして、実行って記述すると冗長なので、共通部分をスケルトンクラスに移管させ、
バリエーション記述のためにprotectedなabstractメソッドを用意しておく。
末端のクラスはこの抽象メソッドを実装するといった感じで。
これに限らず、「インターフェース ー スケルトンクラス ー 実クラス」という形は結構でてくるものよ。

81 ：

>>77
＞そもそもデザパタは局所的に使う物でしょ
デザパタに出てくるものってソフト全体に絡むと思うぞ。大きいものから小さいものまで。
その意見をとやかくいうのではないけど、そういう捉え方をする人がいる人にビクーリした

82 ：

デザインパターンを構成要素としてより大きなパターンが出来てるだけじゃないの？
アーキテクチャパターンとか聞いたことない？

83 ：

ぶっちゃけ言うとデザパタもアーキテクチャパターンも本質は同じだと思ってる。
両者を明確に区別すべき理由はないでしょ。

84 ：

コードから出てきたのがデザパタ
コード書かずに図を弄ぶのがアキパタ

85 ：

デザパタの
拡大解釈
やな予感

86 ：

リファクタリングを繰り返して物凄く汎用性高い設計
あまりレベルの高くないプロジェクトメンバーでも長期に渡って保守可能な設計
これらは両立しなくてどっちも大事だと思うんだけど，両方上達する方法ない？

87 ：

物凄く汎用性高い設計なんてものを、
まずお目にかかったことが無いｗ

88 ：

リファクタリングなんて必要なとき必要なだけやれば十分、汎用性なんて気にしなくていい
長期に渡って保守しておいてレベルの低いままのメンバーなんて切ればいい
下手糞が保守できるからいいソースとは限らない
→どっちも大事じゃない

89 ：

>下手糞が保守できるからいいソースとは限らない
ココロに響くお言葉

90 ：

せっかく保守・拡張しやすいように考えて書いたソースでも
それがわかんない人はどういう変更してくるかマジわからんし。
前の会社で、俺が設計・コーディングして、手を離れたやつに機能追加しようとした先輩がいてさ。
うまくいかないってソース持ってこられて（！）見てみたらコレが酷いのなんの。
俺「そこはサブクラス追加だけで良いですよ、そういう風に変えたら広範囲に悪影響あります、…（しばらく駄目出し）」
先輩「…全然駄目ですか」
俺「駄目駄目です」

91 ：

>>90
それは先輩もあれだが、正しくドキュメントとか残したん？

92 ：

設計思想ってのはドキュメント化しにくい上に工数認めてもらえないこと多くね？

93 ：

コメントで「〇〇〇パターン使ってます」って書いときゃ大体伝わる。
と思ってた時期が以下略　

94 ：

>>93
(ヾﾉ･∀･`)ﾑﾘﾑﾘ

95 ：

>>91
>92-94が正にそん時の状況を表してるw
一応、設計中に作成したメモ書きよりは上等程度のんは残してたけど。
まさか数キロステップ程度のプログラムで悩まれるとは思わんかったし、
彼もOCPとLSPが分かってたらやっちゃいけない事くらい分かったろうし…。
他にやる事あったのにそこまで面倒見切れんかった。

96 ：

そういうのは実際にコードを見てみないと何とも言えない
その先輩のようにOOに疎い人は確かに多いんだけど
自信ありげに語ってる側もまた酷いコードを書いてることが多い

97 ：

あるある。かなり、あるある。

98 ：

自信満々でコメントの一切無いソース見せられたことある
しかも変数名や関数名は母音抜き

99 ：

>>98
コメントはちょっと扱いが難しい。コメントが嘘をつくことがあるから。
つまり、コードの改変にコメントが追いつかないことがある。
コメント書かないほうがまし、と思うことが最近多くなってきた。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲