[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 16:54 / Filesize : 288 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

〔隔離〕デザインパターンは本当に必要か?〔スレ〕



1 名前:デフォルトの名無しさん mailto:sage [2005/06/21(火) 19:09:56 ]
そもそもデザインパターン自体どうなのよ?って話はここでやれ。

683 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 13:37:45 ]
>>679
お前何才よ?ロートルプログラマか?w
年取りすぎて会社じゃもうどこも雇ってもらえないから、家で妄想の毎日か。

684 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 14:40:13 ]
>>683
679じゃないけど、結構あるよーこういう現場。
まだ679は新旧混合で選択しようってんだからいい方だよ。

685 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 14:47:14 ]
フローチャートはちとキツイ。
あれはホントにお絵かきで終わっちゃうからなぁ。

PAD図だったらプログラムの構造が保たれているからまだマシなんだけど。
# でも実際には使ってないけどね。

UMLのクラス図なんかもリバースエンジニアリング出来ないとお絵かきで終わっちゃう。

686 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 19:22:49 ]
フローチャートって、ループすらマトモに書けないじゃん

はっきり言ってアセンブラならまだしも
今時の高級言語なら、フローチャートに落とすことによって
何かがわかりやすくなったりすることはありえない


687 名前:681 mailto:sage [2005/06/29(水) 20:35:12 ]
まあ、機械語を扱う部分で出てきたんで、何とか我慢できるんですが……

C で PAD を教えてきた先生も居たけど、ぶっちゃけ PAD だと関数出てきたあたりからお手上げ状態
構造化チャートは、オブジェクト指向まで考えるともう使えないでし


折角なんで愚痴らせてもらうと

 ハード系の某先生「これからは最低でもオブジェクト指向が出来ないと」

んで、出てきたのがコレ

 class Sample {
     public void input(String filename) { /* filename で指定したファイルを読み込む */ }
     public void process() { /* input で読み込んだデータを処理 */ }
     public void output() { /* process で書き換えたデータを表示する */ }
 }

……まあ、若い先生方にはしっかりした人が多いんで、まだ救いがあるんですが OTL

688 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 21:44:54 ]
>>679
結構同意。


689 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 22:22:42 ]
構造化もOOもデザパタも勉強してみると実は現場で似たような事やってた
ってオチがままある

690 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 01:12:18 ]
>>679
状況によっては古い技術の方が、効力を発揮したりするしね。
色々な知識を持って、あらゆる状況に対応できることが大切だと思う。

691 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 01:27:38 ]
>>689
Cで構造体のメンバとして関数ポインタ持たせて
偽多態みたいなのは良くやるが、
クラスや継承までエミュレートしたことはないなあ。
後、構造体の先頭レイアウトだけ合わせてポインタ渡しとかはありがちだな。

なんかOOというより苦し紛れのテクニック、という気分もするが。



692 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 01:30:06 BE:84286962- ]
>>691
Cしか使えない現場なの?

693 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 01:37:35 ]
>>692
少なくとも俺が入社したころ(そんなに昔ではないのだが)は
Windows3.1、VC++1.0が現役だったし
C + SDKで組まれてるプログラムが珍しくなかったんですわ


694 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 01:39:02 ]
あと、apacheのモジュールみたいなso作ったりとか、
その手の仕事はCが普通じゃまいか。
別に制御屋さんとかじゃなくてもC触る機会、結構あるでよ。

695 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 02:03:20 BE:42143832- ]
なるほど、昔の話か。今となってしまっては
よほど速度や資源を求めない限りはCオンリーは嫌ぽ。

# apacheのsoはよくわからんす。

696 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 02:19:55 ]
>>695
apacheのモジュールは、いわゆるプラグインみたいなもんだす。
soはshared object(library)、いわゆるDLLね。

アプリじゃなくてDLL書く場合はCで書くことは珍しくないと思うよ今でも

697 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 02:28:33 ]
>>696
DLL書く場合でもC++のが楽でいい。

698 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 02:32:47 ]
>>697
C++だとスタートアップコードが必要になったりしてちょっとヤじゃない?
もともとC++用のDLLならいいけれど

Cインタフェースを公開するDLLなら、Cで書いて、しかもlibcに依存しない
形にしたい

699 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 08:39:28 ]
Cしか使えないならCを使うけど、積極的に使おうと思うものじゃないよあれは。
一刻も早く地上から消え去って欲しい。

700 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 09:42:29 ]
>>699
Cと一緒にお前も消えろ。

701 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 14:20:49 ]
なんでもデザパタに当てはめないと設計できなくなったら終わりだな。
というか、あーでもない、こーでもないって、
ころころ設計変えるのが、楽しいのに。
漏れの楽しみ取らないでくださいよ。



702 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 14:36:11 ]
>>701
いもしない人間を想定して適当なことを言うのはやめましょう

703 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 15:11:34 ]
>>687
学生時代、pad2psというソフトをつかってソースからPAD図生成してました。
レポート書くのに助けられたなぁ・・・今は使ってないけど。

704 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 21:03:09 ]
いくらJavaやC#でオブジェクト指向だなんていっても、メソッドの中では構造化の知識がいるだろ。
5行で終わるようなものを50行ぐらいかけてなにやってんだか分からないようなダサダサソースはうんざりするでしょ。

705 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 21:17:37 ]
構造化分析と構造化プログラム設計と構造化コード

706 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 01:45:06 ]
>>699
それはCも使えてないってことだろ。


707 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 02:00:07 ]
今からここはCの素晴らしさを褒め称えるスレになりますた

708 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 09:37:08 ]
>>706
じゃあおまいさんはC++もjavaもC#も使えるような環境において積極的にC言語を選択するか?

709 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 10:05:40 ]
たいていの言語はC言語やC言語のライブラリが土台になってるから消え去ってもらっては困る

710 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 17:07:33 ]
>>708
1)shell等の外のプログラムから部品として呼び出すことを想定したコマンド・
 フィルタ風のプログラムなら、少なくともJavaやC#は「絶対に」使わない。
 ツールボックスアプローチの部品としては、起動遅いのは致命的。

2)C向けのDLLは大抵Cで書くな。
 libc使ってしまうと、クライアントコードとlibcのバージョン合わせる必要が
 生じてウザい。これ、Win32の話ですが。

3)俺は書かないけど、オープンソースでなるべく広い環境で使われたいと願う
 コードを記述するなら、Cのが今でも多いだろ。環境をそもそも特定できない
 から、だが。


711 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 17:09:10 ]
>>710
なるほど。そうかそうか、よーくわかったぞ。それは面白い考えだ。



712 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 17:28:26 ]
>>711
せっかく真面目に答えてやっとるのになんだ、その人を小ばかにしたような
態度は。それで優位に立ってるつもりなのかね、チミは。
反論があるならもっとマジメにやれ。

713 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 18:14:36 BE:70239252- ]
C++でDLL作ったことないので深く突っ込めないんだけど、
インターフェースはCで提供して、
実装はC++ってのもやっぱ無理ですか?

714 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 18:19:01 ]
>>712
だってお前の意見になんか全然興味ないもん。

715 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 18:33:41 ]
>>713
可能か不可能かといえば可能。extern "C"すればいいだけだから。

716 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 18:34:20 ]
>>714
なら下らん一言でスレ汚さずに単にスルーしろよ

