- PR -

デザインパターンって使いますか?

投稿者投稿内容
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2004-02-26 10:25
るぱんです。

デザインパターンは覚える時に有効な前提条件、無効になる前提条件まで含めて勉強して、
それをメモしていけば指針にはなるんじゃないですかね?

イキナリ実践で「このパターンにしたい」ってのは手順として間違ってると思うんですよね。
いかがでしょう?
ほむら
ぬし
会議室デビュー日: 2003/02/28
投稿数: 583
お住まい・勤務地: 東京都
投稿日時: 2004-02-26 10:31
ほむらです。
ちょっと言葉遊びのような感じになりますが。。。
-------
cloy氏へ
>>「***パターンにしたいんだけど、なかなか難しー」
>ですが、私の場合はオブジェクト指向設計、デザインパターンに関して理解が浅いので、
>学習の意味も含めて上記のような試行錯誤がどうしても必要になってしまいます。
試行錯誤するべき場所が違うように思います。
たとえば上記の例をあげるのならば
「****パターンを使いたいのだけどどんな機能を追加すればよいのかむずかしい〜」
とかだったら良いと思うのですけど。。。
すでにある機能に対して自分のエゴで使用するデザインパターンを決めるのは
やめたほうが良いでしょう。
これが、習慣づいてしまっては本末転倒ですよね。

デザインパターンの主語は常に機能であるべきだと思います。

#そういえばGoFとPAC以外のデザインパターンてあまり聞きませんね。。。
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2004-02-26 11:09
るぱんです。
追記みたいな物です。

「デザインパターンを使う際には根拠が要る!」
ってしばるともうちょっとなんとかなるのかなぁ・・・?
永井和彦
ぬし
会議室デビュー日: 2002/07/03
投稿数: 276
お住まい・勤務地: 東京都
投稿日時: 2004-02-26 12:51
引用:

るぱんさんの書き込み (2004-02-26 10:25) より:

デザインパターンは覚える時に有効な前提条件、無効になる前提条件まで含めて勉強して、
それをメモしていけば指針にはなるんじゃないですかね?



(広義の)デザインパターンは主に抽象レベルでの設計ノウハウ共有と考えています。
ので、当然
・パターンの名前
・パターンの目的
・パターンの概要
・パターンの適用条件、前提条件
・パターンの特性、注意事項
・例(クラス図、サンプルコード等)
くらいは必要ですね。これらを含んでようやく「デザインパターン」なのだと思います。
#間違ってもクラス図(と名前)だけで完結するものではないですね

出回っている分の注意事項に関する記載が足りないと思ったら、るぱんさんの仰るようにメモとして残していく等は必要です。
可能ならそれを積極的にコミュニティにフィードバックしていって欲しいと思いますが……。
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-02-26 14:46
はにまるです。
話がずれますが、
引用:

cloyさんの書き込み (2004-02-26 09:50) より:
経験を重ねて、デザインパターンは身に付いていくのかな?と思っていますが、いかがでしょうか?


デザインパターンを利用するまでの手順を考えた場合、

 1.「デザインパターン」の存在を知る。
 2.「デザインパターン」を勉強する。
 3.勉強中に摘要できそうな所を発見する。
 4.「デザインパターン」を摘要する。
 5.失敗する。
 6.模索する

になると思います。
開発で初ツールを試行錯誤して上達するように、
設計でも試行錯誤して上達します。

天才肌の人は別ですが、失敗する事、試行錯誤する事は、
上達する為に避けて通れない道と考えます。

「取りあえずやってみる!」は、良くある話ですし、
実際、大半の方が今持っている知識や技術は、
取りあえずやってみた結果、得た物が殆どの筈です。

引用:

永井和彦さんの書き込み (2004-02-26 12:51) より:
(広義の)デザインパターンは主に抽象レベルでの設計ノウハウ共有と考えています。
ので、当然
・パターンの名前
・パターンの目的
・パターンの概要
・パターンの適用条件、前提条件
・パターンの特性、注意事項
・例(クラス図、サンプルコード等)
くらいは必要ですね。これらを含んでようやく「デザインパターン」なのだと思います。
#間違ってもクラス図(と名前)だけで完結するものではないですね

出回っている分の注意事項に関する記載が足りないと思ったら、るぱんさんの仰るようにメモとして残していく等は必要です。
可能ならそれを積極的にコミュニティにフィードバックしていって欲しいと思いますが……。


↑この様な、勉強する前に知っておくと御得な情報は、先に出会えたらラッキーな話であって、
殆どの場合、苦労の末に知識を得るが多いと思います。
「は、、早くその情報をくれよ...」って事、多々あります。 

でも、それに気付くのには、やはり苦労は必要かも!
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2004-02-26 15:14
るぱんです。

最初にその情報を云々・・・って与えたところで使いこなせない人は
使いこなせないんですよね・・・。

話はそれますが、仕様書でそれやられてます。

仕様書のフォーマットとかそれだと思うんですけど、
大抵の人は「わかればそれでいいよ」

でも、形が決まらないと併せた形で作れなく、
最後まで「仕様書の書き方が悪い!」とごねられる物です。

やり直しつづけるしかないのかなぁ・・・?汗
永井和彦
ぬし
会議室デビュー日: 2002/07/03
投稿数: 276
お住まい・勤務地: 東京都
投稿日時: 2004-02-26 16:25
永井です。

引用:

るぱんさんの書き込み (2004-02-26 15:14) より:
るぱんです。

最初にその情報を云々・・・って与えたところで使いこなせない人は
使いこなせないんですよね・・・。

話はそれますが、仕様書でそれやられてます。

仕様書のフォーマットとかそれだと思うんですけど、
大抵の人は「わかればそれでいいよ」

でも、形が決まらないと併せた形で作れなく、
最後まで「仕様書の書き方が悪い!」とごねられる物です。

やり直しつづけるしかないのかなぁ・・・?汗



逸れた話を続けてしまいますが……
「わかればそれでいいよ」と「仕様書の書き方が悪い!」は同一人物の発言ですか?

同一人物(クライアント)の場合は

開発さん  「仕様書はどのようにいたしましょうか?」
クライアント「わかればそれでいいよ」
開発さん  「弊社フォーマットとして、このような形式をいつも使わせていただいて
       いますが、これでよろしいですね?」
(サンプルを見せる)
クライアント「うん。じゃ、この形式でお願いね」

……という感じで、もう前もって了承取るしかないかなと思います。1回テンプレートを作ってしまえば使いまわせるハズですので、きっちり時間枠を会社に貰って作ってしまいましょう。
「この形式で書きますー」と最初にサンプルを配れば、皆それに沿って作ってくれると思いますし、明確に方向性が示されるのでやりやすいと思いますよ。更に、毎回それならどんどん慣れていくと思いますし。
#テンプレート(/サンプル)がよっぽど奇怪なものでない限りは

そんなことはないとは思うのですが、「わかればそれでいいよ」が開発メンバーの発言、「仕様書の書き方が悪い!」がクライアントの発言でしたら、それは開発メンバーの「それでいいよ」を受けて手を抜いちゃった方の落ち度ですよね……。

スキルアップ/キャリアアップ(JOB@IT)