〔隔離〕ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝとは何か〔スレ〕

ﾊﾟﾀｰﾝ言語とは何か？
ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝを言い換えると何なのか？
という粘着議論を隔離するためのスレ

デザパタって定石みたいなものでない？
どうわかっていないのか聞きたい。

今後、新規に人が来て「デザパタは設計だろ？」とか聞いてきた時に、
また、「いや違う、定石だろ」だの、なんだのの話でループしてしまうと思うから、
その時にみんなが納得できるレスを返せるよう、この辺は明確にしておきたいんだけど。

>>2＝本ｽﾚ387さん

個人的には，デザインパターン＝「○○○」
みたいに置き換える必要はないと思ってます。

一方、例え話のようなものを他者に要求された場合は、
以下のようにしています。

「粘土で塑像するとき、粘土だけで積み重ねていくのもいいけど、
骨格があってそれにぺたぺた貼り付けていったほうが楽ですよね。
それに粘土だけだと作りたいと思っていた形にするのが難しい。」

「デザインパターンはその骨格に相当します。
あなたが作りたいと思っている造形（＝アプリケーション）に適した骨格選び、
その骨格に肉付け（＝実装）していくことで効率よく作業を行えます。」

「だたし、あなたが欲しているのは骨格ではなく、それを利用した完成形で
あることをお忘れなく。まるで粗探しをするように、
使えそうな骨格をかき集めることに夢中になる人もいますから...（以下続く）」

みたいな感じになってとても一言では終わりません。
で、やっぱりデザインパターンはデザインパターンでよいのではないかと...

>>3
「デザインパターン」を「フレームワーク」に置き換えたほうがしっくりくるな。

>>4
あー...その...
1つのたとえ話としておいてください。

>>4
禿同意。
この話もこれで終にしましょう、とか偉そうに言うくせに頓珍漢なんだよなー。

>>4
そんなレスつけるとこみると、本気で勘違いしてる。
とおもう。

デザインパターン≒骨格という例えは、よくありませんでしたね。
一つのアプリケーションに何個も骨格があることになってしまいますから...
視点が局所的になってました。

>>3
たとえ話はあんまり得意じゃないんだけど、あえて言うなら骨か？

骨を選んで骨格を作って（設計）、
その骨格に肉付けする（実装）って感じ？

デザインパターンをあえて言い換える必要はないとするのは同意。

>>8-9
デザインパターンそのものが、建築でいう江戸間関西間2X4を
ソフトの世界で使うように造語したもんだから、言い換え可能だよ。

高尚でも何でもないのに、高尚ぶりたがる奴が多くて、せっかくの
概念がだいなしだと思う。

>>10 それって言葉のせいかな？
例えば「定石」と言い換えたって高尚ぶりたい人は、そうするよ、きっと。
それに「デザインパターンを「○○みたいな物」って言い切っちゃうと、
その「○○みたいな物」から誤解が生じる可能性もあるしさ。

ってホントにやめないか？

>>11
はぁ(ため息)

やめるのは、君の方だってことが分らないのか？

俺ならMLで簡潔に書くんだけどね。

デザインパターン⊃フレームワーク
だと思うが。
いちいち噛み付くなよ。
話が逸れるにしても、もうちょっと紳士的な議論はできないのか。

俺ならMLでスマートに書くからデザパタなんか必要ないんだけどね

>>15
　>> http://pc8.2ch.net/test/read.cgi/tech/1119158274/312-319

こんな下の方でチマチマやらずに、
上の方で思い存分議論してよ

デザインパターンてのはな何種類かの定義がある。
一つは、プログラムすら組めない自称SEが、こういう一見先進的（？）な知識でもって、
さも時代についていっている人間かのようにアピールするためのもの。
「オブジェクト指向」に並ぶ常套句だな。ちなみに、所詮、付け焼刃なのでこいつらの話は何一つ的を射ない。

>>18
「何種類かの定義」と書いたなら、少なくとも複数の定義を書くべきかと

>>9
「骨」だとちょっとダサいから、「骨格の一部」ぐらいにしとけば？

>>18
20年遅れの厨房乙

すべてのデザインパタンを一度に説明できる設計資料ってないかな？

>>22
ない。別にデザインパターンって有限じゃないし。

＜デザインパターン＞
「デザインパターン」でも、なんでも良いけど、実践の結果を残してくれるのはあり難い。
へなちょこプログラマーだけど、本を読んだだけでレベルアップした感じになれる。
実践はあまり出来ないけどね。。。

>>24
意識して実践するのは難しいね。

デザインパターンを知って何がよかったかというと、
プログラミングする際に、よりスマートなモデルになるように試行錯誤した結果、
出来たコードの構造がとあるデザインパターンに合致しているのを発見できること。

んで、第三者に自分のプログラムの構造を説明する際に、
「このクラスとこのクラスがこういう関係で〜」みたいにごちゃごちゃ言うする代わりに
デザインパターンを使ってあっさり説明できること。

ちなみに、コードを書き始める前から、
「今から自分の作ろうとしているプログラムを表現するためには、
これこれのデザインパターンを適用するのがベストに違いない！」
なんて判断するのは無理ですｗ　よほど極端な場合を除いて。

>>25
なんか適当にコード書いてて、
「あ、この辺何となくxxxxパターンっぽいな、
　んじゃ本格的にxxxxパターンにしてみるか」
って感じたことがあって、
実際にコードをxxxxパターンに合わせて書き直してみると、
実にスッキリした良いコードになったことがありますた。

こういうことを何回も繰り返して行くと、

「今から自分の作ろうとしているプログラムを表現するためには、
これこれのデザインパターンを適用するのがベストに違いない！」