717 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 18:39:47 ]
>>716
うるせぇーよ。ぼけ、氏ね ( ´∀`)

718 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 18:46:30 ]
そういえばツールボックスアプローチってデザパタ厨的にはどうなのよ

719 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 19:27:28 BE:70239825- ]
>>715
それでも>>710の言うようなlibcのバージョン合わせる必要ありますか?

>>718
嫌いじゃないが。

720 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 20:36:27 ]
>>718
OOPな時点でツー〜ーチなん違うん?

721 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 20:46:21 ]
>>719
libcのバージョンは、合わせる必要はある。Cを使おうがC++を使おうが
関係ない。Cの方がlibc非依存にしやすいというだけ。

たとえばDLLが(VC++6以前の)MSVCRT.DLLを利用しているならば、
クライアントプログラムもMSVCRT.DLLを用いなければならない。

ま、実際には合わせなくとも動作する場合もある。DLLのインタフェース
や何やってるかによるんだが。
ファイルポインタ、ファイルデスクリプタ、ロケール、errnoのような
CRTオブジェクトの受け渡し、あるいは一方でmalloc()したメモリの
他方でのfree()、といったことをやる場合は、バージョン合わせないと
完璧にマズい。




722 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 21:05:28 ]
>>720
UNIXのツールボックスアプローチってのは、シェルという糊言語を用いて、
部品になる小さくて独立したプログラム群を組み合わせることで
仕事を実現する手法のことなんだが。

プログラムが分かれてるから完全に疎結合。で、標準入出力、パイプ、
コマンドライン引数、戻り値といった単純でwel-definedな仕組みを用いて
それを組み合わせていく。

概念的にはOOとは全く関係ないし、Smalltalkとか見ても、OOはむしろ
モノリシックで巨大なものを指向する傾向があるんじゃないか。
むしろLISPに似ているというか。

723 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 21:17:37 ]
>>722
>概念的にはOOとは全く関係ないし

疎結合という面と、独立したプログラムという面から見て、オブジェクト指向に通じる物があるかと思ってた

724 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 21:20:50 ]
>>722
クラスは>>722の中段で書かれてる要素を全て満たしてると思う。
「である。」とは思わないけど、「の様な振る舞いを持たせる事もできる。」と思う。

725 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 21:53:44 ]
Javaで実装されたシェルもあるね、実用上は使い物にならないと思うけど。
コマンドパターン風に実装したクラスがプログラムのかわりで、
それを実行時ロードとかまあそんな感じかな。

726 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 21:58:22 ]
本当にそんなんなのか?

727 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 22:02:59 ]
>>726
すまん大して興味が無いのでちゃんと見てないんだが

要するに、コマンド実行するたびにVMロードされちゃたまらんワケで、
同一VM上でコマンドを実行するのが、Javaで「使い物になる」シェル風の
環境を作る大前提。
find . -name '*.html' -exec rm {}
とかそんなことをやると、それこそうんざりするほど大量の子プロセスが
生成されて実行されるのがシェルの世界だからな。

その辺は、antのタスクの考え方と同じ。要するに、インタラクティブに
実行できてmake作業に特化してないant+αみたいなもんじゃないかな。


728 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 22:11:51 ]
tclとかはシェル風のごく単純なグルー言語+コマンド関数の世界だが
あれはCで書かれてるから、Javaみたいに実行時ロードできないんだよな

ってどんどんスレ違いの世界に

729 名前:719 mailto:sage [2005/07/01(金) 23:46:32 BE:210717465- ]
>>721
なるほど、ありがとん。たぶん将来とても役立つ知識になった。

730 名前:スレ違いですが [2005/07/02(土) 01:06:25 ]
Javaベースのシェルかぁ。

・こんなんあったね。漏れも一個くらいはインストールした覚えがある。

JDistro jsh : A Un*x-lke shell written in pure Java. Java Web Start対応
  www.jdistro.com/jsh/

COLLIN Gerard's jsh: the opensource java application launcher ! Java Web Start対応
  gerard.collin3.free.fr/

TeaShell: 複数のJavaアプリケーションを一つのJavaVMで動かすJavaシェル
  www.vector.co.jp/soft/other/java/se089271.html

・その他国内某所で Java シェルOS開発というスレが立ち上がってるのを発見したんだけど、
 そこの1、一体何作ろうとしてんのか、よくわかんないや(OSによらず使い慣れたシェル環境を提供するって何?)

・JDK1.6では、Oracle JavaVM流のapplication partitioningの仕組みが導入されるそうなんで、
 JavaVMプロセスを多数起動しなくても、いろいろな事がやりやすくなるね。(本来はAppServer向け機能だけど)

731 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 01:17:07 ]
>>730
少なくともこのスレと関連のあることをいってくれないと。
リンクの貼り付けだけだと荒らしに見える。



732 名前:本スレ住人 mailto:sage [2005/07/02(土) 04:01:40 ]
わるいね。
UNIXシェルとコマンドによる祖結合プログラミングは、
デザインパターンと並んでソフトウェア工学上重要な話題です。

Javaにおいてどのような試みがなされているか、
そして、Javaサーバ〜Webサービスの基盤 (アプリケーション・パーティショニング)が、
UNIXシェルの基盤にもなりうる、という話題を振ったつもりですが。
もしかして、ここは似非スレだから、似非話題以外はスレ違いなのかな(藁

733 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 08:27:03 ]
>>730
>OSによらず使い慣れたシェル環境を提供するって何?
OSによるshellの方言を吸収しようという意味じゃないすか。

734 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 11:19:11 ]
>>732
>デザインパターンと並んでソフトウェア工学上重要な話題です。
だから何?スレ違いに変わりない事に気付けよバカ。

735 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 12:29:02 ]
>>734
気付いてないのは恐らく君だけ

736 名前:デフォルトの名無しさん [2005/07/02(土) 13:17:27 ]
>>732
早く本スレ帰ればいいじゃん。
過疎スレ帰れよw
#デザパタなんてどうせやってる奴いないからこないだろうけどwぷw

>>731>>734は別人ね。俺は>>731



737 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 14:58:05 ]
本当に隔離スレだな
どうでもいいレスでageてるし

738 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 15:56:53 ]
糞な香具師だらけだから、糞スレになるのは当たり前

739 名前:デフォルトの名無しさん [2005/07/02(土) 16:17:40 ]
>>737-738
じゃあ、早く本スレ帰んな。

740 名前:デフォルトの名無しさん [2005/07/02(土) 16:18:59 ]
ω日本のハッカー、今立ち上がれ!!!!
pc8.2ch.net/test/read.cgi/pcnews/1120271067/

また中国です。

741 名前:152 [2005/07/02(土) 16:23:42 ]
>>740
 そんなことしてる暇あるならコード書けってかんじだよなぁ



742 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 16:44:15 ]
>>740
それ、東アジアニュース+でガイシュツだよ。
中国と韓国からのケーブルは切断しなきゃダメだね。

743 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 17:20:28 ]
Javaで動くシェル作るぐらいなら、オールJavaのOS作れ。

744 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 19:21:30 ]
>>740
なんつーか、どっちも死ねよと。

745 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 21:52:29 ]
…………… く ず れ す ……………

746 名前:デフォルトの名無しさん mailto:sage [2005/07/03(日) 18:40:06 ]
プログラム板が荒れているため、IDを導入するか検討中です。
賛成の方も反対の方も、このスレで自分は賛成か反対かをお書きください。

プログラム技術板に強制ID制を導入すべきか否か
etc4.2ch.net/test/read.cgi/vote/1118144381/

理由などの記入は別に構いません。
<<賛成>>か<<反対>>かだけ御記入頂ければ結構です。
ちなみに、当たり前ですが運営の方にIPが見えているので、1日ごとにIDが変わるからといって多重投稿しないでください。

747 名前:デフォルトの名無しさん [2005/07/10(日) 14:08:52 ]
本スレが伸びてると思ったら、
ここに粘着してた頭のおかしいデザパタ信者が集中砲火浴びたっぽいなw
いつも都合の悪い話題が出ると自分の発言を軌道修正するから
あいつ嫌われるだろうなと思ったら滅多撃ちにされてるなw

748 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 14:35:43 ]
伸びてるも何も2005/07/08(金) 12:50:07から書き込みがないぞ?

749 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 16:25:41 ]
>>748
いや、向こうのスレで

2005/06/23(木) 23:12:19

周辺から糞化してたから見て無かったんで・・・

750 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 16:28:28 ]
>>749
つか、あのスレ自体、信者vsアンチの構図が無くなった時点で全く意味がない。
デザパタ自体は誰も仕事でなんか使ってないから、デザパタ自体のことを語るのはおもしろくない。

751 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 17:21:15 ]
バカ粘着スレ

仕事してる俺たちゃ、
あんたみたいな無職野郎と違って
暇じゃないのよ



752 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 20:26:09 ]
>>750
J2EEアプリやったことがないのに
> デザパタ自体は誰も仕事でなんか使ってない
なんて断言するなよ。無知丸出し。

753 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 20:33:18 ]
J2EE だけじゃないんですが

JavaAPI のレベルでも、既にパターンを見つけることも出来るんですが

754 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 20:42:17 ]
>>753
APIで使われているかどうかじゃなくて、自分が作成するアプリの設計に適用するかどうかを言ったつもりだった。
まあ、ヤツはJavaすらやったこと無いんだろうけど。

755 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 20:53:25 ]
>>754
ああん了解

756 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:04:29 ]
ファクトリやストラテジ、アダプタなんかは趣味グラムでも多用するぞ。
もっとも、趣味グラムの場合、単に完成を急ぎたいからそうするだけな
んだけど・・・・・・要はcommons-loggingの悪用と同じ。

詳細決まってないとこは空箱でも詰めとけw

757 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:06:19 ]
> デザパタ自体は誰も仕事でなんか使ってない

誰もというのは言いすぎだが、ほぼ正しい。

1.使ってないやつ 70%
2.使ってプロジェクトに混乱を起こすやつ 25%
3.正しく理解して設計に応用するやつ 5%

もちろん俺は3

758 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:09:59 ]
ネタスレだから、低レベルな奴しか居ないというのには同意。

759 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:13:49 ]
JAVA前提の職業プログラマに限れば
1.使わされてる奴:70%
2.使わせてる奴:20%
3.( ゚д゚)ポカーン:10%

もちろん俺は1orz

760 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:20:25 ]
「知らずに使ってる奴」も居る筈

761 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:27:59 ]
>>760
大規模プロジェクトでは「知らずに使われてる奴」は多そうだね。



762 名前:デフォルトの名無しさん mailto:aoru [2005/07/10(日) 21:38:19 ]
デザインパターンなんて基本的に不要でつね。
継承、多態なんてまずは使わないで設計できるかを考えるべき。
その上で、どうしようもない場合は、継承、多態を使う。
で、継承、多態を使う場合も、基本的なTemplate Methodとかはともかく、
基本的にデザパタは使わないで設計を考える。
それでも必要の時だけデザパタを使うと。
極力シンプルを目指して、リファクタリングをして、継承、多態を減らすと。
つまり、デザパタは基本的に不要!

763 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:41:19 ]
>>762
>どうしようもない場合は、継承、多態を使う

「構造が簡潔になる場合は〜」 に訂正して欲しいこと以外は同意

764 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:47:17 ]
デザパタは認めないのにリファクタリングはOKなんですか?

765 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:48:27 ]
>>762みたいなのは、コンテナ依存のコンポーネントのモックテストなんてやったことないんだろうな。

766 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 22:42:49 ]
さすが隔離スレだな。
1987 OOPSLAのGamma以前のレベルで進化が止まってるわ。
>>765
あんたもデザパタなんて保守的な事言わず、J2EEパターン、.NETパターン、PoEAAにESBって
どんどん話題振らなきゃ。

767 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 22:53:18 ]
>J2EEパターン、.NETパターン、PoEAAにESB
それらはデザインパターンとは呼ばないのか?

768 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 22:54:37 ]
「デザイン」 の 「パターン」 ならば 「デザインパターン」 なんだろうな

769 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 22:57:07 ]
www.microsoft.com/japan/msdn/practices/Type/Patterns/enterprise/
によれば、パターンの適用範囲はデザインだけではないね

770 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 23:08:00 ]
>>767
一応、口ではそんなんデザパタに含んでると反論するが、
実際のパターン名はシングルトンにファクトリー、テンプレートメソッドくらいしか出てこないのが、
隔離スレ・クオリティ(藁

771 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 01:10:18 ]
本スレもそうだけど、君ら自慢と煽り合いが大好きね('A`)
議論を持ち出せば「お前、レベルが低い」とか、馬鹿だなんだと罵り、
どこのサイトのなんの記事を熟読してから書き込めなどといって書き込み排除。
別にいいじゃんレベル低かろうが。

もっと気軽な議論スレがほしい。
正直この状態じゃ何も議論できない気がする。
デザパタ初心者スレでも建てっかな。



772 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 01:11:57 ]
そしてまた増えるデザパタスレ(過疎)

773 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 01:13:16 ]
>>762
デザパタ => オブジェクト指向
に変えても読めてしまう。

そういうことですか?>>762

774 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 01:35:37 ]
>>771
>正直この状態じゃ何も議論できない気がする。
お前の脳みそはまだそんなこと考えてるのかとw

>>757
>3.正しく理解して設計に応用するやつ 5%
これは嘘。
5%もいるわけない。
デザパタはネタ。
実際のプロジェクトでは使ってるところは存在しない。

775 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 01:37:22 ]
>>771
何のための隔離スレだかわかってる?

776 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 01:43:27 ]
> 実際のプロジェクトでは使ってるところは存在しない。
そんなわけない。
俺がいる会社でも使ってるし、知り合いのいる会社でも普通に使うし。
ホントに無知だな。かわいそうに。

777 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 01:56:08 ]
>>775
はじめはアンチだけをここに隔離する目的だったんだけど、
アンチがいなくなったら本スレが過疎スレになっちゃったから今となっては微妙一色w

折角、隔離スレとしてアンチ同士で楽しくやろうと思ってたのに
本スレが過疎スレになったから信者がこっちにまできて非常に邪魔。

はっきりいうけど、本スレが盛り上がらないのは、
本当はデザパタなんて誰も使ってないから、話す話題がない。

技術としても不確定で誰が正しくて間違っているか特定させる手段が無いから、
パターンブームにのってエセ研究者気取りがいいたい放題。

議論も「いかにして相手を言い負かすか」が焦点になっててまったく本質に触れようとしない。

>>776
君こそ、知らないの?
デザパタなんて狭い世界の話なんだよw

778 名前:デフォルトの名無しさん [2005/07/11(月) 01:56:48 ]
>>776
そんなにいうなら本スレ盛り上げてきてよw
ま、誰もこないだろうけどさw

779 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 02:10:51 ]
>>777
「存在しない」から「狭い世界」へ修正ですか?w
次は「特定の分野では使われている」に修正して
さらには「○○では使われていない」に修正ですか?
どこかの議員さんみたいですね。

780 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 02:11:39 ]
>>778
だって、使って当たり前、使われ方もほぼ決まっているのに何を今更議論するのさ?


781 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 02:13:08 ]
>>777
> はじめはアンチだけをここに隔離する目的
ちがうだろ?
デザパタが必要か要らないかの議論をするのがこのスレの目的。
本スレはデザパタありきでの議論が目的。



782 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 02:37:38 ]
本スレが寂れたのは、頭がおかしい人物が荒らしまくって、良心的な人々を遠ざけたから。
荒らし風情がひらきなおるんじゃねぇ〜よ、クズめ

783 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 02:40:48 ]
>>771
某スレで、またぞろakon叩きするバカが発生してたけど、
あんたらのコミュニティは一体どうなってるの?

784 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 02:47:10 ]
未だにパターンに無理やり当てはめて類型化することをパターンを使うと表現している人がいるのか

785 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 02:59:15 ]
おまいはすっこんでろ

786 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 03:10:49 ]
>>784 はほとんど宗教じみているな

787 名前:デフォルトの名無しさん [2005/07/11(月) 03:14:46 ]
GHGH

788 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 03:36:40 ]
>>771
そーゆー前向きな活動は本来、
ML上で署名付きで行うべきものではないか?
その署名が偽りであったとしても、誰も気付かないのだし。

匿名掲示板で本音のぶつかり合いを期待するのは、
虫のいい考えだと思う。blog立てろよ(オレモナー


789 名前:788 mailto:sage [2005/07/11(月) 03:43:05 ]
特に2ちゃんは、平日昼間から深夜まで例の粘着が
 ・情報システム板
 ・プログラム技術板
 ・プログラマー板
 ・ゲーム製作板
 ・セキュリティ板
 他
を常時巡回して荒らしをやっているんで、
多くの人が、ここではもうコミュニケーションが機能しないものとして見放している。

考えても見ろよ、あれだけあちこちで話題になっているRubyのスレが
この板に一個もない。原因は何故だと思う?
例の粘着とおぼしき人物が「Rubyキチ」とかいうコテハンで何年もしつこい荒らし行為を行って、
さすがのMatzも手を引いたからだ。

こんなゴミタメで、鬱憤晴らしと気まぐれな独り言以外、何ができようか?
なんちゃって

790 名前:788 mailto:sage [2005/07/11(月) 03:46:34 ]
>>771
ちょっと考え直してみたら、俺もよくわけの判らんレスを付けてしまった。
貴方が「気楽に議論できるデザパタスレが欲しい」と思うのなら、立てたらいい。
掲示板のスレ立て制限以外、誰もスレ立てを制限する事などできないのだから。

791 名前:デフォルトの名無しさん [2005/07/11(月) 07:20:45 ]
>>780
その割には本スレで馬鹿と盛り上がってたじゃんw



792 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 07:39:21 ]
馬鹿はどこにでもいるし、どうしようもない議論で盛り上がるさ。
こっちでもあっちでもまともな議論はできていない。

793 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 07:48:40 ]
>>792
>こっちでもあっちでもまともな議論はできていない
まともな議論なんて無駄。
デザパタ自体の存在意義について触れた時点で荒らしがはじまる。

794 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 08:24:22 ]
きっと、役立たずの人間にとっては、
世の中に役に立つ概念があるというだけで、
腹が立つんだろうね(藁

795 名前:771 mailto:sage [2005/07/11(月) 14:41:48 ]
>>790
新しいスレ建てるほどのことではないんだよね。
ほぼ重複だし。叩かれそう。なのでやっぱりいいです。

>>792
馬鹿でも、どうしようもない議論でもいいじゃないか。
そこをおまいのような理解してる奴がうまく啓蒙してあげればいいんじゃないか

>>793
まあ馬鹿同志、無駄な議論してるんで生暖かく見守っててくだされヽ(´ー`)ノ

796 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 14:55:10 ]
こっそりとID導入待ち

797 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 15:11:19 ]
IDが必要なのはこのスレだけだろ。他の板逝ってやれ。
他の人が迷惑する。

798 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 15:28:47 ]
プログラムに関係ないことをプログラム板以外でやれと?どっちが迷惑だか。

799 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 15:30:24 ]
プログラムのことを、だ。

800 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 16:53:59 ]
じゃあ、ID出てしかもコテハン専用のプログラム板作ってもらえよ。
お前のルールに他の人間を全部従わせるつもりか。カス。

801 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 17:03:49 ]
クオリティ低いな



802 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 17:41:48 ]
>>797
>IDが必要なのはこのスレだけだろ。
そうでもない。

803 名前:デフォルトの名無しさん [2005/07/12(火) 23:36:08 ]
隔離スレに来てる肯定派のアフォども、元気か。
本スレ盛り上げろよな。まあ、おまえらアフォどもには無理だろうけど。

804 名前:デフォルトの名無しさん mailto:sage [2005/07/12(火) 23:45:43 ]
必要って言うか、なんていうか。
こんなやり方あるんだね、みたいな。そんな軽い気持ちで使えばイイんじゃねーの?
ほとんどの場合でそのまま使えねーんだし。

805 名前:デフォルトの名無しさん mailto:sage [2005/07/13(水) 00:21:37 ]
>>803
お前ほどアフォではない。残念。

806 名前:デフォルトの名無しさん mailto:sage [2005/07/13(水) 00:24:52 ]
>>803
おまいほど暇人でわない

807 名前:デフォルトの名無しさん mailto:sage [2005/07/13(水) 00:35:21 ]
>>803
元から話題が無い(涙

808 名前:デフォルトの名無しさん mailto:sage [2005/07/13(水) 00:41:35 ]
>>807
まぁ話題がない、などと言う奴は中身からっぽなんだろうが。
Martin Fawlerの一連の著作やら、DSLやMDAとの絡みやら、
設計レベルのパターン言語について語るべき事はたくさんある。
問題は、書き込みが少ないこと。

809 名前:デフォルトの名無しさん mailto:sage [2005/07/13(水) 00:42:58 ]
Fowlerな。
あと、書き込み少ないって、某荒らしが粘着してるネタスレと比較しての話だ。
某荒らしが一切書き込みをやめてくれれば、また盛り上がれるスレだと思うよ。

810 名前:デフォルトの名無しさん [2005/07/13(水) 01:16:57 ]
>>805-809
やはりお前らアフォどもに本スレを盛り上げるのは無理ってことだな。
隔離スレで内容のない話をしてろ、アフォども。

811 名前:デフォルトの名無しさん mailto:sage [2005/07/13(水) 02:14:11 ]
>>810
勝利宣言か。本当に日本人ですか?



812 名前:デフォルトの名無しさん mailto:sage [2005/07/13(水) 23:08:14 ]
盛り上げるもなにもデザパタ使ってる奴なんてハナっから存在しない。
信者だって本当に実在しているのかも疑問。

813 名前:デフォルトの名無しさん mailto:sage [2005/07/14(木) 11:18:53 ]
>>812
>デザパタ使ってる奴なんてハナっから存在しない。
という事にしないと、理解できない自分がカワイソス、と。

814 名前:デフォルトの名無しさん mailto:sage [2005/07/14(木) 11:40:11 ]
井の中の蛙もいいところ

815 名前:デフォルトの名無しさん mailto:sage [2005/07/14(木) 12:57:25 ]
こないだつかった。

816 名前:デフォルトの名無しさん mailto:sage [2005/07/14(木) 20:00:39 ]
俺なんか飯のときにも使ってる

817 名前:デフォルトの名無しさん mailto:sage [2005/07/14(木) 21:14:38 ]
>>815
シングルトンはもういいってw

818 名前:デフォルトの名無しさん mailto:sage [2005/07/14(木) 21:44:28 ]
>>817
君がそれしか知らないのは判ったから。

819 名前: != 815 mailto:sage [2005/07/15(金) 00:47:16 ]
>>817
このスレの住人ってくだらない煽りヤロウばっかりだな('A`)

820 名前:808 mailto:sage [2005/07/15(金) 01:30:19 ]
同意。つか、これが例の情報システム板のスレでバカなレスばかり付けている「出張32」ですよ

821 名前:デフォルトの名無しさん mailto:sage [2005/07/15(金) 07:45:18 ]
>>819
オマエモナーw



822 名前:819 mailto:sage [2005/07/15(金) 09:59:55 ]
>>820
いや、あの、きみの>>808の一行目のレスするあたり対してレベルが変わらない気がス('A`)
きみのその一言がなければ、おお。とか思った。思われただろうに。
つか、>>820自体のレスも対してレベ(略

>>821
(゚∀゚)オウヨ!!

823 名前:デフォルトの名無しさん mailto:sage [2005/07/15(金) 11:06:37 ]
>>817
Abstract Factoryでした。
まあこれも使いやすい方なので
じまんにはならんでしょうけど!

824 名前:デフォルトの名無しさん mailto:sage [2005/07/15(金) 14:35:21 ]
>>821
釣られて出てくる「くだらない煽りヤロウ」。

825 名前:デフォルトの名無しさん mailto:sage [2005/07/17(日) 18:36:19 ]
ふと思い立ったんだが、アンチデザパタさん達の中でも、
interpreter パターンを知らずに使ってる人は意外と多いかもしれない

なにせ、
  Window_X = 120
  Window_Y = 100
とかの初期化用スクリプト組んで、config.ini って名前付けるけでも interpreter の思想は受け継がれているからな

【この程度の事で interpreter パターンなどと勿体ぶった言い方を俺はしたくないですが】

826 名前:デフォルトの名無しさん mailto:sage [2005/07/17(日) 21:32:52 ]
>>825
お前は本当になにもわかってねぇウンチングスタイルだな。

827 名前:デフォルトの名無しさん mailto:sage [2005/07/17(日) 22:26:33 ]
はぁ。インタープリタ・パターンねぇ。
再帰下降型パーサなら簡単に書けるけど、
正規表現のように状態遷移マシンつかったり、
JavaやCのようにあるていど大きな規模の構文を効率的に扱うには、
ちょっと寸足らず・・・
つか、実装は別の方法でやって、表面的なインタフェースはinterpriterパターンといったところか。

ってGoFがゆってた

828 名前:825 mailto:sage [2005/07/18(月) 18:30:54 ]
っていうか interpreter パターンって
『処理内容のハードコーティングを避け、必要ならカスタマイズ可能に』
ってのが第一条件で、別に実装方式は問わなかった筈

その気になれば BF を組み込む程度でも interpreter になりそうで

829 名前:デフォルトの名無しさん mailto:sage [2005/07/18(月) 18:35:17 ]
BFでカスタマイズする処理系スゴス

830 名前:デフォルトの名無しさん mailto:sage [2005/07/18(月) 22:39:54 ]
BF?!
BNF (Backus-Naur Form)じゃなくて?

831 名前:デフォルトの名無しさん mailto:sage [2005/07/18(月) 22:48:10 ]
BF
pc8.2ch.net/test/read.cgi/tech/1036013915/l50



832 名前:デフォルトの名無しさん mailto:sage [2005/07/19(火) 00:19:44 ]
Boy Friend

うほっwww

833 名前:デフォルトの名無しさん [2005/11/24(木) 02:13:02 ]
MVCとかって本当に必要なの?
開発ってか設計がめんどうなんだけど・・・

834 名前:デフォルトの名無しさん mailto:sage [2005/11/24(木) 08:00:24 ]
>>833
VCしかないシステムの拡張やらされた時には前任者に殺意を覚えたぞ。

835 名前:デフォルトの名無しさん mailto:sage [2005/11/24(木) 08:35:41 ]
>>833
一度、プログラマが10人以上いるプロジェクトで
すべての処理を一つのクラスにつっこむ実装をしてみるとわかるよ

836 名前:デフォルトの名無しさん mailto:sage [2005/11/24(木) 14:05:48 ]
>>9
> デザパタで成功してるのはstlのイテレータくらい。
なんでイテレータだけなんだ?
JavaのIteratorのほかにObserver、I/OのDecoratorとかはどうよ?

> MFCやWTLはチェーンやらデコレータやらがとっちらかってて、
> どうしてもキショイコードになる。


837 名前:デフォルトの名無しさん [2005/11/24(木) 16:50:37 ]
MVC ってさ、

M:機能本体
V:出力
C:入力と制御(メインループとか)

で良いの?
正直、よく分からんのだが・・・

838 名前:google って知ってる? mailto:sage [2005/11/24(木) 19:03:03 ]
>>837
調べる気のない人は
一生解らないままでいて下さい。

839 名前:デフォルトの名無しさん mailto:sage [2005/11/27(日) 01:16:05 ]
>>838
ヒドス

840 名前:デフォルトの名無しさん [2005/11/27(日) 08:33:23 ]
>>839
デザパタ信者ってこんなのばっかだよ。
教えないんじゃなくて「知らない」or「自分の勝手な解釈で覚えたと思い込んでる」から説明なんてできない。
もし、説明なんかして他の人間と解釈が違っていたら、自分が理解していないことがばれちゃうから、
そういう危ない橋は渡らないのが奴等の処世術。
デザパタなんてオブジェクト指向すら無視してるんだから、当然オブジェクト指向すら理解してない。
で、なんだかんだ苦しくなると「デザパタは全く新しい〜」とか御馬鹿なこと言い出す始末。
これが前スレからの流れ。

841 名前:デフォルトの名無しさん mailto:sage [2005/11/27(日) 08:49:45 ]
       /:
   ∧∧ /  :
  (,,゚Д゚/    :
_ / つ/) _  :
〜(⌒)__)  /| ,, :  
 ̄ ̄ ̄ ̄ ̄|/,,,    
        〜〜〜〜〜〜〜〜〜〜〜



842 名前:デフォルトの名無しさん mailto:sage [2005/11/27(日) 15:34:19 ]
>>837==>>840
による自作自演か。

>>838の言うとおりなんだけどね。
ちょっと調べればMVCで実際に設計する方法がわかるのにね。


843 名前:デフォルトの名無しさん [2005/11/27(日) 16:04:25 ]
>>838==>>842
による自作自演か。

>>840の言うとおりなんだけどね。
ちょっと調べればMVCで実際に設計する方法がわかるのにね

844 名前:デフォルトの名無しさん mailto:sage [2005/11/27(日) 17:29:00 ]
まてまて
調べても理解出来なかった というパターンもありうる。


845 名前:デフォルトの名無しさん mailto:sage [2005/11/27(日) 17:33:38 ]
>>844
我々は選ばれた人間なのですね!

846 名前:デフォルトの名無しさん mailto:sage [2005/11/27(日) 22:59:43 ]
一人で書くなら不要
一人神グラマがいれば、そいつを基準に周りがまねたら良いから不要
一人ではまだ頼りない感じの人達をまとめ上げるために必要なものだ

847 名前:838 mailto:sage [2005/11/28(月) 12:18:29 ]
>>843
>>838==>>842
残念ながら違いますよ。間抜け。

> ちょっと調べればMVCで実際に設計する方法がわかるのにね
判っているなら、そうしなさい。

848 名前:839 mailto:sage [2005/11/30(水) 23:48:07 ]
>>844 調べてわかったけど釣り発言してみよう というパターンもあり、えない
>>845
>>847 オトナゲナサス


849 名前:デフォルトの名無しさん mailto:sage [2005/11/30(水) 23:57:52 ]
       /:
   ∧∧ /  :
  (,,゚Д゚/    :
_ / つ/) _  :
〜(⌒)__)  /| ,, :  
 ̄ ̄ ̄ ̄ ̄|/,,,    
        〜〜〜〜〜〜〜〜〜〜〜

850 名前:デフォルトの名無しさん [2005/12/01(木) 05:51:30 ]
M マゾな
V vsialbasic使いは
C CやC♯は使えません。

MVCで
webは何となく分かるけど
javaのクラス設計で考えたら
Vはインターフェイスとして
Mが実装で
Cはインスタンス化=利用するクラス?
結城先生の本買った方が良いのかな・・・・
高いしな
 

851 名前:デフォルトの名無しさん mailto:sage [2005/12/01(木) 07:53:24 ]
あのころのおれならMLですまーとにかいたんだけどねw



852 名前:デフォルトの名無しさん mailto:sage [2005/12/04(日) 21:08:41 ]
strategy パターンって単なるコールバックじゃんwww

853 名前:デフォルトの名無しさん mailto:sage [2005/12/04(日) 21:17:04 ]
そうだが……何か辛いことでもあったのか? 俺でよければ相談にのるぞ?

854 名前:デフォルトの名無しさん [2005/12/04(日) 23:05:16 ]
良スレあげ

855 名前:デフォルトの名無しさん [2005/12/09(金) 00:50:56 ]
>>847>>842

> >>837==>>840
も実は違うんだが・・・

ちょっとからかっただけ
オマイってからかうとオモシロイナw
必死に反応してくれてw


856 名前:デフォルトの名無しさん mailto:sage [2005/12/09(金) 10:59:08 ]
釣り宣言キタコレ

857 名前:デフォルトの名無しさん mailto:sage [2005/12/10(土) 00:21:15 ]
まあ 隔離スレなんだから、こんなんばっかだろ。
頭のいい奴は、つられたりしないわけだから
気をつけてればいいのさ

858 名前:デフォルトの名無しさん [2005/12/11(日) 17:38:28 ]
852>strategy パターンって単なるコールバックじゃんwww

同感です。昔、GOF 本を読んでクラスを使って実装した strategy パターンのコードを単純化して言ったら、関数ポインタの設定値の切り替えだけになっちゃいました。

それから GOF 本を真剣に読む気持ちがなくなりました。


859 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 17:58:58 ]
>>858
デザパタの存在意義が「技術ブレークスルー」だと勘違いしている
馬鹿がまた一人。