みたいなことが可能になるんじゃなかろうか。

俺はテンプレートメソッドパターンだけ、その有用性に驚愕した。で、使いこなせるようになった。
もち、シングルトンとかアダプターは普通に使ってたから、普通すぎて、有用性が感じられん。(もちろん、普通に使うが)
他のパターンは有用性を実感してないから、すぐに忘れてしまう。
有用性がわからないのに、本読んでずっと覚えておくなんて俺には無理だ。
他のパターンも知らずに使ってるかもしれんが、デザインパターン熱はとりあえず、２年前にさめたきりなので。

で、前のJAVAの仕事で、上司に俺はオブジェクト指向の初心者とか言われた。
その上司は継承が嫌いなので､俺が継承使っているのが嫌らしい。
なんでも、インターフェース派らしい。
俺は何でもバランスだと思っているので､もちろん、深すぎる継承は好まないが。

可読性、保守性もあるけど、
コミュニケーションのための用語として用いられるのも大きい。
これは木構造を表現するために再帰ではなく、
子のインスタンスを云々というより、
コンポジットパターンです、といった方が早い。

>>27
デザインパターンの存在意義をわかっていないようだね。
決して技術ブレイクスルーなどではない。
定型的な設計手法に名前を付けてエンジニア間の認識を共通化するものだ。
>>29 にはほぼ同意。

>>28
その上司がオブジェクト指向をわかってないんじゃないのか？
そもそも継承とインタフェースは本来違うもの。
どこかのドキュメントにある「Javaは多重継承できないのでインタフェースを使う」
なんてのは愚の骨頂。
継承はあくまで親子関係。
インタフェースは、親子関係にないオブジェクト同士に共通の振る舞いを持たせるもの。
オブジェクト指向的には本来こうあるべき。

インタフェースについては他にも
・マーカーインタフェース（Javaの例ではjava.io.Serializable等）
・仕様と実装の分離（オブジェクト間の疎結合化や実装の入れ替えが容易）
　（Javaでは、java.sql.Connectionとかjavax.servlet.http.HttpSession等）
等々の使われ方があるが、これはオブジェクト指向というよりも
実装上の都合でインタフェースという仕組みが利用されているに過ぎない。

visitパターンて、やり方によってはCommonsのCollectionUtilsで全てのコレクションに任意の処理を実行する、
と似ていないですか？

>>32
継承の親子関係って本来はどういうことの実現を目的にしてるんでしょうか？
子クラス群でのインターフェースと実装の共有みたいな感じ？
お暇なら誰か教えてくだはい

>>32 -> >>30
だった・・・あう・・・

・実世界の親子関係を表すため
・差分プログラミング

> ・実世界の親子関係を表すため
残念ながら実世界通りに親子関係を表せないことが多い
> ・差分プログラミング
実装の再利用はcompositeでやれ

・・・とか何とか言うのを聞くんですが、こういうのを聞いてると
>>28の上司は正しいの？とか思えてきます。
結局、継承の親子関係という考え方は、もともとの思惑通りには行かなかったけど、
まあ便利に使えることも多いし残しとくか、みたいな感じなんでしょうか？

そう正しい/正しくないと極論に走らなくても、状況に応じて一番よい設計を
するための選択肢の１つと思えばよいと思うんだけどね。

実世界のものを抽象的といえど、ソースコードというテキストで表現ですのには
限界があるのだと思うよ。

継承ってのはfriendの次に強力な関係なので、
気をつけて使わないと危険。
とりあえず継承はDPから逸脱した使い方をしていると、
アンチパターンに陥っていると考えた方が良い。

デザインパターンというのは、ある一定以上の能力・経験を持った人が
プログラミングをする場合にプログラム上に（ある程度頻繁に）出現する部分的な設計パターンだから、

デザインパターン　＝　ある程度効率的と分かっているプログラムの部分的な設計方法


やっぱり将棋の定跡という言葉が一番近いと思うな。
定跡（デザインパターン）だってそれがその局面で最善手とは限らないし、
全体の流れ（プログラム全体の構造）を考えた上でどの定跡（デザインパターン）を
使うかどうか決めるわけだから。

フレームワークとは明らかに違うね。
フレームワークは（設計の）手法じゃなくて道具でしょ。

定跡を知らなくても強い人は強いけどねｗ

その強い人は定跡とは知らずに定跡を使ってるだけ。
強い人のそれらの手法をまとめたのが定跡（デザインパターン）なんだって。

どうでもいいけど、スレタイが
〔隔離〕ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝと何か〔スレ〕
に、見えた

１ヶ月放置されてるとは・・・

>>42
実務における有用性の限界を正しく認識出来てきたからさ。

正直難しいというイメージしかない・・・


もっと勉強せねば

>>35
その通りだと思う
親子関係の継承は今時流行らない

TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

そういや64bitにネイティブ対応している２ｃｈブラウザてありましたっけ？

>>30
>どこかのどこかのドキュメントにある「Javaは多重継承できないのでインタフェースを使う」
なんてのは愚の骨頂。

そうそう俺も最初これに結構だまされたなー。
今ではインタフェースのほうが継承よりも重要に感じるな。
多態にしても親子関係で考えるよりインタフェースから見たほうがわかりやすい。

Ｃ++でオブジェクト志向身につかなかったのに、ＪＡＶＡ経由してＣ++に戻ってきたら
格段に見通しよくなってたな。それもインタフェースがＪＡＶＡの言語仕様で明確に
定義されてたおかげだと感謝してる。

そうかそうか。よーくわかったぞ。

ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝの勉強をするのは、ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝを理解してからでいいんじゃん？