860 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 17:59:31 ]
>>852,858
デザインパターンに過剰な期待をしていないか?
「単なる○○じゃん」「同感」という発言は、
デザインパターンの目的・役割を取り違えてないか?

デザインパターンは、別に
「そこらのエンジニアが考えつかないような素晴らしい夢のパターン集」
でもなんでもないぞ。
誰でもやっている・よく使われる設計手法に名前を付けてカタログ化したものでしかない。
エンジニア間の共通認識化・共通語化するのが目的。


861 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 18:14:57 ]
指きたす同様デザインパターンって言葉を使いたがる人たちがいるだけだろ



862 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 19:33:05 ]
例えばJavaDoc に
 ・・・
 このクラスはGoFの○○パターンの××です.
 @see □□
 @see △△
とか書いて有ればクラス図見なくても設計意図と構造が解る

ってのもデザインパターンとして用語と設計が定義して有るおかげよね.

863 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 19:40:58 ]
>>862
ぶっちゃけ言いたい。



構造が分かっても用途が分からないドキュメントは糞。

864 名前:デフォルトの名無しさん [2005/12/11(日) 20:16:20 ]
>とか書いて有ればクラス図見なくても設計意図と構造が解る
                         ̄ ̄ ̄ ̄
>構造が分かっても用途が分からないドキュメントは糞。
             ̄ ̄ ̄

ここでもエンジニア間の共通認識化・共通語化をする必要がありそうだな

865 名前:デフォルトの名無しさん [2005/12/11(日) 20:24:19 ]
デザインパターンは、単なるカタログです。

共通的に使える設計で出てくるパターンは、
資産化しなさいよーという教えです。

866 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 20:28:27 ]
完全にデザインパターンにマッチする方が少ないんじゃない?
適用できるなら適用すればいいだけかと


867 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 21:01:21 ]
>>863

詭弁のガイドライン
6.一見、関係がありそうで関係のない話を始める
16.全てか無かで途中を認めないか、あえて無視する
17.勝手に極論化して、結論の正当性に疑問を呈する

あたりか

868 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 21:02:12 ]
>>863
>構造が分かっても用途が分からないドキュメントは糞。

そんな当たり前のことを偉そうになに突っ込んでるんだよw


869 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 21:23:54 ]
>構造が分かっても用途が分からないドキュメントは糞
まんまデザパタのことだな。

870 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 21:27:25 ]
…………俺、爆弾投下しちゃったっぽいな

871 名前:デフォルトの名無しさん mailto:sage [2005/12/26(月) 18:26:38 ]
で、隔離スレが出来たら本スレがほんとに落ちちゃったわけか・・・

ここのアンチの人ってオブジェクト嗜好だよね。
憂鬱本読んでわかった気になってるパターンか。



872 名前:デフォルトの名無しさん [2006/02/21(火) 23:48:17 ]
ちょっとデザインパターンからはずれてしまうんですが、
内部設計というか、プログラムのインターフェース設計ってどうやってます?

自分の経験では、共通化の行き過ぎによるメンテナンスの低下が多くのプロジェクトで見られます。
簡単にいうと、こういうことです。

処理A、処理B、処理Cがあったとして、この3つは横展開の関係にあります。
3つも実装するのは大変なので、全て共通化して実装した(methodX(A)のように1つのメソッドで処理A〜Cを行い、どれを行うかは引数で指定する)。
ただし、メンテナンス作業を繰り返すうちに、If (処理Aの時のみ)...のような記述が増え、所謂マカロニソースになってしまった。
最初から処理A、処理B、処理Cは別々に実装すべきだった。
もちろん共通化すべき部分はあるので、下請け処理の共通部品を作るべきだが、
大元の処理は分けて実装すべきだった。

なんで、こんな失敗するんでしょう?
最初からA〜Cはほとんど同じ実装で済むと思っていたのが、
想定外のバグ、仕様漏れ、仕様変更等により、A〜Cが乖離した結果、マカロニ化してしまうんですね。
けれど、「想定外」のことを想定して設計なんてできないんですよ。

皆様どうやって設計してますか?

873 名前:デフォルトの名無しさん [2006/02/21(火) 23:49:16 ]
872の続き

けれど、「想定外」のことを想定して設計なんてできないんですよ。

皆様どうやって設計してますか?


874 名前:デフォルトの名無しさん [2006/02/21(火) 23:59:09 ]
2行しか読んでないけど
>どれを行うかは引数で指定する
これが間違ってると思う

875 名前:大根 [2006/02/22(水) 00:00:29 ]
>>874
ご回答ありがとうございます。
すいません、新スレ立てさせていただきました。
デザインパターンとは違う話題なので。。。

876 名前:デフォルトの名無しさん mailto:sage [2006/02/22(水) 16:53:47 ]
そういや、デザパタスレなくなったな。悲しいことだ。

877 名前:デフォルトの名無しさん mailto:sage [2006/02/23(木) 18:31:51 ]
昔から俺がやってた手法に勝手に名前つけられただけ

878 名前:デフォルトの名無しさん mailto:sage [2006/02/23(木) 18:48:42 ]
未だに>>877みたいな勘違いをしている奴がいるんだな。
名前を付けて普及させ、技術者間の共通認識にするところまでやってはじめて価値が出る。
どんなに優れた設計でも『オレ様パターン』じゃ意味ないんだよ。

879 名前:デフォルトの名無しさん mailto:sage [2006/02/23(木) 19:12:09 ]
>>878
その点において最大の価値がある。

>>877
全パターンをただ一人で考案した
というのはとても信じられない

880 名前:責任転嫁マン mailto:sage [2006/02/24(金) 01:07:28 ]
じゃあ、このスレで900を取った奴がデザパタスレ建ててくれ。
確か、5スレ目まで言ってたので、「【GoF】Design Pattern 6」とかで。

881 名前:デフォルトの名無しさん [2006/02/25(土) 00:39:28 ]
まだ、こんなスレあんのか?
デザパタなんて使ってる会社無いっていってるだろ。
だいたいGoF本なんてもう絶版だろ?ワロス
オブジェクト指向が理解できない奴ほど食いつくんだよな
いい加減にオブジェクト指向理解しろって
オブジェクト指向言語がメジャーになってから何年経つんだよテラワロス



882 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 00:47:09 ]
J2EEパターンを知らない奴がまた現れたのか。
JavaでサーバサイドシステムをJ2EEパターンを使わないで作ってる会社なんて無いよw

883 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 00:54:09 ]
>>882
はぁ?なにそれ?

884 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 01:39:23 ]
>>883
「?」の後は1つ空白を入れろ 話はそこからだ
ただし」が続く場合はいらないぞ

885 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 02:42:03 ]
>>884
うるせえよ
氏ね

886 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 10:49:04 ]
>>883
言われたとおりに書いてればおkなドカタには不要なモノだよ

887 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 10:56:55 ]
まあれだ、デザパタってのはプログラマに対して、
コンビニのアルバイトみたいに、接客対応マニュアル
を用意してくれたってことでしょ

888 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 12:43:07 ]
デパガがトイレに行く事を棚卸してきますとか言うだろ?
共通の認識がないとこういう符丁は成立しない。デザパタも似た様なもんだw

889 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 18:16:18 ]
一人プロジェクトでメンテも自分以外やらない、つー場合でもメリットある?
あるなら本でも読んでみようという気になるかも

890 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 18:35:05 ]
>>889
こうしてこっちはあーしてこういう風に作ろう が これしよう と単純に考えられる
ライブラリでデザインパターンになってるものがあるから、それを簡単に理解できるようになる

891 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 19:02:37 ]
考察段階でつまずいたり時間がかかったりすることは
ほとんどないしなあ。今ひとつ食指が動かない



892 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 19:24:15 ]
pc8.2ch.net/test/read.cgi/prog/1140795650/2
   , -‐−-、  ヽ∧∧∧ //  |
.  /////_ハ ヽ< 釣れた!> ハ
  レ//j け ,fjlリ / ∨∨V ヽ  h. ゚l;
 ハイイト、"ヮノハ     //   |::: j  。
  /⌒ヽヾ'リ、     //     ヾ、≦ '
. {   j`ー' ハ      // ヽ∧∧∧∧∧∧∨/
  k〜'l   レヘ.   ,r'ス < 初めてなのに >
  | ヽ \ ト、 ヽ-kヾソ < 釣れちゃった!>
.  l  \ `ー‐ゝ-〈/´   / ∨∨∨∨∨∨ヽ
  l     `ー-、___ノ
  ハ   ´ ̄` 〈/‐-、


893 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 19:42:26 ]
>>891
考察段階でつまずくんじゃなくて、考察内容自体を短縮するんじゃないか?

894 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 20:53:19 ]
例えばデザパタを習得していると、音声認識とか不可逆圧縮アルゴリズム、
動画再生ルーチン、将棋の強いアルゴリズムとか楽々こなせるほどの
思考手法が手に入るの?(コーディングとかマンパワー的なものは除いて)

こういう専門分野以外はソフト構築の考察時間なんかほとんどゼロだと思う
んだけど。

895 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 20:56:16 ]
>例えばデザパタを習得していると、音声認識とか不可逆圧縮アルゴリズム、
>動画再生ルーチン、将棋の強いアルゴリズムとか楽々こなせるほどの
>思考手法が手に入るの?(コーディングとかマンパワー的なものは除いて)
入るわけない
誰がそんなこと言ったの?


896 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 20:57:45 ]
だから、それじゃあ学ぶ価値なんかないよ。一人でやってる限りは。

897 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 21:05:59 ]
デザパタの使い道がわかっていない典型だ

898 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 21:30:33 ]
だから一人プロジェクトでの効能をキボン

899 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 21:41:49 ]
10ステップの命令文を1つの関数にすれば、関数の名前だけで内容が一気に把握できる
そういうことが本当に分からないなら勉強する気も起きないだろうしやんなくていい
釣りかな

900 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 21:51:18 ]
そんなことは百も承知だけど例えとしてそういうもんなのか?
無限の関数名が出来そうだけど

901 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 22:04:06 ]
>>898
「こういうときはこうする」というチップス集としても役立つ。
自分で考える手間が減るだろ?

専門分野のソフトウェアにしたって、入出力やイベントハンドリングなんかは
機能として実装するだろ?
そういう部分で「よくやる手法」としてのチップス集にはなる。
あるいは機能の重複をどう効率よく実装するか、とか。

・・・無理矢理かな?



902 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 22:11:07 ]
なんねぇんじゃん。
変数名をプロジェクトで決まった用語のローマ字方式でつけてて
開発の途中でダサいって理由で英語で付け変えた変数名も、
誰も読めないって理由で結局対応表が必要になった。

これはデザパタにもいえることだけど余計な手間増やしてない?
みんなの共通認識っていうけど、別にあの本はネットで公開されてるわけでも
そこまで普及してるわけでも、開発のすべてをカバーしてるわけでもない。
アレを覚えることで得られるメリットも開発に参加する人数の大半をサポートしていなければ
その説得力は無いも同然。

デザパタがいいという人間はデザパタを知ってる人間とかしか開発がしたくなくなるとかいう呪い付き。
やっぱり駄目じゃねぇのかな?

903 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 22:16:55 ]
>>901
>専門分野のソフトウェアにしたって、入出力やイベントハンドリングなんかは
>機能として実装するだろ?

この辺がどう効率的になるのかわかんないんだ。現状でもコーディング
の時間以外はコストかからんしライブラリやフレームワークがあればそれ
も軽減できる。

>「こういうときはこうする」というチップス集としても役立つ。

チップスの数って数えられるほどに押さえられるもんなのか?

そういわれると問題に対して適用する手法はそんなにない
ような気もしてきた。

904 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 22:59:21 ]
>>900
無限ってことはないでしょ 使われなくなったら消えるし
良く使われる部分にそれがあると楽になるんじゃないか

良く使われる部分でもその名前が知られてなければしょうがないというのは……
まあ自分で考える時に使うということで
gotoよりforループだ ってぐらいのものじゃないと意味がないってことか?

905 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:20:01 ]
>>904
>gotoよりforループだ ってぐらいのものじゃないと意味がないってことか?
そう。
プロジェクトで結構手間がかかるのは
個人個人の認識の仕方を確認し、それを共通認識までもってくことだからな。
その手間をぶっちぎって、「デザインパターン読んでください」なんて突き放してうまくいくわけがない。

中国語と英語を話す国に
「今日から日本語が母国語になります。ええ、決まったことですからしょうがないですね。」
なんてふっかける行為となんら代らない。

906 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:21:10 ]
> ライブラリやフレームワークがあればそれも軽減できる。
それこそがデザパタの適用w

907 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:22:01 ]
>無限ってことはないでしょ
これはなんとなく分かるけど

>使われなくなったら消えるし
>gotoよりforループだ ってぐらいのものじゃないと意味がないってことか?
スマンが何を言ってるのか不明。


908 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:22:12 ]
たしかに日本語のテキストなんかもたくさん出てるだろうし、
勉強する環境やらお金やらは問題ないかもしれんだけどやるか?やらんだろ?

909 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:25:47 ]
>> ライブラリやフレームワークがあればそれも軽減できる。
>それこそがデザパタの適用w

おれデザパタとか意識してないよ。

こういうときはこれ(ライブラリでも手法でも)を使う、ってのは
大概苦労せずに出てくるけど

910 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:25:51 ]
> アレを覚えることで得られるメリットも開発に参加する人数の大半をサポートしていなければ
> その説得力は無いも同然。

わかってんじゃん。

> みんなの共通認識っていうけど、別にあの本はネットで公開されてるわけでも
> そこまで普及してるわけでも、開発のすべてをカバーしてるわけでもない。

俺の周囲は常識としてあたりまえに知っているけどな。
デザパタを知らないDQNばかりの開発者だらけの現場だとそうなる。

・・・とは言え、分野にもよるのだろう。
J2EEアプリの開発者達は知っていて当たり前。知らなければDQNと言われても仕方ない。
他の分野だとJ2EEアプリほどアプリ全体の作りがパターン化しないと思われるから
デザパタが普及する必要性は低くなるだろう。


911 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:31:49 ]
>>910
J2EEなんて狭い世界にしかいないからそんなんなんだよw



912 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:54:14 ]
データ構造には名前が付いてる。スタックだとかツリーだとかリストだとか?
アルゴリズムにも名前が付いてる。バブルソートだとかクイックソートだとか?
OODにも名前を付けてみた。それがデザインパターン。

>>905
デザパタがあるから不親切なのか?不親切な奴はデザパタの有無とは無
関係に不親切だぞ?
もしデザパタがなかったなら、ソース読めと突き放されるだけだと思うが?

全部暗記しないと話にならない?ありえん。
全てのデータ構造を知ってるか?全てのアルゴリズムを知ってるか?
少なくとも俺が知る限り、そんな奴はいない。

重要なのは、名前は目次になるってこと。
名前を得られれば、その実装なり実装例なりを得られる。ないと困るだろ?

913 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 01:05:34 ]
>>907
使われなくなったら消えるっていうのはそのままだ
誰も使わないデザインパターンは消え去るでしょ? 言葉と同じ

gotoとforループは機能と認知度のことで例としてあげた
gotoでforと同じ機能が実現できるけど、forを使う
それは便利で、そして誰でも知ってるからか という話

そんなに分かりにくかったかな……

914 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 01:44:57 ]
>>912
>ないと困るだろ?
別に困らない。
むしろ、勝手に名前をつけて共通認識にもなってないのに使ってくる奴のがウザイ。

915 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 01:58:36 ]
自分の知ってることが全て 俺が知らないことは言うな
ってやつもウザイ。

916 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 03:15:27 ]
>>915
でも、仕事でそういう状況のときってどうするのが適切なのかな?
例えば、
B:「これなんでこんな変な組み方してんの?」
A:「あ、ここはステートパターン」
B:「なにそれ?」
A:「デザインパターンという・・・というわけですよ」
B:「なんかよくわからないけど、そのパターンがどうしてここで使っててそれで間違った組み方じゃないって言えるの?」
A:「だから、デザインパターンの・・・はこういう・・・のときに使うのが・・・なわけですよ。」
B:「どして?さっぱりわかんね。そもそも、そのステートパターンとかよくわからないし。何がよくてどうしてそのパターンを使いたいの?」
ってなったときね。
ここで本を渡して「はい、自分で勝手に調べてね」っていうとすげーヤナ奴じゃない?
上司でもないのに変な用語使って勝手に仕事増やしてる痛い奴であることに間違いは無いよ。
やっぱり無難にそのパターンの詳細を説明することになると思うけどそれだと別にそのクラスの仕組みを説明すればいいんであって
べつにパターンとかいう必要ねぇし。と思う。
これってデザパタ知ってる奴同士でも同じじゃね?

917 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 03:40:56 ]
B:「これなんでこんな変な組み方してんの?」
A:「あ、ここはステートパターン」
B:「なるほどね」

- 完 -


918 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 03:42:02 ]
>>916
それ、前提が間違ってるわ。
配列で済むとこにリスト使ってたら、そりゃただの馬鹿だろ?
デザパタも同じで、不要なとこで使ってたらただの馬鹿だ。

試しにさ、リストを使う妥当な理由があるという前提の下で
リストを知らない者にリストという単語を使う事なくそのデー
タ構造を説明するというシチュエーションで話作ってみてよ。

919 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 03:42:14 ]
J2EEってそんなに狭い世界なのか?

920 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 04:17:28 ]
自分はもっといろいろ知ってるんだぜ!って言いたいんだろw

921 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 05:09:22 ]
>>916
クラスの仕組みを説明したときに、それにこういう名前がついてるっていえばいいんじゃないか?
名前の説明が追加されても大差ないし、次があれば楽に説明できる

それとその例だとAさんが説明したのにBさんが分かってないようだが
Aさんの説明が悪いか、Bさんに理解する気がないかのどちらかだ



922 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 08:51:14 ]
>>918
916じゃないけどやってみた

B:「これなんでこんな変な組み方してんの?」
A:「あ、ここはリスト構造」
B:「なにそれ?」
A:「要素をインデックスじゃなくて、次へのポインタで指すデータ構造です」
B:「……ああなるほど、これだとデータ挟んだり抜いたり、配列でやりにくいことが楽に出来るんだ」

例えが分かり易すぎて引き合いにはなりませんですた。

デザパタが物議をかもすのは、ひとつの名前に対しての内容が
人によってはアンバランスに感じるほど詰まってるからじゃねーの?

おれはデザパタ知らん人間ね。

923 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 08:51:24 ]
共通の名前ってーのも一理あると思うが、デザパタって「システム」という大枠を
どのように細分化していくかって話もあるだろう? (つまり境界線をどこに引くか)

>>894
> 例えばデザパタを習得していると、音声認識とか不可逆圧縮アルゴリズム、
> 動画再生ルーチン、将棋の強いアルゴリズムとか楽々こなせるほどの
> 思考手法が手に入るの?(コーディングとかマンパワー的なものは除いて)

そういった思考手法そのものが手に入るのではなく、そういった思考手法と他の機能が
どのように連携するのかを考え、適切なクラス分割が行えるようになる。
例えば、将来的に音声認識アルゴリズムを(クラスを追加するだけで)ばっさり他のものと
入れ替えることが簡単に行えるようになるわけ。

> こういう専門分野以外はソフト構築の考察時間なんかほとんどゼロだと思う
> んだけど。

ソフトが行っている内容は考察するほどもない簡単なものかもしれんが、
将来どういった仕様変更があるのか(どの部分を入れ替えられるようにするのか)について
は色々考えるべき点が多いぞ。


924 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 09:02:06 ]
>>923
>入れ替えることが簡単に行えるようになるわけ。
別にデザパタ知らんでも簡単に入れ替えられるんだな。

>将来どういった仕様変更があるのか
仕様変更要求に対して、「面倒くさいなあ」以外に困ったことなんてないんです。

つーか仕様変更で困っていると言う話を聞くたびに不思議。いったいどんな
組み方してるんだろう。

素直に組んでれば改変追加etc、何も問題ないと思うんだけど。

925 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 09:20:16 ]
>>924
> 別にデザパタ知らんでも簡単に入れ替えられるんだな。

そういう人にとってはデザパタって「共通の名前」という以外の意味はないんでしょうな。

> 仕様変更要求に対して、「面倒くさいなあ」以外に困ったことなんてないんです。

その「面倒くさいなぁ」ってーのはどんな感覚?
Aという要求がBという要求に変わった時、クラスの「追加だけ」で対処できる?
Aの機能を呼び出したりする部分を一切変更することなく、Bの機能を実現したクラスの
追加だけで対応できているんであれば、あんたはかなりの実力者だ。

> つーか仕様変更で困っていると言う話を聞くたびに不思議。いったいどんな
> 組み方してるんだろう。

仕様変更が起こった場合、変更とは直接関係のない部分(上記で言うところのAの機能を
呼び出している部分)まで修正が及ぶため、そこも含めてテストをやり直さなければなら
なくなるのが普通。  これによって工数が無茶苦茶増える。

> 素直に組んでれば改変追加etc、何も問題ないと思うんだけど。

客先からの要求ヒアリングでも、「どこに仕様変更が起こりそうか」なんてことは
ほとんど聞けないのが実態。 素直に組むことで問題が解決される例はほとんどない。


926 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 11:14:54 ]
>>925
>その「面倒くさいなぁ」ってーのはどんな感覚?
単に仕事が増えてゴルア。精神的な問題のみ

>Aという要求がBという要求に変わった時、クラスの「追加だけ」で対処できる?

クラスかどうかはともかく、変更の規模によって

・Aを多少改造(現機能も維持したまま条件判断で追加のケース)
・Aをまるまる残してBを追加。

関係ないけど、どっちのケースもAの動作はとりあえず残しておく。
元に戻したい時ってのは常にあるから。容量が厳しい場合はケースバイケース

>変更とは直接関係のない部分(Aの機能を呼び出している部分)まで修正が及ぶ

AをBに変えるならAを呼び出しているところは全然無関係だとはいえないよ。
変えたところをテストするのはしゃーないじゃん

まったく関係ないところはあたりまえだが変更など皆無。

>「どこに仕様変更が起こりそうか」予測できない
だから、変更を許容せよ、がおれの組む時の一番頭にあること。

プログラムを仕事にしてから一番学んだのはそれだね。

927 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 11:58:16 ]
ソース管理ツールくらい使ってるだろうし、
戻すなんて手間じゃないだろうに。

…じゃなくて。冷静になろう。
話がデザパタから微妙にずれてきてる。
これはニュアンス的にはリファクタリングのネタだよな。

928 名前:925 mailto:sage [2006/02/26(日) 12:11:13 ]
>>926
> AをBに変えるならAを呼び出しているところは全然無関係だとはいえないよ。

そうとも言えないんじゃない?
AとかBとかの機能と、それを呼び出す部分のインタフェースをうまく設計すると
AがBに変わったとしても、Aを呼び出しているところにいっさい手を加える必要は
無くなるわけです。
さらに、Aのインスタンスを生成する部分に工夫を加えておくと、設定ファイルを
いじるだけでAのインスタンスでもBのインスタンスでも生成できるようになるん
ですな。 コードに手を加える(修正する)必要が無くなるんです。

> 変えたところをテストするのはしゃーないじゃん
その通り。 だから修正部分が減るとテスト工数が激減することになる。

> だから、変更を許容せよ、がおれの組む時の一番頭にあること。
デザパタ(というかオブジェクト指向原則の多く)が言っているのはまさにそこ。
変更を許容する以上、変更点を局所化することこそを考えるべきではないで
しょうか?


929 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 12:14:07 ]
>>927
> 話がデザパタから微妙にずれてきてる。
> これはニュアンス的にはリファクタリングのネタだよな。
いや、ずれてないと思うぞ。
デザパタを利用することでリファクタリングも楽になるという点で、関連はあるが。


930 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 12:22:05 ]
>>927
スレ違いごめんよ

>ソース管理ツールくらい使ってるだろうし、
>戻すなんて手間じゃないだろうに。

単純に戻すとかいう問題じゃなくて、どっちも使いたいとかなる
場合もあるからプログラム的に共存させておくことを念頭におい
て作っている

>>928
>AがBに変わったとしても、
もちろん外見が同じなら何も変更はしないよ。
ただそうじゃない場合もあるし。(まれと言えばまれ)

まあ、

>設定ファイル
それをもっと進めている。外見のインターフェースがまったく
変わったとしてもコードのビルドしなおしなんてやんない。

ビルドしなおすのはまったく新しい機能追加と
大好きな最適化やる時だけ

931 名前:925 mailto:sage [2006/02/26(日) 12:38:28 ]
>>930
> もちろん外見が同じなら何も変更はしないよ。
> ただそうじゃない場合もあるし。(まれと言えばまれ)

外見(つまりインタフェース)を同じになるようにするってーのが、システムを設計する
際の肝であり、GoF本が主張している「インタフェースに対して設計する」ということで
すね。
「そうじゃない場合もあるし」というのは、まだまだ精進する余地があるってことでしょう。
(とはいえ、完璧に予想するなんて、神にしかできないだろうが。w)

そういった観点から見た場合、デザパタは「変化しそうな部分の外見(インタフェース)を
汎用的な形に変形するための設計をカタログ化」したものと言えるんじゃないかな。

デザパタを使うと無意味なクラスが多くできるとか、デザパタを用いて失敗したという
のは、こういった変形を必要以上にシステム内に持ち込んだり、誤った変形をしてしまった
結果に起因するのではないかと言ってみる。




932 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 17:15:45 ]
>>928
>AがBに変わったとしても、Aを呼び出しているところにいっさい手を加える必要は
>無くなるわけです。
これってソースコードだけの話であってテストは必要になるから手間としては全く意味ない。

933 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 19:37:56 ]
>>932
> これってソースコードだけの話であってテストは必要になるから手間としては全く意味ない。

ふっ、、、甘いな。
テストが必要になるとすれば、正しいインスタンスが生成されていることの確認だけだろう?


934 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 21:52:34 ]
>これってソースコードだけの話であってテストは必要になるから手間としては全く意味ない。

ひょっとして、ここは笑いどころだったのか?
ソースコードだけの話って、ソースコードいじると色々とたちの悪い問題が出てくるんだが。


935 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 22:08:04 ]
というふうに、デザパタ肯定派でも意見の対立がある(・∀・)

936 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 23:47:30 ]
>>933
>テストが必要になるとすれば、正しいインスタンスが生成されていることの確認だけだろう?
そのテストってどうやるの?
何を証明すればキチンとした動作になってると言えるのかわからない。
とりあえず全パターン出して、今回の変更で変わる部分を抜き出さないとテストは終わらない。
そういうふうに人に説明しにくい仕組みしてしまうよりは、ベタで書いたほうが早いと思う。単純に。

937 名前:デフォルトの名無しさん mailto:sage [2006/02/27(月) 01:46:03 ]
多分単体テストと結合テスト、外部テストがごっちゃになってるんだと思う。

938 名前:デフォルトの名無しさん mailto:sage [2006/02/27(月) 01:48:05 ]
テストの種別も組織によって違うしねw

939 名前:デフォルトの名無しさん mailto:sage [2006/02/27(月) 02:58:03 ]
>>937
それを含めて全パターンだしても>>936のいってることは代わらないと思う。

940 名前:デフォルトの名無しさん mailto:sage [2006/02/27(月) 06:41:21 ]
自動化できるところとできないところの切り分けができていないのかと。

941 名前:デフォルトの名無しさん mailto:sage [2006/02/27(月) 07:48:49 ]
>>936
> そのテストってどうやるの?
> 何を証明すればキチンとした動作になってると言えるのかわからない。

そんなことを聞くあなたは、ひょっとするとテストの際、毎回全てのケースをテストしているのかい?
(まぁ、xUnit 等をうまく使えば、そういったことも可能だし、効率もさほど低下しないだろうから、
 毎回全てのケースをテストすることに対して否定はしないが。)

答えは色々あるだろうが、正しいインスタンスが生成されているかどうかを確認したいのならば
クラスBのコンストラクタが起動された際にコンソールメッセージを出すようにするというのは
一つの手じゃないか?  まぁ、この手の方法は組織によって向き不向きがあるんだろうけど。

それよりも >>932>>934 の言ってたソースコードを触った時の危険性を認識しなさ過ぎ。
たいていの厄介なバグは、新規機能に作り込んでしまうのではなく、新規機能を追加した時に
既存機能側をいじり壊して作り込んでしまうものです。




942 名前:デフォルトの名無しさん mailto:sage [2006/02/27(月) 08:30:39 ]
交通事故と同じ。やるやつは繰り返す

943 名前:デフォルトの名無しさん mailto:sage [2006/02/27(月) 09:12:00 ]
かもな。
俺は絶対事故らない、、、とみんな思ってる。


944 名前:デフォルトの名無しさん mailto:sage [2006/02/27(月) 10:31:57 ]
むしろ事故らなかったことはありませんが(プログラムの方だよん。
車の方はやばいと思って運転するのやめた)

945 名前:デフォルトの名無しさん mailto:sage [2006/02/28(火) 03:01:40 ]
>>926の発言をみる限り、プログラミングはうまそうなので、
必要だと思わないのであれば別に無理して覚える必要はないんじゃない?

俺は面白かったから勉強したけど。
俺が得られたメリットは、コードの整理がうまくなったってことかな。
昔、色々コード書いてて、規模が大きくなればなるほど、整理の方法がわからず、
コードが汚くなることが悩みだったが、デザパタ覚えたことで少し改善した感じ。

あと「カタログ化して、みんなの共通の認識とする」っていうのはあんまメリットない気がする。
デザパタしらん人には無意味だし。ただの浮いてる奴としか見られない。

946 名前:デフォルトの名無しさん mailto:sage [2006/02/28(火) 20:30:50 ]
デザパタなくとも、プログラム上手くなればコード整理はできるけど
デザパタないと、共通認識にはできないから俺はそっちの方が重要だと思う

データ構造とアルゴリズム みたいな本がいっぱいあるけど
クラス構造とアルゴリズム になるのがデザパタだろう
どちらも丸暗記する必要はないけどな

947 名前:デフォルトの名無しさん mailto:sage [2006/02/28(火) 22:12:30 ]
「デザパタしらん人には無意味だし。」ってのが正論としてまかり通るのが問題だ。

948 名前:デフォルトの名無しさん mailto:sage [2006/03/01(水) 01:13:50 ]
>>947
つーかもう本でてないしw
流行りも廃れたしw
あのぶ厚い本を一冊読むことを強制するってのは流行らないと思うわ。
なんかもうちょっとお手軽なのじゃないとねぇ。

949 名前:デフォルトの名無しさん mailto:sage [2006/03/01(水) 01:23:54 ]
>>948
もう少し本屋にいった方がいいと思う

950 名前:デフォルトの名無しさん mailto:sage [2006/03/01(水) 06:29:12 ]
>>949
オススメは何?


951 名前:デフォルトの名無しさん mailto:sage [2006/03/01(水) 14:20:46 ]
>>947
うーん、無理だろう。
プログラム勉強するようになっていきなりデザインパターン勉強する奴とかいないだろ。
「関数で処理を分けるのは、なぜ必要なんですか」っていうレベルからだろうし。

100人のプログラマがいても20人くらいしか知ってる奴は期待できないとおもう。
それを20人の都合で、80人に本よめっていうのはわがまますぎだと思う。
所詮たよれるのは自分です。なんつって。

>>948
まあ、とりあえず、デザパタは得て損はないと思うよ。
ただ全部が全部、よいパターン/読んで欲しいパターンだとはいえないんだけど。



952 名前:デフォルトの名無しさん mailto:sage [2006/03/01(水) 15:17:11 ]
100人中100人が知っている必要はないだろう。
100人いたら半数以上は言われたとおりに部品製造していればいいコーディング担当だろうし。

設計を担当するアーキテクトチームなら常識的に知ってて当然だとは思う。
設計について議論しなければいけない人間同士でデザパタが共通認識でないのは問題。
使う・使わない・どこにどう適用するかは別問題として。


953 名前:デフォルトの名無しさん mailto:sage [2006/03/01(水) 20:36:03 ]
>>950
俺は結城さんの読んで覚えた、お勧め
読んではいないが、最近だと変なねーちゃん表紙のやつ評判よかったような

954 名前:デフォルトの名無しさん mailto:sage [2006/03/05(日) 18:13:55 ]
>>952
>設計について議論しなければいけない人間同士でデザパタが共通認識でないのは問題
なんで?

955 名前:デフォルトの名無しさん mailto:sage [2006/03/05(日) 20:08:18 ]
>>954
アーキテクトにとっては、良し悪し・使うべき/使わないべきまで含めて知ってて当然の知識だからな。
デザパタも知らない、共通の概念のない非常識な人間が寄ってたかって設計したシステムなど、お里が知れるわw

956 名前:デフォルトの名無しさん mailto:sage [2006/03/05(日) 23:34:37 ]
そうか「当然の知識」か。そして「共通の概念」か。
・・・それは思いこみであって現実の正しい認識であるとは思えないけどね。

957 名前:デフォルトの名無しさん mailto:sage [2006/03/05(日) 23:39:43 ]
>>955
具体的な根拠がなにも示されて無いな。
本当に理系の人間なのかどうか疑問

>>956
ね。
なんか思い込み強いよね。

958 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 00:19:40 ]
デザパタのように今や古典とも言える超メジャーな設計上のスキームを
「知りもしない」ってのは、土方コーダーならともかく
アーキテクトとしては激しく問題があると思われ。

知った上で使う・使わないは別問題だがな。


959 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 00:43:55 ]
知ったつもりになって使ったつもりになる。
形式だけ学んだので不必要に濫用する。

このパターンが少なくない気がする。

デザパタの粒度ってアーキテクトレベルなんかな?
どちらかと言うとプログラミング(詳細設計から下)レベルに思うんだが。

960 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 06:35:25 ]
>>958
デザパタなんていつ必須事項になったんだか。
オブジェクト指向でもなんでもないし。
すっげどうでもいい部分の寄せ集めじゃん。

>知った上で使う・使わないは別問題だがな
これでデザパタは使えないって結論に至った人間をどうやって説得するのか?

961 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 06:43:31 ]
>>959
> 知ったつもりになって使ったつもりになる。
> 形式だけ学んだので不必要に濫用する。
> このパターンが少なくない気がする。

ここのところは同意。 しかし、デザパタの真意はアーキテクトレベルにあると思うぞ。
それをコーディングの定石集だと誤解しているヤシが多すぎ。

>>960
> オブジェクト指向でもなんでもないし。

オブジェクト指向原理主義ですか?
90年代前半の呪縛に捕らわれてますな。




962 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 13:23:31 ]
>>960
>すっげどうでもいい部分の寄せ集めじゃん。
そうかね?JavaとかC#とかの標準ライブラリ(java.langとかjava.ioとか)は、
デザパタを基準に作られてると思うけど、あれもすっげどうでもいい使えないライブラリかね?
あれらを見たときなかなかいいもんだと感じたもんだが。
まあ、良いか悪いかの感じ方は、人それぞれとは思うけどね。

>>961
俺も>>959と同じくプログラミングレベルの概念だと思うのだが、
デザパタの本は色々読んだが、アーキテクトレベルの説明をする本だとするならば、
あそこまで本の中身がソースコードだらけにはならないと思う。

963 名前:962 mailto:sage [2006/03/06(月) 13:28:47 ]
まあ、俺がアーキテクトという言葉をよく理解していないからかもしれんがな。
アーキテクトという言葉は正直、抽象的すぎてなにをさしている言葉なのかわからんし。

964 名前:961 mailto:sage [2006/03/06(月) 15:08:20 ]
>>962
> 俺も>>959と同じくプログラミングレベルの概念だと思うのだが、
> デザパタの本は色々読んだが、アーキテクトレベルの説明をする本だとするならば、
> あそこまで本の中身がソースコードだらけにはならないと思う。

デザパタは、クラスの関連を用いることで、いかにして実装と抽象を切り離すのかという
ことを明確にしている点が肝なんだと考えています。
そういった意味では、本の中身をあそこまでソースコードだらけにしてしまう必要はなか
ったんじゃないかな。  (クラス図とせいぜい状態遷移図があれば十分だったはず。)

実は「GoF本の翻訳がイマイチで理解しづらかった」→「みんなソースコードに頼ろうと
する」というだけなのではないかと。
(かの結城氏もJavaで書かれてないから判りにくいんだと誤解していたし。)

そもそもデザパタがプログラミングレベルの概念だったとしたら、もっと色々な言語が
シンタックスシュガーとしてデザパタ構文を採用してるんじゃないか?

> まあ、俺がアーキテクトという言葉をよく理解していないからかもしれんがな。
> アーキテクトという言葉は正直、抽象的すぎてなにをさしている言葉なのかわからんし。

アーキテクトほどいい加減な言葉もそうそうないと思う。
あれってプログラミングが設計工程に属していることを認めたくない連中が、
(彼らの言う)設計工程とプログラミング工程のギャップを埋めるために作り出した
役割なんだと思うな。


965 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 18:49:58 ]
>>964
>デザパタは、クラスの関連を用いることで、いかにして実装と抽象を切り離すのかという
>ことを明確にしている点が肝なんだと考えています。
よく考えると切り離す意味が全くわからないな。

966 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 19:20:35 ]
>>965
> よく考えると切り離す意味が全くわからないな。

変更に強くするため。
いくらクラスを作って「カプセル化」だと叫んでも、インタフェース部分に変更が
あると、そのクラスを変更した時、山火事のように影響度が飛び火して広がって
いく。


967 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 20:00:30 ]
>>966
変更に強いかどうかってそんなに重要かぁ?
俺には設計と実装がマッチしてない糞みたいなソースができるような気がするぜ。
つーかさ、変更に強いかどうかじゃなくて、もっと大事なこととして設計と実装とみんなのイメージが
一致してることの方が何倍も大事なことのように思えるんだけど。

968 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 20:01:59 ]
ああ、言いたいことはさ。
変更されたらそれに合わせて変更が必要になってもいいんじゃないの?
ってこと。
てゆうか、設計が変更されたのに実装がそのまんまっておかしいw

969 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 20:16:10 ]
>>967
設計と実装はそんなに離れない 離れたらその設計参考にされてない
変更に強いって言うのは変更箇所が少ない、影響範囲が小さいってこと
釣りなのかマジなのか……

970 名前:962 mailto:sage [2006/03/06(月) 20:21:39 ]
>>967-968
まあ、デザパタを覚えることで利点を感じなければ覚える必要は無いと思うけどね。

あと、「設計変更による変更に強い」というよりは、
設定ファイルや、オプションによる処理の変更には強くできるね。
一行変えるくらいで後々の処理を大きく変えることができるとか。
設計変更されたら実装かえるのは当然だぁね。

971 名前:962 mailto:sage [2006/03/06(月) 20:35:48 ]
>>967
>つーかさ、変更に強いかどうかじゃなくて、もっと大事なこととして設計と実装とみんなのイメージが
>一致してることの方が何倍も大事なことのように思えるんだけど。
こりゃ同意だな。実装はともかく、設計(インターフェース)は、
万人がイメージしやすい&理解しやすいことが望ましい、というかそうすべきであると思う。

デザパタのほとんどのパターンは、実装の変更を容易にすることを目的としているかな。

例えば、データを読込&保存する処理をしたい場合に、保存する手法は何でもよいというとき、
その中身の実装は、普通にファイルで保存したり、DBにしたり、XMLにしたり、
と後々実装を変えたい、または、コマンドラインオプションや設定ファイルによって変えたいと
思った場合の変更に強くすることができるかと。



972 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 20:44:47 ]
フト思ったんだが、、、
ひょっとしたらアンチデザパタってヤシは、設計時に無茶苦茶にデザパタを
適用した結果、設計結果とみんなのイメージが乖離してしまったという
暗い過去を持っているんジャマイカ?



973 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 00:18:43 ]
そこで結城先生の登場ですよ。

>デザインパターンの目標の1つは、プログラムを再利用可能にすることです。
>つまり、どうやってプログラムを「部品」として再利用するかを考えているのです。
>ですから、プログラム例を「完成品」として見るのではなく、今後「機能を拡張していくもの」
>「変更を加えていくもの」として見るようにしましょう。
> ・どのような機能が拡張される可能性があるか?
> ・その機能拡張を行うときに修正が必要になるのはどのクラスか?
> ・修正が不要なのはどのクラスか?
>このような観点でデザインパターンを見ると、理解が深まるでしょう。

974 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 00:36:28 ]
>変更に強いかどうかってそんなに重要かぁ? 

極めて重要だと思う。特に脱ウォーターフォールを標榜する今後のJavaの開発形態としては特に。
と、いうかJavaの抽象化フレームワークやJunitやEclipseの強力なリファクタリング機能が
何の為に存在するのかといったら、やっぱ「変更しないのが前提」、っていうウォーターフォールの一番駄目駄目な
部分を徹底的に唾を吐き、"いかにソースを良くしていくか"、"「動いているソースは駄目ソースでも触るな」じゃなく
「ガリガリ直してどんどん洗練されたソースにリファクタリング」していくか"、
"余計なドキュメント製造に掛かるコストをカットする事で生ずるリスクをどこで吸収できるか"
等にあるわけで。

変更に強い、というのは客の仕様を満たすのと同じくらい重要だと思う。

975 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 00:49:56 ]
世の中には二種類のアーキテクトが居る。

一方のアーキテクトはアンチパターンを認識・検出・除去することが出来る。
残りのアーキテクトは日々新たなアンチパターンを生産することが出来る。

後者多すぎ。

976 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 03:20:30 ]
>>969
いや、だから、どんな変更に強いってのか謎。
変更したらさ、設計がかわるんだよね?
ここはいいよね?
影響範囲が最小っていったって、それってどんな変更をするかによってわからないよね?
普通にそれぞれのクラスに閉じ込めるように作っていれば結果的に変更時の影響範囲が最小になってるって話だよね。
要はメインじゃなくて付加価値みたいなもんでしょ?
それを勘違いしてこっちをメインにして変な仕組み入れてわざわざインターフェースとむりやり切り離してる
プログラムってのはそれだけで気持ち悪いと思うんだ。
おそらく、みて理解のしやすいソースにはなっていない。

977 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 07:30:31 ]
>>976
> いや、だから、どんな変更に強いってのか謎。
「十分予測できるが、現時点では詳細が不明な変更」ですな。
そこを押さえずに何でもかんでも変更可能にしてやろう、あるいはとにかくデザパタを
適用しようという発想がいかんのです。

> 変更したらさ、設計がかわるんだよね?
> ここはいいよね?
ここはOK。 マクロな視点で見れば必ず設計は変わる。 しかしミクロな視点で
構成要素を一つずつ見ていき、影響が出る構成要素の数を極力減らす努力が
必要。

> 影響範囲が最小っていったって、それってどんな変更をするかによってわからないよね?
変更内容が判らないというのであれば、その通り。 しかし裏を返せば、変更の匂いが
するところに対してデザパタを適用できるということ。
伝家の宝刀はここぞという時にしか抜いてはならない(とはいえ意外と多かったりするがなw)。

> 普通にそれぞれのクラスに閉じ込めるように作っていれば結果的に変更時の影響範囲が最小になってるって話だよね。
それはダウト。 現状の静的なスナップショットを取っているだけのデザイナは、松竹梅で
言えば梅レベル。 そもそも現状のスナップショットをいくら睨んで見ても、そのどの部分が
変わりそうなのかといった情報は読みとれないものだ。 つまり「普通にそれぞれのクラスを
閉じこめるように作っていく」だけでは全然不足というわけだ。


978 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 07:31:26 ]
(続き)
>>976
> 要はメインじゃなくて付加価値みたいなもんでしょ?
システムを作るだけ作ってそのまま逃げるような開発をするのであれば、現状のスナップ
ショットのみを用いて設計してもいいかもしれない。 (開発中に入ってくる要求変更と戦う
必要はあるが。)  しかしその後の保守を考えると、変更に対する強度は極めて重要な
ことになるのだ。

> それを勘違いしてこっちをメインにして変な仕組み入れてわざわざインターフェースとむりやり切り離してる
> プログラムってのはそれだけで気持ち悪いと思うんだ。
> おそらく、みて理解のしやすいソースにはなっていない。
おそらく君が過去に接したシステムというのは伝家の宝刀を濫用したものなんだろう。
デザパタを適切に使用した場合のクラス図は、現状のスナップショットがどうなっている
のかという情報だけでなく、今後どういった部分が変化しそうなのかという情報もはっきりと
伝える判りやすいものになるのだ。


979 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 07:33:10 ]
>>976
> 要はメインじゃなくて付加価値みたいなもんでしょ?
> それを勘違いしてこっちをメインにして変な仕組み入れてわざわざインターフェースとむりやり切り離してる
> プログラムってのはそれだけで気持ち悪いと思うんだ。
> おそらく、みて理解のしやすいソースにはなっていない。

俺も最近流行りのDIコンテナを利用した実装とインタフェースを分ける設計をみて
そう感じることがよくある。
IDEのデバッガでも追いづらいし、開発の効率を下げている一面もあるよな。
クラスの入れ替えが容易であるメリットは、ユニットテストの時にモックパターンで
やりやすい点ぐらいか・・・

オブジェクト指向本来のインタフェースの用途ではなく、
言語機能としてのインタフェースの機能を逆手に取ったような手法とも感じる。


980 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 07:51:27 ]
>>973
> そこで結城先生の登場ですよ。

> >デザインパターンの目標の1つは、プログラムを再利用可能にすることです。
> >つまり、どうやってプログラムを「部品」として再利用するかを考えているのです。

注意すべきはここでの「部品」,「再利用」という表現ですな。

A, B, C, D, E, F, Gという7つのクラスで構成されたシステムがあったとする。
普通に「部品」というと、例えばCとかDというクラスを思い浮かべ,「再利用」というと
そういったクラスを他のシステムから利用することを想像してしまいがちになる。

しかし、デザパタのいう「部品」、「再利用」は違う。
デザパタでいう「部品」というのは、「Cというクラスから見た場合はA, B, D, E, F, Gと
いう6つのクラス」であり、Cが変更になった時にこれら6つのクラスに影響を与える
ことなく、「このシステム自体から見て6つのクラスを再利用する」ということだ。


981 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 08:01:01 ]
>>979
> クラスの入れ替えが容易であるメリットは、ユニットテストの時にモックパターンで
> やりやすい点ぐらいか・・・
ユニットテスト時にモッククラスと入れ替えることができるということは、将来そのクラスに
対して変更があった場合、保守コストが引き下げられるということを意味しているはず。

> オブジェクト指向本来のインタフェースの用途ではなく、
> 言語機能としてのインタフェースの機能を逆手に取ったような手法とも感じる。
あなたの考えるオブジェクト指向本来のインタフェースの用途って何でしょう?
実装とインタフェースは無理矢理分けられてるのではなく、本来これらは別々のもので
あるべきなんじゃないかい?




982 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 12:17:18 ]
>979
DIコンテナ使わないチームと使ったチームで比べられればいいけどね。
俺はもうDIコンテナなしの開発は考えたくないです。

まぁDIスレ(typoしてるが)でやるのが適切な話題だし、
あっち過疎ってるから盛り上げて欲しいってのが本音。

983 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 16:36:13 ]
>将来そのクラスに
>対して変更があった場合、保守コストが引き下げられるということを意味しているはず。

タテマエとしてはよく見る意見だが、実際にそのようなシチュエーションは
よくあるのかな?



984 名前:962 mailto:sage [2006/03/07(火) 18:00:51 ]
>>982
DIコンテナって使うとソース見やすくなったりとかするの?
DIコンテナって要は実装クラスをnewする部分をファクトリーじゃなくて、設定ファイルに書くみたいなやつだよね?

設定ファイルの情報を反映させたいときは再起動が必要みたいだから、
ファクトリーで書くのとあんま変わってないのであまり利点を感じないのだが…。コンパイルは不要だろうけど。

985 名前:981 mailto:sage [2006/03/07(火) 19:20:50 ]
>>983
> タテマエとしてはよく見る意見だが、実際にそのようなシチュエーションは
> よくあるのかな?

意外とよくある。 新規開発の際、客先がちゃんと要求を出せてない部分が
開発途中にガンガン決まっていくんだが、デザパタ使ってると楽に対応でき
るぞ。  その都度リファクタリングしてもいいんだが、新規開発時だとユニット
テストデータもちゃんと揃ってないから、その手があまり使えないんだわ。
どの部分が曖昧なのか、ちゃんと客先ヒアリングして頭使わないとダメだけどね。


986 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 19:29:23 ]
変更自体はよくあるんだが……その変更が、デザパタで吸収可能なものなのかは不明
デザパタ使う時点で、ある程度変更内容を予想してなきゃいかんと思う

987 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 19:55:01 ]
インタフェース設計レベルから変更を余儀なくされる要求が多いな。


988 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 20:10:10 ]
>>976
極端から極端に走らなくてもいいじゃん
仕様に載ってない機能を搭載し、ファイル以外にDBやgmailやSubversionも保存先として使えるようにして
隠しオプションでどんな仕様にも即対応! みたいのはそりゃだめだ

デザパタは問題の解決法として書かれていて
その問題があるときは割と的確な粒度の解決だと思うがどうだ?
あれでもまだ余分かな?

989 名前:981 mailto:sage [2006/03/07(火) 20:23:57 ]
>>986
> 変更自体はよくあるんだが……その変更が、デザパタで吸収可能なものなのかは不明
> デザパタ使う時点で、ある程度変更内容を予想してなきゃいかんと思う

結構大変だけどね。 客先が「XXがYYという風に変わりそうだ」なんて自分から教えて
くれることはほとんどないけど、「ここがこうなるとかいうこと考えられます?」といった
聞き方を続けてると、答え方の雰囲気から変更されそうなところが見えてくる場合が多し。
で、実際に変更が発生すると、「実はそういうこともあろうかと、、、」と徳川機関長モードに
入る。


990 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 23:54:24 ]
>984
この話題、DIスレにコピペしてもフォローしてくれますか?
(スレタイの意味での)デザパタとは全然関係ないと思うし。

>ソース見やすくなったりとかするの?
それはないです。

>988
>的確な粒度の解決だと思うがどうだ?
当方もそういう意識ですね。
そういう意味でもアーキテクトと言うよりは、
プログラミングレベルの話題だと思う。
フレームワーク作成チームが知っておくべきプラクティス。

991 名前:962 mailto:sage [2006/03/08(水) 01:21:50 ]
>>990
>この話題、DIスレにコピペしてもフォローしてくれますか?
いやいいっすわ。DIスレみてたら同じ疑問を持っている人がいて勉強になりました。
ありがとう。あっ、でもやっぱり聞いてみようかな。

>>986
漏れの理解ではだけど、デザパタは実装の入れ替えが容易というのが売りだと思ってるから、
プログラムのやることが変わったらデザパタで組もうがなんだろうが変更する量はさほど変わらないと思う。

ただプログラムのやることは同じだけど実装を変える。
例えばパフォーマンスアップのために仕様変更するというのであれば、
それは実装の変更であるから、そういう変更には予想してなくとも強くなれると思う。



992 名前:デフォルトの名無しさん mailto:sage [2006/03/08(水) 01:40:16 ]
つーかさ、
ボタンクリックしたら、そのクリックしたメッセージが降りてくるその場所に
その処理が記述してあってほしい。(関数とかクラスとか)

そうでないと他の人間の書いたソースなんて追えない。
降りてきたメッセージをさらにどっかに飛ばす処理なんか入ってるともう駄目。
すげー面倒臭い。どうにかしてくれ。

単純に、ただ単純に書いて欲しい。
それだけ・・・それだけなんだ・・・orz

993 名前:986 mailto:sage [2006/03/08(水) 01:43:31 ]
>>991
たとえ話になるけど 「100Vコンセントがあれば、殆どの電化製品に対応できる」 とか考えて実装してると、
いざ 「実は、この家電アース線がついてるんだけど……」 ってなったときに、コンセント側も改造しなくちゃいけないな、
って話をしてみた。

アース線無い家電製品のみに限定するなら、いくらでも変更は可能。変更に強い。
ただしアース線だとか外国用の特殊形状だとかが変更で出てくると面倒になるってことで、
どこまで変更を予測するか〜って話だ。

ちなみに↑は Strategy を想定してみた。
解決策としては、Adapter が使えれば手っ取り早い。


どうでも良い。次ぎスレたのむ。

994 名前:962 mailto:sage [2006/03/08(水) 02:08:21 ]
>>992
基本的には単純なものは単純に書くよww 必要になったときにしかデザパタは適用しないよ。

処理をたらいまわしにしている人のソースに悩まされてるの?たまにいるわなぁ。
デザパタだとかいって何でもかんでもたらいまわし処理書く人は。俺も追えない。30秒で諦める自信ある。

必要になった場合に適用すると効果を発揮するというのに、むやみに使うのは毒でしかない。
やるべき処理を素直にコードにすることが一番の解だというのに。

995 名前:デフォルトの名無しさん mailto:sage [2006/03/08(水) 02:22:21 ]
マ板的な話題になってしまうが

とあるベンダが俺様フレームワークを作成して
基本設計の説明に加えて
「ここはあのパターン、ここにはあのパターンを使ってる。」
みたいなことをのたまって
最後にパターン名と適用の有無からなる
2列23行の表を見せて、こんなにたくさん○が付いてますよ
(使った(ことになってる)パターンを○でカウントする。)
みたいな感じで胸を張ってた。

手段が目的にすり替わってしまうと大体ロクな結果を導かんよね。
アンチパターンの表を作るのは意味があるかも知れん。

なんか盛り上がってきたし次スレ欲しいなあ。

996 名前:デフォルトの名無しさん mailto:sage [2006/03/08(水) 03:02:51 ]
手段のためには目的を選ばない。

997 名前:962 mailto:sage [2006/03/09(木) 03:33:36 ]
では私が建てよう。ひっそりと深夜に。

998 名前:962 mailto:sage [2006/03/09(木) 03:39:13 ]
>新このホストでは、しばらくスレッドが立てられません。
>またの機会にどうぞ。。。
「【GoF】デザインパターン 6」で建てようとしたけど駄目でした orz
建てて誘導したいけど残り2レスしかない・・・。

999 名前:デフォルトの名無しさん mailto:sage [2006/03/09(木) 04:28:57 ]
次すれ

「【GoF】デザインパターン 6
pc8.2ch.net/test/read.cgi/tech/1141846078/


1000 名前:デフォルトの名無しさん mailto:sage [2006/03/09(木) 04:29:41 ]
コピペミスで「が残ってたorz

1001 名前:1001 [Over 1000 Thread]
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。








[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<288KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef