【GOF】デザインパターン

1 ：考えよう：04/06/12 23:31

なるほどなーと思ったがあんまり使わないぞ

factory method
abstract factory
builder
prototype
singleton
adapter
bridge
composite
decorator
facade
flyweight
proxy
chain of responsibility
command
interpreter
iterator
mediator
memento
observer
state
strategy
template method
visitor

2 ：デフォルトの名無しさん：04/06/12 23:41

10げっと

3 ：デフォルトの名無しさん：04/06/12 23:48

ひとつひとつ具体的なクラスを交えて紹介するサイトとかある？

4 ：デフォルトの名無しさん：04/06/12 23:49

Singletonは使う。全部Singletonになってしまう。

5 ：デフォルトの名無しさん：04/06/13 00:05

Design pattern (computer science) - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

6 ：デフォルトの名無しさん：04/06/13 00:33

使わないんじゃなくて使えないんだろ。
設計からしっかりやってればちゃんと使いどころが見えてくる。
あんまり小さいシステムじゃ使えないけど。

7 ：デフォルトの名無しさん：04/06/13 00:36

自己満足的に使ってる奴が多すぎるな。
本人は使えてる気になっているようだが実際には・・・
まあ、設計をしっかりやってればちゃんと使いどころが見えてくる、とか
あんまり小さいシステムじゃ使えないけど、とか言っている奴には
使えないだろうけどね。

8 ：デフォルトの名無しさん：04/06/13 00:50

システム規模の大きい小さい関係無いんでわ。
小さいシステムって、3～400行のスクリプトとかか？

9 ：デフォルトの名無しさん：04/06/13 00:52

使いどころが見えてくるんじゃなくて、使うのが当然の仕組みが抽出
できるだけちゃうの。

10 ：デフォルトの名無しさん：04/06/13 01:13

http://p44.aaacafe.ne.jp/%7Efeel/

11 ：デフォルトの名無しさん：04/06/13 01:16

>>9
なんだとこの野郎！

12 ：デフォルトの名無しさん：04/06/13 01:20

デザパタのスレってすでに無かったか

13 ：デフォルトの名無しさん：04/06/13 05:04

本当に再利用されているんですかね、現場で。

14 ：デフォルトの名無しさん：04/06/13 14:28

必要に応じて使うってだけだな。
Java で GUI やると使った方が楽だし。

15 ：デフォルトの名無しさん：04/06/13 18:02

>>1 GoFだけか。GoFだけなら頻繁に使われているほうだと思うが。
GoF以外のデザインパターンを知っている香具師はすくないからあまり使われてなさそうだが。

16 ：651：04/06/13 18:41

>>8
小さいながらもひとつのシステムを3～400行のスクリプトに収められるなら
そこにもなんらかのパターンがありそうな気がします。

17 ：デフォルトの名無しさん：04/06/13 18:46

FactoryMethod
AbstractFactory

今日覚えたパターンはこの二つ。
AbstractFactoryはCだと何も考えなくてもそうなるね。

18 ：デフォルトの名無しさん：04/06/13 18:56

>AbstractFactoryはCだと何も考えなくてもそうなるね。
それはあなたがそうだというだけで「何も考えな」いヤツをあなどってはいけない

19 ：デフォルトの名無しさん：04/06/13 19:53

君たちはまだ、本当に何も考えないやつの恐ろしさを知らない。
何も考えてないやつじゃないよ。それはまだ序の口。

20 ：デフォルトの名無しさん：04/06/13 19:55

シングル㌧だけで十分だよ。

21 ：デフォルトの名無しさん：04/06/13 20:21

ここはデザインパターンの単純そうな質問の次スレ？
とりあえずこんなのはっときますね。

[ja]
Java言語で学ぶデザインパターン入門
http://piza.2ch.net/test/read.cgi?bbs=tech&key=994690114

mogura (2chLinuxer氏に敬礼！）
http://2ch.dyn.to/

22 ：デフォルトの名無しさん：04/06/13 21:36

実際シングル㌧ってなんかメリットあんの？

23 ：デフォルトの名無しさん：04/06/13 21:40

インスタンスを3つしか生成できないようにするのは
トリトンでOK?

24 ：デフォルトの名無しさん：04/06/13 21:49

>>23
それセマフォでは？

25 ：デフォルトの名無しさん：04/06/13 22:32

生成できるインスタンスの数を制限するのがシングルトン。

26 ：デフォルトの名無しさん：04/06/14 00:00

1つじゃなくてもシングルトンなのね

27 ：デフォルトの名無しさん：04/06/14 00:31

違う。
「たった１つのインスタンス」がシングルトン。（結城著の5章のタイトル）

28 ：デフォルトの名無しさん：04/06/14 20:12

>>24
そこはつっこむんじゃなくて、笑ってやるところだろ。

29 ：デフォルトの名無しさん：04/06/15 08:45

>>23
ﾌﾟﾘｹﾞﾗｯﾁｮ

30 ：デフォルトの名無しさん：04/06/22 21:10

たとえばテキストエディタクラスと、ヘキサエディタクラスがあるとして、
ファイルによってどちらを生成するかを決定する場合は
AbstractFactory使えばいいんでしょうか？

31 ：デフォルトの名無しさん：04/06/22 21:27

どこからでも簡単に参照が取ってこれるという「功罪表裏一体」のグローバル変数の
ﾗｸﾁﾝさをシングルトンのメリットだと思っている馬鹿いってよし。

32 ：デフォルトの名無しさん：04/06/22 21:38

何でもかんでもシングルトンにしたらオブジェクト指向の意味が
なくなるような気がする
そんなんなら全部ただのモジュールにしちゃった方が
ごちゃごちゃしない分いいと思う

33 ：デフォルトの名無しさん：04/06/22 23:05

独身豚

34 ：デフォルトの名無しさん：04/06/22 23:06

>>33
まあ、言いたいことは分からないでもないが。

35 ：デフォルトの名無しさん：04/06/22 23:24

元米大統領

36 ：デフォルトの名無しさん：04/06/23 01:31

じゃあ
「どこからでも簡単に参照が取ってこれる」インスタンスが欲しい場合はどうすればいいの？

37 ：デフォルトの名無しさん：04/06/23 09:51

グローバル変数

38 ：デフォルトの名無しさん：04/06/23 22:27

>>30
いいえ。
テキストを生成するときは、テキストエディタクラスを使い、
ヘキサを生成するときは、ヘキサエディタクラスを使うようなコーディングを
しなければなりません。

例
if target == text
　texteditorclass．．．
elseif target == hekisa
　hekisaeditorclass．．．

39 ：デフォルトの名無しさん：04/06/23 23:39

>>38
ダセぇ。ポリモフィズム使え。

40 ：デフォルトの名無しさん：04/06/24 00:23

>>39
尿意

41 ：デフォルトの名無しさん：04/06/24 00:26

納期に間に合わせるなら38が正解

42 ：デフォルトの名無しさん：04/06/24 00:38

>>41
その程度の変更でスケジュールにインパクトが加わるようなカスしかいないのか、
おまえのところは。

43 ：SE：04/06/24 01:20

>>42
いや、俺が仕様聞き漏らしてただけだけど、まだ間に合うから作って。

44 ：デフォルトの名無しさん：04/06/24 01:38

C++でPrototypeパターン適用しようとしたら、どうやってクローンを作ればいいの？

45 ：デフォルトの名無しさん：04/06/24 01:46

>>44
コピーコンストラクタでディープコピーを作るように実装しといて、
明示的に呼ぶとか？

46 ：デフォルトの名無しさん：04/06/24 02:23

>>39-40
ポリモルフィズムを使った解答例がぜひ知りたい
生成されたエディタクラスを使う側はポリモルフィズムでいけるだろうけど、
エディタクラスを生成する側は具象クラスを知らなければいけなくない？

47 ：デフォルトの名無しさん：04/06/24 06:26

>>46
前どっかでそのこと聞いたら、ハッシュを使うとかｗｗ
得意げな顔してポリモルフィズムｗｗｗ>>39-40

48 ：デフォルトの名無しさん：04/06/24 07:45

>>46
いや、そんなことはない。

class Editor;
typedef Editor* (EditorCreator)();

class Factory {
public:
　　void register(EditorCreator, int id);
　　Editor* create(int id);
};

こんな感じのファクトリクラス作って、実際のエディタを作るクラスに対して、
各々ファクトリに EditorCreator 型の生成関数を登録させる。

49 ：デフォルトの名無しさん：04/06/24 09:57

>>48
なるほど。下のような感じですか？

エディタのクリエイタ、ファクトリを作る分
三度手間になっちゃうのね。C++じゃちょっとやりたくないかなぁ。

get_targetid(target)
{
if (target == text) return id_text;
else return id_binary;
}

Factory f;
f.register(texteditor, id_text);
f.register(hexeditor, id_binary);

get_view_object(target)
{
return f.create(get_targetid(target));
}

50 ：デフォルトの名無しさん：04/06/24 21:20

>>49
> エディタのクリエイタ、ファクトリを作る分
> 三度手間になっちゃうのね。
そんなん C プリプロセッサでマクロ書けば 1, 2 行で済むよ。登録処理も
グローバル変数のコンストラクタとか、DLL に逃がすなら DLL のロード
処理でやらせれば良い。

51 ：デフォルトの名無しさん：04/06/25 00:38

そんなアナタにIoCコンテナ。

52 ：デフォルトの名無しさん：04/06/27 00:23

>>51
聞いた事無いっす

53 ：デフォルトの名無しさん：04/06/27 00:26

ぐぐればすぐ見つかるけど一応。

Inversion of Control コンテナと Dependency Injection パターン
http://www.kakutani.com/trans/fowler/injection.html
Inversion of Control
http://wiki.bmedianode.com/Spring/?Inversion+of+Control

54 ：デフォルトの名無しさん：04/06/28 18:57

保守

55 ：デフォルトの名無しさん：04/06/28 19:28

意外とまともなアドバイスがあるスレだな
そこに驚いたｗ

56 ：デフォルトの名無しさん：04/06/28 21:26

デザインパターンは、Java以外の言語では、どの程度認められてるの？
それともJavaでしか再現できないものがあるとか？

57 ：デフォルトの名無しさん：04/06/28 21:44

>>56
Java っつーかリフレクションが充実してないとやりにくいパターンは存在する。

58 ：デフォルトの名無しさん：04/06/28 23:11

>>57
なるほど。道理でデザパタ＝Javaなわけだ。
プログラマ全てが共通で覚えるだけの価値はないのね。

59 ：デフォルトの名無しさん：04/06/28 23:19

>>56
Ruby の例で悪いけど、singleton や observer は標準ライブラリとして使える。
動的型言語だとデザパタと同等の効果をごり押しで実現できちゃったりするので、
Java くらいの言語の方が適用しやすいというのは言えるかもね。

60 ：デフォルトの名無しさん：04/06/28 23:23

>>58
プログラマすべてが知ってる必要はないかもしれんが、オブジェクト指向の言語やるなら知ってたほうがいいと思うけどね。
つーかデザインパターンの本家はSmalltalkだったと思うが。

61 ：57：04/06/28 23:33

>>58
> なるほど。道理でデザパタ＝Javaなわけだ。
そこまでは言ってないが。GoF のデザパタ本も、取り上げてる言語は
smalltalk と C++ だし。

62 ：デフォルトの名無しさん：04/06/28 23:36

しかしC++使いでデザパタは聞かんな
boostとかlokiとかライブラリの話は良く出るのに

63 ：デフォルトの名無しさん：04/06/28 23:46

C++でもObserver や、Singleton、Adapter、・・・結構つかうぞ。StateやStrategyがなかったら死んじゃう。
Visitor とかは、STLつかっちゃうから、デザパタとはずいぶん違う形になっちゃうけど。

64 ：デフォルトの名無しさん：04/06/28 23:48

パターン名知らなくてもやってるってことはあるからな
アンチデザパタの意見がそれだし

65 ：デフォルトの名無しさん：04/06/29 00:31

Cで、関数ポインタを用いた多態を利用していたら、ソリャ多分Strategyとか
Stateだよ。いままでそう呼んでいなかっただけっさー。

66 ：デフォルトの名無しさん：04/06/29 01:58

C++使いの漏れが使うもの
AbstractFactory
＠Singleton
Decorator
＠Composite
＠Facade　　　　　
Command
＠Observer
State
＠TemplateMethod
Visitor

＠付きは必須

67 ：デフォルトの名無しさん：04/06/29 07:44

>>62
デザパタは使えて当たり前なんで、Java厨と違っていちいち騒がない。
とか。
まあsmart pointerを伴わないと使いにくいパターンはある。
temlateを駆使したやつはC++独自のデザインパターンとも言える。
（パターンは言語非依存のものしか認めんとか狂ったこと言わない限りは。）

>>66
Adapter・Flyweight・Mediator・MementoもC++で無理なく使えるね。

68 ：67：04/06/29 07:46

Bridgeもか

69 ：デフォルトの名無しさん：04/06/29 11:20

>Observer や、Singleton、Adapter

知らなくても使ってしまうう技法だけど、
それをデザインパターンを使っている例に分類するのはどうかと。

>StateやStrategy

GoF式のStateって使う、、、かなぁ？

70 ：デフォルトの名無しさん：04/06/29 12:14

>69
作るアプリやその人の好みで使うパターンが異なるからそんなもんだ。
FlyWeight使えそうだけど自分で使う場面に合ったことないし

71 ：titti：04/06/30 00:13

誰か　Abstract Factoryパターンの適用範囲教えてくださいませ。

72 ：デフォルトの名無しさん：04/06/30 00:20

機種依存のあるコードをそうでない様にラップするだけじゃないかな

73 ：デフォルトの名無しさん：04/06/30 00:48

>>69
パターンとして知らなくても問題とフォースから定型的に解放を導き出しているのなら
使っているといえる。
そうではなくて毎回再発明していてたまたま同じ解放になっているだけなら
使っているとはいえない。

Stateパターンはオブジェクトの振る舞いが動的に変わるときによく使う。

74 ：デフォルトの名無しさん：04/06/30 01:15

×解放
○解法

75 ：デフォルトの名無しさん：04/06/30 17:46

>>73
Stateはジェネレータ使ったほうが保守性も可読性もよくなるっしょ

76 ：デフォルトの名無しさん：04/06/30 22:01

>>75
コードジェネレータか。それはそれで融通が利きにくくなったりして微妙な
場合もあるが、有効な場合も多いやね。

俺は Quantum Framework (http://www.quantum-leaps.com/) の階層型
状態遷機械の実装移部分だけ切り出して template ベースで書き直した
ものを使ってる。

コードジェネレータ使おうがフレームワーク使おうがどっちでも良いけど、
階層型の状態遷移と入退場動作なんかをサポートしてないとキツい。
そのあたり GoF の State パターンは何も示してないので、そのまま
使ってる人は少ないと思うよ。

77 ：デフォルトの名無しさん：04/06/30 23:31

大半のパターンは、単純にクラスとクラスの関係ではなく
かならずインターフェイスとインターフェイスの関係をパターンとして作って
そのインターフェイスをインプリメントしたクラスを使っているか、

仮想クラス同士の関係を作ってからそれを継承した具象したクラスを使っている。

使いたいクラス同士を直接関係させてパターンに当てはめれば早いのにと思うのです。

78 ：デフォルトの名無しさん：04/06/30 23:40

>>77
> 使いたいクラス同士を直接関係させてパターンに当てはめれば早いのにと思うのです。
インターフェースと実装を分離することによるメリットが実感できない？
これはわりと OOP のキモなんだけど、ある程度の規模もしくは寿命を
持つプログラムじゃないと、手間ばっかりかかるように見えちゃうかも
知れず。

79 ：デフォルトの名無しさん：04/07/01 00:54

ある程度規模が大きくならないとメリットが見えてこないことはあるだろう。

80 ：デフォルトの名無しさん：04/07/01 06:56

なんらかのスーパークラスかインターフェイスを１つも持たない具象クラスを作成してはいけない。
それを許した時点でプロジェクトは破綻する。

81 ：デフォルトの名無しさん：04/07/02 00:30

>>80
そういうときは力技でどうにかするみたいですよ。

82 ：デフォルトの名無しさん：04/07/03 09:48

デザパタ使いたいがためにデザインするのはアレです案。

83 ：名無しさん＠そうだ選挙に行こう：04/07/11 11:40

>>69
GoFのStateは実装方法がダサいんでまったく使わないな。
いや、いつもまず試すんだけど、やっぱ止めってなる。

84 ：名無しさん＠そうだ選挙に行こう：04/07/11 12:22

>>83
要約すると、

私は賢い。

でいいんですか？

85 ：名無しさん＠そうだ選挙に行こう：04/07/11 20:14

思うんだけど、デザインパターンって何でもかんでもGoFのデザインパターンで
解決ってのを前提にしすぎてない？
色々、考えた結果、GoFのデザインパターンは使わない泥臭い実装っていうのも
ありだと思うのよ。全て教科書的な問題ばかりじゃないから。

86 ：デフォルトの名無しさん：04/07/11 20:32

>>85
と、GoF本の序章に書いてありますね。

87 ：デフォルトの名無しさん：04/07/11 20:49

>>85
そういう考えなのはテザパタ初心者かアンチデザパタのいずれか。
初心者なら習作としてとりあえずそういう態度で臨むのも意義がある。
アンチデザパタは視野が狭いだけ。

88 ：デフォルトの名無しさん：04/07/11 20:53

>>87
取りあえずお前はGoFに謝っとけ。

89 ：デフォルトの名無しさん：04/07/11 20:57

>>87
儲？

90 ：87：04/07/11 21:40

>>88
あ～、「そういう」ってのは
>思うんだけど、デザインパターンって何でもかんでもGoFのデザインパターンで
>解決ってのを前提にしすぎてない？
この部分な。

91 ：デフォルトの名無しさん：04/07/11 21:52

>>90
今度からは補足しなくても誤解のない文章を書きましょう。
あなたの仕様書でプロジェクトはてんやわんやです。

92 ：デフォルトの名無しさん：04/07/11 22:32

いまさらデザインパターンかよ。
時代錯誤も甚だしい。
VB6なみに消えかかってるよ。

93 ：デフォルトの名無しさん：04/07/11 22:58

>>90
似て非なる実装をしたら、それは亜種であって別の名前がつくべきだろ？
たとえばpush型Observer/Multicastの差は、後者が別の名前を付けて、
統一的な実装方法を示しているあたりだけじゃないか。

頑なにGoFに拘るのは馬鹿かもしれないけど、
最適の解が他にあったとしても、多少の無理や妥協で
リファレンス（GoF）の実装で実現できるならそうするべき。

Stateの亜種をStateといっても、正確に他人との意思の疎通が図れるとは限らないからな。

94 ：デフォルトの名無しさん：04/07/11 23:03

>>93
GoF が提示したかったのは「パターン」であって「実装」ではないということは、
読めば分かるはずだが……。

95 ：デフォルトの名無しさん：04/07/11 23:16

>>94
「実装」じゃなくて「実装方法」な、それくらいは読み取ってくれ。

96 ：デフォルトの名無しさん：04/07/11 23:26

>>95
今度からは補足しなくても誤解のない文章を書きましょう。
あなたの仕様書でプロジェクトはてんやわんやです。

97 ：デフォルトの名無しさん：04/07/11 23:33

>>91
補足しなくて済む仕様書なんて今まで見たことねぇや
そこをきっちり読み取れるか読み取れんかが
土方プログラマと使えるプログラマの差だろ？

98 ：デフォルトの名無しさん：04/07/11 23:34

(´д｀)ｺﾞﾌｯｺﾞﾌｯ

99 ：デフォルトの名無しさん：04/07/11 23:37

>>96
開き直るのはアレかもしれないが、それはただの揚げ足鳥とゆーものだろう。
ましてや仕様ではなく、掲示板上の駄文のひとつでしかないんだしさ。

100 ：デフォルトの名無しさん：04/07/11 23:42

みんGOF

101 ：デフォルトの名無しさん：04/07/11 23:52

デザパタをマニュアル扱いする奴は馬鹿...

102 ：デフォルトの名無しさん：04/07/11 23:57

>>101
その通り。

103 ：デフォルトの名無しさん：04/07/12 00:08

馬鹿ばっかだな。

104 ：デフォルトの名無しさん：04/07/12 00:56

そういえば，つい先日（っていっても1,2ヶ月前かな？）に
dat落ちしたデザパタスレがあったはず・・・

105 ：デフォルトの名無しさん：04/07/12 01:18

>>104
デザインパターンの単純そうな質問
ttp://pc5.2ch.net/test/read.cgi/tech/994836140/

106 ：デフォルトの名無しさん：04/07/12 01:44

>>105
あ，それそれ．ありがとう．

107 ：デフォルトの名無しさん：04/07/12 04:03

>>93
>頑なにGoFに拘るのは馬鹿かもしれないけど、
>最適の解が他にあったとしても、多少の無理や妥協で
>リファレンス（GoF）の実装で実現できるならそうするべき。

自分の仕事の目的が最適の解を実装する事なら、最適の解をえらぶべき。

趣味ならいいけどね。

108 ：デフォルトの名無しさん：04/07/12 04:28

GoFより beck のベスト・プラクティス・パターンの方が役立つと思うのはオレだけだろうか・・・
あと、リファクタリングとテストパターン。

>>38なんか>>48みたいに実装する利点がこの時点ではあまり無いから>>38のままで良いし
もっと動的に数多く Editor が必要になる時にリファクタリングを掛けて>>48にするのが実践的でしょ

リファクタリングの方向性としてGoFのパターンを使うのは良いけど、最初から型として使っちゃうのは
ウォーターフォール開発とたいして変わらん気がするなぁ
必要な時に必要な実装をする
これが一番無駄がないと思うんだが

109 ：デフォルトの名無しさん：04/07/12 10:02

>>108
あとTDD本も入れといて
ﾉｼ

110 ：デフォルトの名無しさん：04/07/12 10:05

>93
いまみた。阿呆ですか?
何でわざわざマニュアルに当てはめないといけないんだ?

111 ：デフォルトの名無しさん：04/07/12 13:30

ところでGoFってなんて読むの
俺ずっとゴフって読んでるんだけど

112 ：デフォルトの名無しさん：04/07/12 16:54

>>110
どこがアホなんですか？

>何で
最後の一行に書いてありますが。

デザインパターンは解決手法というよりも、
統一的な認識を得るために各手法へ名前を付けたことが重要なのであって、
それを達成するには多くの人が見慣れた形のコードを書くべきだと思いますが。

そうでなければ、Multicastパターンに新たに名前が付けられた意味がありません。

113 ：デフォルトの名無しさん：04/07/12 17:24

＞112
＞デザインパターンは解決手法というよりも、
＞統一的な認識を得るために各手法へ名前を付けたことが重要なのであって、

ここの前提が自分とは違っています。
あくまでもデザパタは考え方の一つをあらわしたものでありこれがすべてではないと考えてます。
話をするときはOberverみたいにとかはなしますけど、Observerでなければならないという使い方はしていません。
設計や実装においてもある程度の共通認識ができればいいのであって､原理主義的になることはないと思います。
うちでつかってるObserver(みたいなもの)はテンプレートを多用してファンクターを取り入れ型安全性と条件分岐を排除したものとしています。
またイベント配布などの優先順位なども考慮したある意味余計な機能もつけてます。
けれども本質はSubjectとObserver間の依存性を排除したイベント配信という意味では問題ないと思います。

Multicastパターンをあえて別にしていることはあまり重要には思えません。
うちの知り合いの中では8割が区分けに意味ないと話してます。

114 ：デフォルトの名無しさん：04/07/12 17:25

＞１１３
型安全性と条件分岐を排除したものとしています。
↓
型安全性を取り入れ条件分岐を排除したものとしています。

orz...

115 ：デフォルトの名無しさん：04/07/12 18:48

>>108
「もっと動的に数多く Editor が必要になる時」って具体的に幾つをイメージしてる？
ケースバイケースだろうが、リファクタリング的には「数多く」の基準は2個だと思う。
だから>>48の解は正しい。

116 ：デフォルトの名無しさん：04/07/12 20:30

>>67
> >>62
> デザパタは使えて当たり前なんで、Java厨と違っていちいち騒がない。
かなり傲慢だな。騒いでいるC/C++厨が腐るほどいるのは事実だが

117 ：デフォルトの名無しさん：04/07/12 20:40

使ってて当たり前でも周りの奴が積極的に使ってくれないと
まともに使えない。騒ぎたくなる理由はそこにあるんじゃなかろうか。
他の奴にも使って欲しい。使ってくれれば開発効率が格段に向上すると。

118 ：デフォルトの名無しさん：04/07/13 00:54

＞統一的な認識を得るために各手法へ名前を付けたことが重要なのであって、

「ここはシングルトン　み　た　い　にこんな　感　じ　で　実装すれば良いんじゃない？」

こういう用法で使うのが基本。

119 ：デフォルトの名無しさん：04/07/13 01:09

>>115
それは違うと思う。
数多くの基準が2個なのはコードの重複であって
制御構文をポリモーフィズムに変換するのは別
リファクタリング本見ればそれは解るよ

120 ：デフォルトの名無しさん：04/07/13 20:45

>>118
つまり、シングルトンっぽい気がするけど本当のシングルトンだかどうだか自身がない。
だからなんとなく「シングルトンで」とは言えずに「シングルトン　み　た　い　に」とか
「シングルトン　の　よ　う　に」とか「シングルトン　っ　ぽ　く」とか言うわけだ。
　

121 ：デフォルトの名無しさん：04/07/13 20:47

シングルトンなんて、そんなにヴァリエーションねーじゃん。

122 ：デフォルトの名無しさん：04/07/13 21:12

「シングルトンっぽく」と言われたら、普通のシングルトンとどこが違うか
確認せずには居られない。

123 ：デフォルトの名無しさん：04/07/13 21:42

>>122
確認すれば済むから問題ない。
シングルトンっぽいからコードも追いやすいし。

124 ：デフォルトの名無しさん：04/07/13 21:57

>>123
しかし確認されたら>>120は困り果てるんだろ？

125 ：デフォルトの名無しさん：04/07/13 23:49

まあなんつーか、つまらん腹の探り愛は止めませんか？

126 ：デフォルトの名無しさん：04/07/14 01:03

>>124
世の中の実装がすべてピカピカのアルゴリズムで構築できりゃ苦労はせん訳だ

127 ：デフォルトの名無しさん：04/07/14 01:09

全部が全部じゃないがデフォルトのパターンのまま使ってることは少ないと思うが．．．
なんかしら拡張機能つけたりしてる。

128 ：デフォルトの名無しさん：04/07/14 09:01

所詮パターンなんだから、”型”でしかないでしょ。
だから120や123のようにバリエーションでてもいいじゃない。
実際118の言ってるのだって、
”シングルトンのように”は”シングルトンをベースにした”って読みかえられるわけだから、
シングルトンをベースにしただけで、ベースにした物もシングルトンと同一でないと
いけない理由もないでしょ。
120はシングルトンがどんなのか判ってないけどシングルトンらしく書いてシングルトンと名乗ってる例と
シングルトンをベースにして変えたのをごっちゃにしてると思うよ。

129 ：デフォルトの名無しさん：04/07/14 09:09

とりあえず、
スレッドセーフでないものは
真のSingletonでないってことでオッケー？

130 ：デフォルトの名無しさん：04/07/14 09:47

バールのようなもの。

131 ：デフォルトの名無しさん：04/07/14 12:04

例えば、スレッドセーフにする必要が全くない場合とか。

132 ：デフォルトの名無しさん：04/07/14 12:06

＞129
スレッドセーフになっかしないぞ。
いわれてみればそうしたほうがいいかも知らんが、今まで全部メインスレッドで初期化しメインスレッドで終了させて宝必要なし

133 ：デフォルトの名無しさん：04/07/14 21:57

>>132
よかったな。

134 ：デフォルトの名無しさん：04/07/14 21:58

つまり、アブストラクトファクトリっぽい気がするけど本当のアブストラクトファクトリだかどうだか自身がない。
だからなんとなく「アブストラクトファクトリで」とは言えずに「アブストラクトファクトリ　み　た　い　に」とか
「アブストラクトファクトリ　の　よ　う　に」とか「アブストラクトファクトリ　っ　ぽ　く」とか言うわけだ。

135 ：デフォルトの名無しさん：04/07/14 22:46

>>134
> 本当のアブストラクトファクトリ
本当の正三角形がこの世に存在しないのと同様、そんなものも存在しない。
もしかしたらイデアの世界にはあるのかもしれんが。

136 ：デフォルトの名無しさん：04/07/14 23:58

>>134
木を見て森を見ないタイプの人間だな。
アナベル・ガトーに合わせたら小一時間ほど説教されるな。

137 ：デフォルトの名無しさん：04/07/14 23:59

>>135
プログラムと正三角形のなにが同様なのだかわかりません。

138 ：デフォルトの名無しさん：04/07/15 00:28

>>137
アホなんですね。

139 ：デフォルトの名無しさん：04/07/15 00:44

ってか、「本当の正三角形」でなく「本当の三角形」なんだが

140 ：デフォルトの名無しさん：04/07/15 00:58

>>132
> ＞129
> スレッドセーフになっかしないぞ。
> いわれてみればそうしたほうがいいかも知らんが、今まで全部メインスレッドで初期化しメインスレッドで終了させて宝必要なし

おまえみたいな香具師がバグを生み出し他人に迷惑をかける。

141 ：デフォルトの名無しさん：04/07/15 00:59

Abstract Factoryはアスペクト指向で欠点が解消されるかな

142 ：デフォルトの名無しさん：04/07/15 01:03

アスペクトＪって実際のプロジェクトで使ってるやついる？

143 ：デフォルトの名無しさん：04/07/15 01:21

>>142
使わなくても良いものは極力使わない。これ基本。

144 ：デフォルトの名無しさん：04/07/15 02:22

当たり前のことをいうな。
それはExtreme Programmingでは常識だ。

145 ：デフォルトの名無しさん：04/07/15 07:08

Extreme Programmingって実際のプロジェクトで使ってるやついる？

146 ：デフォルトの名無しさん：04/07/15 07:36

>>145
「変化を抱擁せよ」だけは以前から使っている。
客と営業がな。

147 ：デフォルトの名無しさん：04/07/15 07:38

キチガイみたいな名前だよなぁ

148 ：デフォルトの名無しさん：04/07/15 12:41

グローブオブファイトのスレですか

149 ：デフォルトの名無しさん：04/07/16 10:24

>>135
同意
本当のハヤシライスがこの世に存在しないのと同様、そんなものも存在しない。

150 ：デフォルトの名無しさん：04/07/16 12:03

>>143
死ぬまで汎用機でＣＯＢＯＬすれ。

151 ：デフォルトの名無しさん：04/07/16 22:45

>>149
激しく同意。

長年追い求めているがなかなかこれと言ったハヤシに巡り会えない。

152 ：デフォルトの名無しさん：04/07/16 23:35

林さんの作ったハヤシライスをお囃子を聞きながら脇毛を生やして食べるのが早し。

153 ：デフォルトの名無しさん：04/07/16 23:38

>>152
良い回分ですな。

154 ：デフォルトの名無しさん：04/07/16 23:41

>>153
逆から呼んじまったじゃネカ

155 ：デフォルトの名無しさん：04/07/16 23:41

回分？押韻じゃねーの？

156 ：デフォルトの名無しさん：04/07/17 18:33

>>152
それはhayashi-riceパターンですな。

157 ：デフォルトの名無しさん：04/07/17 22:01

一つのオブジェクトを使い回すパターン？

158 ：デフォルトの名無しさん：04/07/19 23:08

奥村晴彦氏のアルゴリズム事典の様なものだね。

159 ：デフォルトの名無しさん：04/07/27 21:59

ちなみに皆さん、GOFって普段どう読みます？

　ギャングオブフォー
　ジーオーエフ
　ゴフ

オイラはゴフ

160 ：デフォルトの名無しさん：04/07/27 22:20

グローブオブファイト

161 ：デフォルトの名無しさん：04/07/27 23:47

>>160
オブではなくてオンだろ。

162 ：デフォルトの名無しさん：04/07/28 03:00

ここはヲタクなインターネッツですね．

ちなみに漏れはゴフ

163 ：デフォルトの名無しさん：04/07/28 08:59

(´д｀)ｺﾞﾌｯｺﾞﾌｯ

164 ：デフォルトの名無しさん：04/07/28 09:49

XAMLは？

じぶんはえぐざむる

165 ：デフォルトの名無しさん：04/07/28 12:50

XAML=ザメル

166 ：デフォルトの名無しさん：04/07/28 17:48

どっちにしろこのデカ物はあの船には載りやせんぜ！

167 ：デフォルトの名無しさん：04/07/28 20:25

ここで言っているレイヤーパターンというのは
ttp://pc5.2ch.net/test/read.cgi/tech/1004962559/
どの様なものか、軽く説明して頂けないでしょうか

恐らくこの本に載っているのかなと目星をつけたのですが、今月は貧乏地獄でして…
ttp://www.amazon.co.jp/exec/obidos/ASIN/4764902834/250-2491241-0319464

厚かましい質問なのは重々承知ですので、あれでしたらスルーしちゃってください

168 ：167：04/07/28 20:26

失礼しました、正確にはこのレス番号です
ttp://pc5.2ch.net/test/read.cgi/tech/1087050664/36

169 ：デフォルトの名無しさん：04/07/31 00:23

ファクトリーってみんな使ってる？

170 ：デフォルトの名無しさん：04/07/31 00:24

使ってません

171 ：デフォルトの名無しさん：04/07/31 00:57

>>169
Windows で COM のお世話になってる人間は、みな使ってる。

172 ：デフォルトの名無しさん：04/08/03 17:23

Windowsのドキュメントビュー型プロジェクトにメメントを組み込もうとしてるのだが
アンドゥ対象のデータ（シリアライズ対象）だけドキュメントクラスの派生で作ってメメントクラスをフレンド
にした。

ここでアンドゥの管理クラスをどこに作ればいいのかで止まってる。
アプリケーションクラスだろうか。

MFCとデザインパターンとオブジェクト指向全てにおいてあいまいな知識しかないので
見当違いな質問しているかもしれないが教えてください。

173 ：デフォルトの名無しさん：04/08/03 17:58

>>172
自己レス
アンドゥ対象をドキュメントクラスの派生で作らずに、素のクラス作ればいいわけですね。
自己解決です。たぶん。

174 ：デフォルトの名無しさん：04/08/03 17:59

デザインパターンの勉強にはC++よりJavaのほうが向いていますか？

175 ：デフォルトの名無しさん：04/08/03 18:02

>>174
C++を100 としたら、Javaは107くらいの割合で向いている。

176 ：デフォルトの名無しさん：04/08/03 18:04

そんな感じですか。C一本でやってきたんですがそろそろ限界が見えてきたので(UMLやるにも
COMやるにしてもオブジェクト指向がほぼ必須なので)どっちから入ろうかと考えていました。
ありがとうございます。

177 ：デフォルトの名無しさん：04/08/03 18:08

Ｃを知っているなら、どっちからやっても大差ない。
C++ も Java も文法の難易度はどっこいどっこい（若干Javaがやさしいけど）。

178 ：デフォルトの名無しさん：04/08/03 18:26

C++はテンプレートとか例外安全の保ち方とかがややこしい
のでよく知ろうと思ったら、Javaよりかなり難しいと思う。

179 ：デフォルトの名無しさん：04/08/03 18:47

Javaの範囲内だけなら、Javaの方が若干簡単。
しかしC++にはJavaにない機能がある。

180 ：デフォルトの名無しさん：04/08/03 18:57

Javaとは比較にならない面倒くささと落とし穴もついてきます。

181 ：デフォルトの名無しさん：04/08/03 19:06

C++の面倒くささや落とし穴を全て回避できる程度にC++に熟練しているなら
C++の方が簡単。

182 ：デフォルトの名無しさん：04/08/03 21:17

あ"～～～～～～～
Mementoでアンドゥ面倒くせーって、なんかギャグみたいだな

アンドゥ対象の数だけ、クラスが増えていくんだけど、こんなものなんでしょうか？
templateもあまり使えないし、困ってます。
いまアンドゥ用の状態保存を兼ねたコマンドクラスが51種類ありますよ…。

大体5移動した場合のアンドゥが-5セットするだけ…なんて簡単なの滅多に無いんですよね。
可読性も落ちるし、余計なバグも増えるし…もういやだ…。

183 ：デフォルトの名無しさん：04/08/03 21:30

>>182
お勧めのテクニック。

1.Memento をきっぱり見捨てる。
2.継続をサポートした言語を組み込む。
3.操作する度、状態を保存。

以上。

184 ：デフォルトの名無しさん：04/08/03 21:49

>>183
ｽﾏﾝ、ネタかどうかも判断できなくて。見捨てる覚悟はあり。

継続をサポートした言語ってなんだろう、調べてもさっぱり。
継続ってスタックの事かな？

185 ：デフォルトの名無しさん：04/08/03 22:33

ま、>>184 は俺じゃないので、見捨てるのは一向に構わんが、
最近の言語は、悉く継続を積もうと躍起になっているぞ。

186 ：デフォルトの名無しさん：04/08/03 22:37

オレの実装では、アンドゥクラスを１つ作った。内部はスイッチ分岐。コマンドとかオプションの保存とかも、この方式。
なんでもオブジェクトに担当させようとすると、コードも保守も煩雑で肥大になる。
デザパタ流では、オブジェクトに担当させた方が、保守性・拡張性ともに優れている、という結論になるんだろうが。

187 ：デフォルトの名無しさん：04/08/04 00:12

＞186
俺的に許さん

188 ：184：04/08/04 00:38

>>185
いあ、見捨てるのはMementoをだよ！>>183
馬鹿正直にやるとオブジェクトの粒度が細かすぎるよー。
アスペクト指向とかになると、この辺楽になるのかねぇ。

>>186
俺もそんなんで行こうかなぁ。もう疲れたよﾊﾟﾄﾗｯｼｪ。

やる事がそれぞれ違うのに、ExecuteとUndoだけでやらなきゃだからさ、
なんか凄い無理が出るのよ。例えば最初のExecutまでの情報セットがだらけたり。

あーあ、久しぶりにゲームでも作りたいな。
ﾘﾌﾟﾚｲ機能?ｶﾝﾍﾞﾝ…

189 ：デフォルトの名無しさん：04/08/04 02:26

>>183
継続だと楽にできるの？

190 ：デフォルトの名無しさん：04/08/04 03:06

>>189
相手にしない方が･･･

191 ：デフォルトの名無しさん：04/08/04 06:44

>>189
楽も何も・・・
「前の状態に戻りたい」という「前の状態」とは、
いわゆる「継続」そのものだから。

192 ：デフォルトの名無しさん：04/08/04 07:49

アホはスルー

193 ：デフォルトの名無しさん：04/08/04 07:58

＞182
クラス増えるのはまったく問題なし
２ｃｈブラウザ見たいの作ったら自分の感覚だとクラス数３００－５００ぐらいになると思う

194 ：デフォルトの名無しさん：04/08/04 08:42

>>193
デザパタ厨の的外れなコメント

195 ：デフォルトの名無しさん：04/08/04 10:39

>>182
＞アンドゥ対象の数だけ、クラスが増えていくんだけど、こんなものなんでしょうか？
＞templateもあまり使えないし、困ってます。
＞いまアンドゥ用の状態保存を兼ねたコマンドクラスが51種類ありますよ…。

アンドゥ対象を一つのクラスにまとめてそいつをメンバーに持つクラスを被せて
アンドゥ対象を一つに纏めたクラスはカプセル化を維持したいから、その被せたクラスのフレンドにするらしい。

ttp://member.nifty.ne.jp/yamazaki/doc/cpp_design_pattern.html#Memento

こうするとアンドゥ対象が沢山できるなんてことはないのだけど、なんかフレンドまで使って無理やりデザパタ
に合わせたみたいでいまいちメメントのメリットわからないっす。

ttp://www.hyuki.com/dp/anime/Memento.gif

ギコ猫でもフレンド使えと言ってる。フレンドってなんか構造化言語でGOTO使うような感覚でどうも納得いかない
のだが、こういうものなんだろう。デザパタ本当に良いのか？

196 ：デフォルトの名無しさん：04/08/04 10:40

とりあえずGoF位読めよ

197 ：デフォルトの名無しさん：04/08/04 11:09

デザパタ信者ってのは通常Java厨で、まともなプログラムなんて組んだことがない。
本から得た薄っぺらい知識にすがってるから、本質が全く見えていない。
批判すると反論できないので、理解してないだの、勉強しろだの、無知無能だのといいだす。
くだらん型判定のために、Visitor使って喜んでるような変態が多い。

198 ：デフォルトの名無しさん：04/08/04 11:28

過ぎたるは猶・・・ってやつだと思う。
デザパタなんてカタログだからな。カタログめくるだけで
物は作れないわけで。でも、めくったら新しい発見があるかもしれない。
実際ほとんど作ったこと無いけど設計だけやるような人がいたりもするので驚く。

＞くだらん型判定のために、Visitor使って喜んでるような変態が多い。
このやり方はそんなに嫌いじゃない。適用する場所によるだろうけど。

199 ：デフォルトの名無しさん：04/08/04 11:32

>>196
何読んだら良い？紹介してくれ。

200 ：デフォルトの名無しさん：04/08/04 12:12

そのクラスが増えて困るというのがよくわからんのだけど？

201 ：デフォルトの名無しさん：04/08/04 12:15

んでおまえらが2chブラウザ作ったらクラスすうどのぐらいになるの？

202 ：デフォルトの名無しさん：04/08/04 12:41

>>201
俺ならたったの１個で済ますぜ。
すげーだろ。

203 ：デフォルトの名無しさん：04/08/04 13:24

コマンドパターンはなんか凄そうなことかと思ったがこんなこと
当然だろうと思ってしまった。

今のところなるほどと思ったのはシングルトンだけだな。まだ5つぐらいしか知らん俺が
言うことではないか。

204 ：デフォルトの名無しさん：04/08/04 16:11

>>202
0にできないところがお前の能力的限界だな。

205 ：デフォルトの名無しさん：04/08/04 19:01

中学生が増えてまいりました

206 ：デフォルトの名無しさん：04/08/04 22:21

>>199
http://www.hyuki.com/dp/index.html

207 ：デフォルトの名無しさん：04/08/04 22:35

たった１００行のプログラムで、クラスが２０もあったらどう思う？
何千行のプログラムが、１つのクラスだったら？
クラスが多いと悪いとか、少ないと良いとかじゃない。
適度な粒度と、共通部分の集約が重要。
同じような処理が各オブジェクトに重複して存在するうえ、
処理が全く違う場合でもインターフェイスの統一を強いられ、
その上、粒度が細かくなり過ぎるのが問題だといっている。
保守性は最悪だし、拡張するのも面倒。
拡張時のインターフェイス変更の危険性も増す。
自分でプログラミングすれば、誰でも簡単に見えることも、
本の鵜呑みじゃ見えてこない。

208 ：デフォルトの名無しさん：04/08/04 22:43

＞207
だから2chブラウザ(比較のため適当かと)を作るとしたらどのぐらいになるの？
自分にとっては300ぐらいが適当。
同じような処理は一切存在しないし細かすぎるとも思わない．
大きいクラスもあれば小さいクラスもある．
commandのswitch分岐なんか論外。

209 ：デフォルトの名無しさん：04/08/04 22:48

>>208
数にこだわるなって話だろ
ステップ換算のCOBOLERじゃないんだから

210 ：デフォルトの名無しさん：04/08/04 22:50

Java厨は死ぬまでアンドゥを各オブジェクトに実装してろってこったな

211 ：デフォルトの名無しさん：04/08/04 22:51

いや他の人だとどのぐらいの粒度でやってるのかが知りたくて．
うちの会社では自分の粒度が格段に高かった。
でも他の人の見ると同じようなコードが分散してる気がしました．

212 ：デフォルトの名無しさん：04/08/04 22:52

>>208
Mementoの話でしょう。なんで2chブラウザが(w

213 ：デフォルトの名無しさん：04/08/04 22:54

>>208
2chブラウザと一口に言われても、いろいろだしな。もう少し具体的に、どの機能をどのパターンで実装したら、粒度がどうなったくらいまで書いてくれないと。

214 ：デフォルトの名無しさん：04/08/04 22:57

いや、大体推定で．．．
自分はJaneStyleを基準にして考えたんだけど

215 ：デフォルトの名無しさん：04/08/04 23:02

>>211
会社って事はデタラメなコード書いてる奴らばっかりってことだろ。
それなら>>211が格段に細かくても当たり前だと思う。

構造化からオブジェクト指向に入った人は、
初めのうちはクラスの数が少なくなりがちだから。

216 ：デフォルトの名無しさん：04/08/04 23:03

Javaを使ってる若い人は可哀想だと思うよ。
日教組に自虐教育をうけた小学生みたいでさ。
状況に応じて自分で考えることが出来ない。
static悪、分岐悪、コンポジット最高みたいにさ。

217 ：デフォルトの名無しさん：04/08/04 23:16

目的は良いソフトを作ること
そのための道具の１つとしてデザインパターンが使えるなら使う
間違ってもデザインパターン流にソフトを作ることが目的じゃない

218 ：デフォルトの名無しさん：04/08/04 23:46

>>216
そりゃ単にあんたが年を食って、若い連中に知った風な事を
言いたくなっただけだよ。言いがかりだな。
昔は継承による差分プログラミング最高だったわけだが、
だからといって自分で考えられなかった訳じゃないだろ。
今の若い連中だって、考える奴は考えるし、考えない奴は考えない。
当たり前じゃないか。

219 ：デフォルトの名無しさん：04/08/05 00:18

てか、若い人がダメなんじゃなくて、Java厨がダメなんでしょ。

220 ：デフォルトの名無しさん：04/08/05 00:22

教育機関でのJavaの学習が洗脳的だってこと?

221 ：デフォルトの名無しさん：04/08/05 00:35

Javaを教えてる人が
GOF読んだだけでほとんど
プログラムしたことないってのが
一番問題なんじゃ

222 ：デフォルトの名無しさん：04/08/05 00:37

>221
んなことねーだろ．．．

あるのか？

223 ：デフォルトの名無しさん：04/08/05 00:48

おれ工房だけど、うちのがっこの場合、せんせはデザインパターンなんて知らない。
Javaの文法と、サンプルコードを実行するまでの手順がわかるってくらい。
わかんないこととか、授業中におれに聞いてくることあるもん。

224 ：デフォルトの名無しさん：04/08/05 00:59

>>218
＞差分プログラミング最高だったわけだが、

そんな時代はなかった。

225 ：デフォルトの名無しさん：04/08/05 01:01

たたいマンセー

226 ：デフォルトの名無しさん：04/08/05 01:12

>>223
＞わかんないこととか、授業中におれに聞いてくることあるもん
そんな風に親近感を持たせつつ生徒に歩み寄る
美人女教師はそうそういない。大切にしろよ。

227 ：デフォルトの名無しさん：04/08/05 01:18

>>179
> Javaの範囲内だけなら、Javaの方が若干簡単。
> しかしC++にはJavaにない機能がある。
といっても、デザインパターンで設計するうえでは
C++にある機能ってのはオブジェクト指向的に必要のないものばかりだが。

228 ：デフォルトの名無しさん：04/08/05 02:25

Java厨はやっぱデザパタ的にプログラミングするのが目的だったってオチ？
そりゃデザパタの功罪なんて話は無理だわな

229 ：デフォルトの名無しさん：04/08/05 06:50

目的がオブジェクト指向やデザインパターンって・・・
いつの間にか手段が目的と化してる

すると何かを実現するためにプログラミングするんじゃなくて
プログラミング自体が目的なのか？

プログラムが動いて何かを実現するよりも
自己満足のソースを眺める方が重要なのか？

230 ：デフォルトの名無しさん：04/08/05 07:23

このスレは、デザインパターンを理解出来ない低レベルプログラマーが
必死で活動するスレですか？

231 ：デフォルトの名無しさん：04/08/05 08:09

>>230 その言葉を待ってました。ﾜｰｲヽ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)ノﾜｰｲさ出かけるか(w

232 ：デフォルトの名無しさん：04/08/05 08:14

どうせデザパタをまともに語れる奴なんていないんだろ。ﾌﾟｯ
お前らみたいな無知無能がオブジェクト指向なんてできるわけがない
まずは批判する前に勉強しろ

233 ：デフォルトの名無しさん：04/08/05 10:13

デザインパターン使い始めるとクラス数は明らかに増える傾向にあるな。
特にCommandパターンなんて、今までならOnOpenDocument内に直に実装していたのに
わざわざクラスにするのだからな。

234 ：デフォルトの名無しさん：04/08/05 10:15

>>229
>すると何かを実現するためにプログラミングするんじゃなくて
>プログラミング自体が目的なのか？

プログラマとしては正しいと思う。
職業プログラマとしてはダメダメだけど。

235 ：デフォルトの名無しさん：04/08/05 10:48

>>234
プログラムが綺麗なだけで自己満足できる人はいないだろう。
どんなプログラマーでも正しい動作することは必須条件。

俺は最低限コメントさえ詳しければいいと思うよ。デザインパターンの有無はともかく。

236 ：デフォルトの名無しさん：04/08/05 11:37

>>235
>プログラムが綺麗なだけで自己満足できる人はいないだろう。
>どんなプログラマーでも正しい動作することは必須条件。
それは確かに必須条件だな。
が
>俺は最低限コメントさえ詳しければいいと思うよ。デザインパターンの有無はともかく。
その前にやっぱり漏れはプログラムが綺麗で素直な事が重要だと思うよ。
綺麗で素直（コードの書き方にトリックプレイとかなく淡々と書いてある）なコードは
保守しやすいし、読みやすい。
なによりそんなコードだとバグの入る率が激減するからな。
その上でコメントかな。
ソース＝コメントって考え方もあるんだし。

237 ：デフォルトの名無しさん：04/08/05 16:29

ソースはコメントになりうるが、コメントはソースにはなれん

238 ：デフォルトの名無しさん：04/08/05 16:52

なぁ、素敵なナイスガイ様たち、ちょっとバシッと答えてくれまいか
Windowsプログラムで、かつC++の話なんだけどさ

1、素のままだろうが、MFC/ATL/WTLだろうが、全てのWM_メッセージは結局
　　プロシージャか、それの代替コントロールクラスに集まるよね。これをCMainクラスとする。
　　するってぇとCMainは、イベントを受け取って実際に動くクラス(通知先クラス)を全て持ってなければなのだろうか？

2、同じWM_LBUTTONDOWNでも、状態によってやること(通知先)が違う。
　　ここでstateパターンでも使ってみたくなるけど、実際に通知先クラスを持ってるのはCMain。
　　stateクラスからCMainが持つ通知先クラスには当然アクセスできない。
　　こうなるとCMainが、その中身を使わせるためのメソッドを全て用意しなきゃなのだろうか？Mediator？friend？

例えばここでMVCモデルとか持ち出されても、実際にどうやるか良く分からないんだよねぇ…。

239 ：デフォルトの名無しさん：04/08/05 18:51

> 特にCommandパターンなんて、今までならOnOpenDocument内に直に実装していたのに
電波ｷﾀ━━━━ヽ(`ζ.´)ﾉ━━━━!!!!

240 ：デフォルトの名無しさん：04/08/05 20:53

Java厨って、デザパタ以外

　　　な　　　に　　　も　　　知　　　ら　　　な　　　い　　　ん　　　じゃ？　　　(w

241 ：デフォルトの名無しさん：04/08/05 21:00

よくいるデザパタ馬鹿

デザインパターンが大層なもんみたいに勘違いして
必死こいてなんとか読んだ自分が出来る奴だと勘違いして
間違いを指摘されると反論も出来ずデザパタ分かってないとか言いだして
挙げ句はデザパタ以外何も知らない自分をさらけ出しちゃって
職業プログラマならデザパタなんて土日で読める程度のもんなのに

242 ：デフォルトの名無しさん：04/08/05 21:24

>>240-241
そういう事にしてやるから消えろ。

243 ：デフォルトの名無しさん：04/08/05 22:06

>>238
MFCは chain of responsibility だったと思う。

244 ：デフォルトの名無しさん：04/08/05 22:18

Ａ「デザインパターンっていいよね」
Ｂ「プッ、デザインパターンで全てを解決出来ると思ってる馬鹿ハッケーン」
Ａ「いえ、別にそんなこと思ってません」
Ｂ「ワハハ、何も出来ないんじゃん。やっぱりデザインパターンって用無しだね　プッ」

245 ：デフォルトの名無しさん：04/08/05 22:29

まぁきちがいとは会話できないってこった

246 ：デフォルトの名無しさん：04/08/05 23:07

Ａ「Mementoだとオブジェクトの粒度が細かくなるよね。」
Ｂ「クラス増えてもいいだろ。2chブラウザならクラスいくつになるんだよ。」
Ａ「なぜ2chブラウザ？　だれかクラス数の話した？　聞きたいなら、どの機能がどのパターンだと粒度がどうくらいまで書いてくれないと。」
Ｂ「昔は差分プログラミング最高で、コマンドはOnOpenDocument内に直に実装してただろ。とりあえずGoF位読めよ。」
Ａ「・・・」

247 ：デフォルトの名無しさん：04/08/05 23:14

>>246
細かいニュアンスとか会話の流れが捏造されてるぞ。
朝日新聞みたいなまねはするな。

248 ：238：04/08/05 23:52

>>243
いや、それはMFCがメッセージをディスパッチする仕組みの事だよね？
俺が知りたいのは、その結果の使い方なんですよ。

といってもレス来そうにないなぁ、こりゃ…。

249 ：デフォルトの名無しさん：04/08/06 00:26

>>248
回答としては、1と2ともにNo。もう少しSDKプログラミングの基礎学習が必要。
（メッセージループからやり直せ。）
Windowsの流儀を学んだうえで、デザパタ流にすることは出来るけど、
流儀を知らずにデザパタだけは無理。

250 ：238：04/08/06 00:44

>>249
もちっと具体的に言ってくれぇ。
メッセージループの仕組みなんか知ってるよ。
実際はでも生のまま叩かないだろ？WTLなり使うわけだ。
まさか昔のぷよーん氏の様にフレームワークから自作しろってのかい。

流儀とか基礎学習とか、曖昧なだけでもう
こういっちゃなんだが、威張りたいだけに見えるよ…。

251 ：デフォルトの名無しさん：04/08/06 00:55

>>250
そう思うならさっさとこのスレを見限ってどこかの優しいお兄さん達の集まるBBSなりMLに行けばどうだ？

252 ：デフォルトの名無しさん：04/08/06 00:58

MFCなりWTLを使っておいてわざわざデザパタ流にする意味ないと思うけどな。

253 ：デフォルトの名無しさん：04/08/06 00:59

>>252
それこそ目的と手段がごっちゃになってるよな。

254 ：デフォルトの名無しさん：04/08/06 01:06

>>250
べつにWTL使っていいんだけど、WTLでのメッセージループの実装、ソース見た？
>>238 の1や2みたいな見当違いだと、メッセージループの仕組み、分かってないやん。
>>238 の文章で伝わるのは、Windowsプログラミングをしたことがないのに、
デザパタ流でWindowsプログラムをしようとして、右も左も分からないって事くらい。

255 ：デフォルトの名無しさん：04/08/06 01:07

>>254
だからデザパタありきで何かやろうとすんなよ。。。

256 ：254：04/08/06 01:09

>>255
やろうとしてないけど（藁

257 ：デフォルトの名無しさん：04/08/06 01:12

>>255-256
>>244のパターン

258 ：デフォルトの名無しさん：04/08/06 01:15

いつも言われてるので　たまには人に言いたくなった by Java厨

259 ：254：04/08/06 01:17

>>257
>>244 って可哀想な人やん（藁

260 ：238：04/08/06 01:19

おお、流れが変わった。

>>252-253
まてまて、それじゃ生のままで構わないよ。
俺もMFCとか実際に使ったことないしな。

でもさ、わざわざ自作してメッセージをマップしたり、
継承可能なWindowクラスを作っても、結局同じものになると思うのよ。俺ごときじゃ。
>>252氏のやりかたが、どんな感じなのか教えてくれ。煽りじゃなく本気で。

>>254
みたみた、この板で一時期話題になったマッピング方法と大体同じだね。ってもうスレ無いや。
本当に良くできるよ。とても自分で作る気にはならないっす…。

261 ：254：04/08/06 01:21

べつにWTL使っても、デザパタのエッセンスは生かせると思うよ。
やったことないけど（藁
それともWTLをデザパタ流に書き換えないと、デザパタ使ってる意味無いって話？

262 ：デフォルトの名無しさん：04/08/06 01:24

>>238
Win32APIスレの誤爆はあなた？

263 ：デフォルトの名無しさん：04/08/06 01:24

>>261　Java厨のいうことをまにうけちゃだめ(w

264 ：デフォルトの名無しさん：04/08/06 01:46

MFC、．NETともどもデザパタつかって独自フレーム作ってますが？
別にデザパタに限るわけじゃないけど
キーボードのルーティングとかchainなんたらといえなくもない

265 ：238：04/08/06 01:51

>>261
いや、そんなことないんですよ。そのまま使えればハッピー！楽したい！なので。
でもねぇ、なんだか一つのクラスが肥大化しすぎちゃいましてねぇ…。
この辺の既成クラスを使ってる人はどうしてるのかなぁと。

>>262
誤爆じゃないけど、なんか名前残ってて。ｽﾏｿどこか間違ってたかな。
OSを～ってのは、ちと切り分けが面倒だった記憶がありまして…使えないOSがあるって訳じゃないので。

関係ないけど>>248の「レス来そうにないな」は荒れてたからです。
248氏に言った訳じゃないので。紛らわしくて申し訳ない。

266 ：デフォルトの名無しさん：04/08/06 02:04

>>238は具体的に何が知りたいのか良くわからない。
メッセージを受け取るCMainが適当な粒度の
通知先クラスを集約してる形じゃ不満だということなのか？

2で言ってるstateクラスってのもどのレベルの状態切り替えかわからない。
アプリ全体に関わる状態だったらCMainとやらが持っていてもいいだろうし、
もっと小さいレベルならCMainが持つ通知先クラスの中の実装を
差し替えたりすればいいことのように思うんだけど。

267 ：デフォルトの名無しさん：04/08/06 02:43

デザパタって結局考え方集だろ？

つまみ食いするだけならめちゃ便利だよな

268 ：238：04/08/06 03:51

>>266
お付き合いありがたいっす。>>238確かに非道い！例えば通知先クラスって言葉が悪すぎ。
「イベントが来たとき実際に操作するクラス」のつもりでした。すいません、具体的に話し直すっす。

以前書いた描画アプリを、要望に応えてバージョンアップさせるのが目的なんです。
これがまたプロシージャに自動書記で直書きしたような奴でして、まず見やすいように成形しなおしたく思ってます。

状態は、「今、どの描画ツール(ブラシなど)を使っているか」です。たぶんアプリレベルですね。
結構複雑なキー・マウス操作もありますので、恐らくウィンドウメッセージ通知先の粒度は、
この描画ツールごとが良いと思いました。これをNotifiedClassとします。うぉ地震だ。

問題なのは、このNotifiedClassAとNotifiedClassBとが、共通のオブジェクトを
扱わなければ行けないことなんですよ。オブジェクトは例えばBlushやLayerなんてのです。
決して珍しいケースじゃ無いと思うのですが…。

結局こうなると、BlushやLayerを集約して管理するクラスが必要で、
管理クラスからNotifiedClassへは、get/setを始め豊富なメソッドをご用意って
うわそれ、NotifiedClass意味ないじゃん。助けて！っていうかすいません眠くて思考がもう。

269 ：デフォルトの名無しさん：04/08/06 04:07

>>268
地震ﾜﾗﾀ

270 ：243：04/08/06 04:42

見てない間にこんなにﾚｽが
>248氏に言った訳じゃないので。紛らわしくて申し訳ない。
ん? 俺宛てか? 俺も「なんかいやな流れの中で書いちゃったかな」とか思ってた。

>みたみた、この板で一時期話題になったマッピング方法と大体同じだね。
が、よくわかんないけど、メッセージの処理はMFCでのコマンドルーティング
で使われているような chain of responsibility や、.NET系や最近の言語に
多い Delegation って、いうのかな、その2種類が主流っぽい。
他にあったら教えてくれい。

MFCとか使ってるわけでないなら、自分で Chain... 実装して状態
>「今、どの描画ツール(ブラシなど)を使っているか」です。
ごとにメッセージを処理するクラスを作っておいて
今、選択しているツールのメッセージ処理クラスを chain で
通るようにすればよい。複数の要素があっても複数を chain で
つなげればよいはず(もちろん複数前提で実装しなければいけないが)
でも、Layerって、表示レイヤー? なら visitor の方が普通かな?

しかし、MFC使ってたらこのへん(chain)融通利きにくそうなので
メッセージ処理クラスを chain に追加するのは難しそう。
wxの方がやりやすそうだった。

あくまで個人的な意見なので参考程度にしてください。

271 ：デフォルトの名無しさん：04/08/06 06:34

どのライブラリのメッセージ機構使ってもメインにぶら下げる必要なし

272 ：デフォルトの名無しさん：04/08/06 10:17

>>239
あーすまんが、この発言のどこら辺が電波なのか教えてくれ。>233は
アンチパターン「ゴールデンハンマー」にはまっているだけだと思うのだが。

俺もOnOpenDocumentなんて大抵直書きするが

273 ：デフォルトの名無しさん：04/08/06 10:35

＞233
はCommandとEventを受けたところでなに書くかということを混同してる

274 ：デフォルトの名無しさん：04/08/06 11:29

>>268
なんとなく見えてきた・・が、微妙なので俺なりの回答を書いてみる。
描画アプリは描画するツール（ブラシなど）と描画対象（Layerなど）が
連携して動作するから、CMainはToolとCanvasを集約していて、
Toolは内部に複数の実装（ブラシやペンなど）を持ち、切り替え可能にする。
stateになるのかな？違ったら誰か突っ込んで。

基本的にCMainは今どの描画ツールが選択されているかとか
どのレイヤーがアクティブかなんてことは気にしなくて良いもののはず。
（アプリの仕様にもよると思うけど）

とりあえずToolとCanvasの各実装は後回しにして
Toolを実装したBrushとCanvasを簡単に実装したCanvasImpl
みたいのを作って設計を固めると後がやりやすいと思う。
一対一で動作が確認できればあとはToolをcompositeっぽく
実装したクラスを作って楽ができるような気がする。

275 ：デフォルトの名無しさん：04/08/06 13:13

>>274
簡単なプログラムをわざわざ難しくしているようにしか見えないのは俺だけ？

276 ：デフォルトの名無しさん：04/08/06 13:40

＞275
そうしたほうがいいときもある．必要のないときもある．

277 ：デフォルトの名無しさん：04/08/06 13:51

クラスの数を増やして自分の生産性の高さを経営者に示す

278 ：デフォルトの名無しさん：04/08/06 13:58

>>275
難しく見えるなら簡単な方法で作れば良い。

279 ：デフォルトの名無しさん：04/08/06 14:00

趣味グラムとか後々資産にするためならば病的なまでに粒度細かくする
やっつけはしらん

280 ：デフォルトの名無しさん：04/08/06 14:05

とりあえず動けばいいだけのプログラムになんか頭使うの無駄だしな。
何かもっと上のものを望むときにだけ労力使いたいし。

281 ：デフォルトの名無しさん：04/08/06 17:46

脳の中もループしてるよ、良かったね。

大脳基底核：脳幹と大脳皮質の間に位置する神経回路。
入力部の「線条体」は大脳皮質からの興奮性の入力と、中脳からのドーパミン性の入力を受ける。
その出力は複数の抑制シナプス結合を経て大脳皮質に戻されるループ構造を持つ。
大脳皮質-基底核ループは、運動野、前頭前野など異なる皮質領域を投射先とする
並列的な構造を持つことが、近年の解剖学的研究により明らかになった。

282 ：デフォルトの名無しさん：04/08/06 21:48

>>224
おまえが無知なだけ。９０年代初頭の雑誌でもあさってみろ。
よく知らないのに「なかった」とか言い切るのはアホの所業だぞ。

283 ：デフォルトの名無しさん：04/08/07 02:00

>>218 = >>233 だろ。こいつ馬鹿なのに粘着で、すくいよう無し。ム板から消えてくれ。

284 ：デフォルトの名無しさん：04/08/07 08:42

>>282
お前90年代に現場にいなかったろ？

その先にあったのは地獄と焼け野原だけだ・・・。

285 ：デフォルトの名無しさん：04/08/07 08:43

>>279
そのコンポーネントの90%が使用されることなく忘れられていく訳だ。
で、また同じモノを作る。良くある話で。

286 ：デフォルトの名無しさん：04/08/07 08:52

>>284
いや、いたぞ。だが、仮にいなかったとしてだから何？
無関係な事を関係ありそうに言うな。詭弁かよ。くだらねえ。

287 ：デフォルトの名無しさん：04/08/07 08:55

>>286
んじゃそのころCOBOLでも使ってたんですか？

288 ：デフォルトの名無しさん：04/08/07 09:31

>>283
ソイツが一人でこのスレのレベル落としてるのは事実だが
お前にｷｴﾛとまで言う資格あるか？

289 ：デフォルトの名無しさん：04/08/07 09:38

>>288
初級シスアドじゃダメですか・・・？

290 ：デフォルトの名無しさん：04/08/07 12:43

＞285
いやそんなことないぞ。
まぁおなじようなものつくってるせいもあるけど。

291 ：デフォルトの名無しさん：04/08/09 10:05

なんかJava厨の考えが分かってきた

目的
ソフトで現実のメリットを得る　＜－　プロ
機能や性能のいいソフトを作る　＜－　アマチュア
ソースの自己満足的美学（現実のメリット度外視・機能や性能軽視）　＜－　Java厨

この考えだと、WTLでデザパタなんてありえない
デザパタじゃないライブラリなんて意味がない
Java+オールデザパタじゃないと気がすまない

プロ的、アマチュア的には、使えるところに使える物を使うだから、
WTL+デザパタもありなわけだ

292 ：デフォルトの名無しさん：04/08/09 20:43

>>291
この馬鹿は何を言ってるんでしょうね。

293 ：デフォルトの名無しさん：04/08/09 21:19

>>270 >>274
すいません、ようやく家に帰ってこれました、つかれたっす…

お二人とも丁寧なレスありがとうございました。熟読しましたがChainや
Toolのポリモーフィックなど、私が目標としたい点である事は間違いないです。
ところが長年Cでやっていたせいか、どうもこんなのしか思いつかないんです…。

class CMain{
　ToolInterface* tool;　//state
　CanvasImple* Canvas;
　CMain() : tool( new ToolBrush ), Canvas( new CanvasImple ){}
};

LRESULT CMain::WinProc( WinMessage msg ){
　return callChainProc( &msg, this );　//tool->WinProc();
}

void ToolBrush::WinProc( WinMessage* msg, CMain* main ){
　CanvasImple* canvas = main->getCurrentCanvas();
　Object* object = main->getCurrentObject();
　int blush_width = main->getBlushWidth();
　COLOR color = main->getCurrentColor();
　..........
　if( msg->msg == WM_LBUTTONDOWN )
　　//処理など

　//処理しないなら
　m_next_chain->WinProc( msg, main ); //他のツールというより、視点操作などですが
}
これだけgetterを用意するんじゃ、ToolBrush::WinProcなど、そのままCMainの
メソッドにした方がましな位な気がして、我ながら気に入りません。
次レスに言い訳を書きます。

294 ：293：04/08/09 21:20

おいおい、処理をまとめすぎじゃないか？

　例えばブラシツールは左クリックした時点で操作が終わるわけではなく、
　描画開始、描画中、描画終了とメッセージを処理しなければいけないわけです。
　ですから、どうしても一カ所にまとめて見通しを良くしないとやりづらいもんで…。
　Undo処理用準備なども分かりやすいので、つい…。

もう少し細かくポリモーフィックなメソッドを用意して、ましにできないのかよ？

　同じイベントでも、ツールによって処理が全然違うんですよ先輩。
　例えばCtrl+左クリックが、ただの左クリックと別の意味を
　持つツールもある。持たないツールもある。
　これを共通のメソッドに納めるのは辛くてつい…。

295 ：270：04/08/10 02:43

読み返してみたら >>274 さんが、かなりフォローしてくれてます?
多分、全く意識していなかったと思いますが、いや、>>293 での例が
単に両方取り入れているだけ? >>270 みるとわかりにくいし、
つーか、たいしたことかいてない?
>今、選択しているツールのメッセージ処理クラスを chain で
>通るようにすればよい。
いいわけすると、これがstateだったんだなと。
後で気が付くんだよな、「あっ、こんなとこにもパターンが」って感じで。

なるほど、コードにすると見えてきますね(自分的には)
>なんとなく見えてきた・・が、微妙なので俺なりの回答を書いてみる。
あれっ? 俺って周回遅れ?

ちゃうねんちゃうねん、>>270 では
>いや、それはMFCがメッセージをディスパッチする仕組みの事だよね？
>俺が知りたいのは、その結果の使い方なんですよ。
に答えたつもりやねん。

296 ：270：04/08/10 02:56

>これだけgetterを用意するんじゃ、ToolBrush::WinProcなど、そのままCMainの
ToolBrush のメンバーに持たせるようにして、new のときに渡してもいいかと
たいしたアドバイスじゃないけど

>例えばブラシツールは左クリックした時点で操作が終わるわけではなく、
>描画開始、描画中、描画終了とメッセージを処理しなければいけないわけです。
>ですから、どうしても一カ所にまとめて見通しを良くしないとやりづらいもんで…。
これは同意ですね、ドラッグ動作はまとめてしまいたいですね。

>同じイベントでも、ツールによって処理が全然違うんですよ先輩。
>例えばCtrl+左クリックが、ただの左クリックと別の意味を
>持つツールもある。持たないツールもある。
これもわかるよ

ドラッグの動作も一つのクラスにして、ToolBrush でWM_LBUTTONDOWNの時に
ToolBrushDrag を生成してこのクラスにメッセージが通るようにして
ドラッグの動作してもいいかもね。
Ctrl+左クリックでのドラッグもあるのなら ToolBrushCtrlDrag クラスとか
作って(ry

もう、あんまり書くことナイッス

297 ：デフォルトの名無しさん：04/08/10 05:27

Java厨の考えってｷﾓｲ･･･

298 ：デフォルトの名無しさん：04/08/10 09:34

>>292

>>>291
>この馬鹿は何を言ってるんでしょうね。
そーか？馬鹿か？

完全に認めるわけではないが、291のは当たらずしも遠からずってとこは
あるように思うがな。

プロ、アマだっていろいろあるだろーに。
中には291ぴったりのやつや、よく似た奴もいるだろう。
それをいきなり馬鹿って即断するあたり、喪前にもよっぽど問題あるよーな気がするぞｗ

299 ：デフォルトの名無しさん：04/08/10 10:34

>>298　煽りが弱いぞ

300 ：デフォルトの名無しさん：04/08/10 11:43

>>297
どれを根拠にJava厨って言葉使ってるの？このスレの内容？

301 ：デフォルトの名無しさん：04/08/10 12:04

↓
Chain of Unko Response
↓

302 ：デフォルトの名無しさん：04/08/10 13:12

　｜　↑
　￣￣
　∩∧ ∧ 　　　　おらっしゃあ！
　ヽ（ﾟДﾟ）
　　　＼⊂＼
　　　Ｏ-､　）～
　　　　　　∪

303 ：デフォルトの名無しさん：04/08/11 00:19

アンチJavaな人は、劣等感の固まりですね。

304 ：デフォルトの名無しさん：04/08/11 02:49

JavaはC++と違ってポインターが無いから，デザインパターン知らないと眼も当てられないこと多いよね。
まあ，だから皆必死に勉強するんだが，C++はどうにかなっちゃう分デザインパターンの優先順位は低いからね。
自分の場合は，Javaだといつもデザインパターン（基本形，J2EE，ｅｔｃ）を意識するけど，
C++でやる時はライブラリィどれ使おうか悩むのが最優先だし．．．

305 ：デフォルトの名無しさん：04/08/11 05:23

>>304
どうにかなっちゃったコードを読む身にもなれ

306 ：デフォルトの名無しさん：04/08/11 06:33

>>304
相互依存しまくりでよければJavaでもデザインパターンなしでどうにかなると思うが。
C++のどうにかなっちゃうってのもそういうレベルなんだろ？

307 ：デフォルトの名無しさん：04/08/11 08:54

>>306
factory method 系は厳しく無いかい？

308 ：デフォルトの名無しさん：04/08/11 10:44

俺JavaもC++も使っているが、

>>304
＞JavaはC++と違ってポインターが無いから
どういう点でそうなのかよかったら説明して欲しい。

>>307
これもいまいちピンと来なかった。説明求む。

309 ：デフォルトの名無しさん：04/08/11 16:39

> 俺JavaもC++も使っているが
Java厨の常套句(本当はWebで文法見た程度)

310 ：デフォルトの名無しさん：04/08/11 16:59

Java厨はひきこもり

311 ：デフォルトの名無しさん：04/08/11 19:44

言語だろうがパターンだろうが環境だろうが、勉強して良いと思ったものは使う。
そうでないものは使わない。そして他人に押し付けない。

そして仕事だと選り好みできない現実がある。ただそれだけ。

312 ：デフォルトの名無しさん：04/08/11 23:21

”あるオブジェクトが他からアクセスされたときにフックしたい”のフックってなに？

313 ：デフォルトの名無しさん：04/08/12 00:05

スレ違い。

314 ：デフォルトの名無しさん：04/08/12 00:09

>>313
ﾌﾟｯ　わかんないからって必死すぎｗ

315 ：デフォルトの名無しさん：04/08/12 00:33

313じゃないけど、どこがどう必死なんだろう
てか、312=314が必死？
しかし、若いもん？はフックも知らんのか。

316 ：デフォルトの名無しさん：04/08/12 00:56

Factoryって今日はじめて知ったけど便利だな
でもこれってJavaでこそ真価を発揮するんだな
C++で使うとちょっとキモい

317 ：293：04/08/12 02:07

>>296
こちらも勘違いしてました、委細承知でござる！
オブジェクトが静的なら、最初に必要なものをFactoryなりBuilderで渡しちゃえれば
格好良いのですけどねぇ。実際はあまりに生成破棄が多すぎて難しそうです…。

ポリモーフィックに行こうとこういうのを考えたことがあります。

ToolInterface{
　virtual void OnLbuttonDown() =0;
　virtual void OnLbuttonDownPressingRButton() =0;
　virtual void OnLbuttonDownPressingCtrl() =0;
};

ToolBrush{
　virtual void OnLbuttonDown(){ /*処理*/ }
　virtual void OnLbuttonDownPressingRButton(){ OnLbuttonDown(); }//操作変わらず
　virtual void OnLbuttonDownPressingCtrl(){ /*処理*/ }
};

ただこれも、getterの多さは変わらないんですよね。
どうすればもう少しオブジェクト同士が分散して動くような感じに出来るのだろう…。
いや長々お付き合いありがとうございました。今後の糧にします。

318 ：デフォルトの名無しさん：04/08/12 08:38

経験が浅いせいか、漏れがアホなせいかしらんが、
プログラミング構想時には、なかなかデザパタ適用が
ピンと来ないんだよね。
で、プログラム組んでると思いついてきて、上司には
内緒でこっそり、リファクタリングしてたりするんだが・・・
コーディング前にもう少し、想像力を働かせられるように
なりたいな・・・

319 ：デフォルトの名無しさん：04/08/12 09:12

>上司には
>内緒でこっそり、リファクタリング

フリーになるのがお勧め。
ただし素人には(ry

320 ：デフォルトの名無しさん：04/08/12 11:13

＞318
作ろうとするプログラム実装する前にクラス構造とか必至に考えろ

321 ：デフォルトの名無しさん：04/08/12 12:11

>320
そういったクラス分けや構造って結構悩む部分なんだが。
（粒度や継承の度合い、連携その他・・・）
喪前さんの自己流でもいいから、
お手本又はガイドラインキボン

322 ：320：04/08/12 12:21

自分の作るプログラムに重複部分はほとんどない
重複する部分はほとんど"部品"としてきりだす。
多重継承多様
たたい多様
前の２chブラウザの話で言ったら自分も２００-３００いくと思う

323 ：デフォルトの名無しさん：04/08/12 14:10

また具体論抜きの妄想ですか(ﾌﾟ

324 ：デフォルトの名無しさん：04/08/12 14:26

おれの友達にもいたな。
漫画家志望で同人誌作ってた。
この漫画家はここがダメだとか
あの漫画家は大成しないだとか
おれならもっとこうできるとか
凄いこといっぱい言ってたな。
けっきょく漫画家になるどころか
卒業するまで一度も
同人誌は完成しなかったな。
いまはフリーアルバイターらしい。
なにが悪いんかなー？

325 ：デフォルトの名無しさん：04/08/12 14:28

>>322
>自分の作るプログラムに重複部分はほとんどない
>重複する部分はほとんど"部品"としてきりだす。
>多重継承多様
>たたい多様

なんで委譲使わなくて継承が多いのか聞きたいな。
継承だと確かに効率的なんだが上位クラスに縛られるしつぶしが利かないしね。
実際継承より委譲を使うべきって話も良く聞くし。
もちろん、これはこれで考えは判るんからケチつける気はないんだけどさ。
なんでそっちなのか気になるところ。
それに漏れはクラスってのはあるものの動作とか属性をひとまとまりにした物でクラス同士でメソッドやり取りして構成って
思うし、そーなると共通の要素を持った親的な存在があるってのなら判るんだが、
”部品”がクラスって言われると、それは”関数もぶち込める便利な構造体”としてしか使ってないんじゃないか？とも思える。
で、アクセス等が便利だから部品の真下にぶら下げていってるだけ。と。

もっとも322は漏れの言ってるのクラスの意味と同じ事を”部品”って表現してるだけだと思いたいが・・・

326 ：デフォルトの名無しさん：04/08/12 15:02

>>320がポリシーの概念を多くを用いたプログラムを書いているなら
多重継承の部分は結構納得。

327 ：320：04/08/12 15:16

ポリシーの概念って野がよく分からないんだけど
自分が使ってるグリッドクラスはハこんな感じ

public class CGrid:class CWindow,class CSerializable,class CCommandRouting{
ほにゃらら
}

ウィンドウでもあり、保存可能なものでもあり、コマンド受け取れるものでもある
各々が使われるフレームワーク(大げさだけど)に放り込んどけばそのとおりに動いてくれる.
自分はそういうフレームワークをドンどこ作っていってそこに当てはめる形で作ってます.
部品といってるのはフレームワークって意味に近いかも

328 ：デフォルトの名無しさん：04/08/12 15:48

>>327
MFCに近いなあ、志向が．．．

329 ：デフォルトの名無しさん：04/08/12 16:36

ここにいる人たちは業務系？
継承がいいとか委譲がいいって話は、システムのどの層を作るのかによって全く変わってくる部分だと思うんだけど。

330 ：デフォルトの名無しさん：04/08/12 17:15

>>327
おれもMFCやその辺のフレームワークと大差ない気がする
それなら皆が良く知っている物を使った方が良いし、自作するだけ無駄な気がするんだが・・・

もう少し具体的に違いを知りたい
たとえばそれだと>>293みたいのはどう処理できるんだ？

331 ：320：04/08/12 17:43

言いたかったのはなるべく共通の仕組みをつくり汎用的になるように設計するということだったんですけれど.
SwingとMFCだと設計思想違いますよね?Swingのほうがいろんな部品を組み合わせられるように出来ていると思います.
自分も作るときにはそうできるように作ってるんです.

＞293の例だと他の条件が分からないのでなんともいえないんですが、あれはツールの描画上でのウィンドウに対する考え方とかイベントの配信の仕方とか絡んでますよね?
なるべくそこらへんは分離する.
で、うまく抽象化できればレイヤーとかもほとんどツール側には手を加えないでできるようにとか考えると思います.

自分の考える基本は使いまわせるようにする、いろんな流れを分離するです。

332 ：U ◆CZtFsGiu0c ：04/08/12 17:46

>>327
ぱっとみたところ、実装継承ではなく型のみ多重継承しているようなので、
問題ないと思います。
＃Javaならインタフェース使うとこだけど

333 ：320：04/08/12 17:53

＞332
実装継承してます．．．
実装継承の問題点って何でしたっけ?
ダイヤモンド継承はしませんけど実装継承含む多重継承多用してるんですけど、今まで不具合はないんです．
逆にインターフェースを好む理由がわからないんです。何で基本クラスは一つにしなければいけないのかと?
＞３２７の例だと別にグリッドクラスだけれどそれはウィンドウクラスでもあるし、シリアライザブルでもあるし、コマンド受け取れるものでもあるんです｡
どれも同じ扱いなんです．

334 ：デフォルトの名無しさん：04/08/12 18:03

>>333
多重継承しても、互いに概念が全く違うものなら基本的には問題は発生しない。
よって君の使い方は可。
ポリシーはModern C++ Desigｎ参照のこと。

335 ：デフォルトの名無しさん：04/08/13 00:53

>>324
＞お
＞漫
＞こ
＞あ
＞お
＞凄
＞け
＞卒
＞同
＞い
＞な

卒同いなってなんだろ...難しい縦読みだな

336 ：デフォルトの名無しさん：04/08/13 16:52

Java厨って才能無いのに夢見がちな少年?

337 ：デフォルトの名無しさん：04/08/13 17:15

>>336
心は少年、体は中年

338 ：デフォルトの名無しさん：04/08/13 17:47

>>337
技は大年あたりか？

339 ：デフォルトの名無しさん：04/08/13 23:36

デザインパターン＝天才達が作ったスパゲッティパターン

340 ：デフォルトの名無しさん：04/08/13 23:51

デザインパターン＝前世代の遺物

341 ：デフォルトの名無しさん：04/08/13 23:55

オブジェクト指向＝前世代の遺物

342 ：デフォルトの名無しさん：04/08/14 00:39

オブジェクト指向→構造化

これが本来の正常な進化。
人間的な物からより機械が扱いやすい形へ。
機械が扱いやすいってことはそれだけ曖昧な所がなく理路整然として
分かりやすいということ。
クラスが多すぎる場合は、switchにリファクタリングしよう。

343 ：デフォルトの名無しさん：04/08/14 00:59

今や構造化も古いな。
機械が扱いやすいってことはそれだけ曖昧な所がなく理路整然として
分かりやすいということ。
あらゆる構造はgotoにリファクタリングしよう。

344 ：デフォルトの名無しさん：04/08/14 01:01

（`･ω･´)　

345 ：デフォルトの名無しさん：04/08/14 01:16

行番号を使ってプログラムを書くのが最近の流行らしい

346 ：デフォルトの名無しさん：04/08/14 01:28

馬鹿ばっかし

347 ：デフォルトの名無しさん：04/08/14 01:28

Javaでメソッドしかないクラスとフィールドしかないクラスを使って
C風にプログラムを組むのは何パターンて言うのですか？

348 ：デフォルトの名無しさん：04/08/14 02:54

Java厨って馬鹿を装ってる時でさえ
知識の浅さがにじみ出るね

349 ：デフォルトの名無しさん：04/08/14 03:04

>>348
そうだな

例えば>>348とか一見馬鹿装ってる、と自分で思ってるんだろうが
本当に馬鹿丸出しと見ただけで感じ取れるもんな

350 ：デフォルトの名無しさん：04/08/14 03:24

知ってる単語が少ないんだよね。スパゲッティとか構造化とかリファクタリングとかアスペクト思考とか、脈絡もなく連呼しだす(稾)

351 ：デフォルトの名無しさん：04/08/14 03:30

Java厨は「D言語」とかも好きだぞ
知識は皆無だが(w

352 ：デフォルトの名無しさん：04/08/14 04:00

↑馬鹿発見。

Java厨はJava以外に興味を示さず、Javaを盲信する奴のこと。
D言語に興味を示してる時点でJava厨では無い。

353 ：デフォルトの名無しさん：04/08/14 07:14

Java厨は、自分はJava厨じゃないっていうんだよな
勝手に自分で、自分を定義すんなよ
定義はまわりがするもんだ
>>352 は立派なJava厨(www)

354 ：デフォルトの名無しさん：04/08/14 09:13

↑Java厨が大挙して出現したな。
俺？俺はC++厨、Java糞言語

355 ：デフォルトの名無しさん：04/08/14 10:33

Java厨認定すると、ポイントがもらえたりするのだろうか。
１００ポイントで１０００円分のお買い物が出来ます。
自分の何の得にもならないんだったら、こんなことしないだろうしなぁ。

356 ：デフォルトの名無しさん：04/08/14 11:12

まぁ弱いものが弱いものたたくのがこの世の常だから。ﾌﾟｹﾞﾗ

357 ：デフォルトの名無しさん：04/08/14 13:01

>>353
お前も立派なJava厨だな（ｗｗｗ）
定義は周りがするらしいんで、お前は否定できないなｗｗｗ

358 ：デフォルトの名無しさん：04/08/14 14:14

Java厨と呼ばれるくらいなら死んだ方がまし

359 ：デフォルトの名無しさん：04/08/14 14:22

>>358
> Java厨と呼ばれるくらいなら死んだ方がまし

じゃあ死ねよJava厨、お前が居なくなってもなんの影響も無い

360 ：デフォルトの名無しさん：04/08/14 14:35

ＩＱが１００以下の人達が集まっているスレですね。俺は自慢じゃないがＩＱ１５０。

361 ：デフォルトの名無しさん：04/08/14 15:33

KusoresFactory

362 ：デフォルトの名無しさん：04/08/14 15:50

>>360
http://pc5.2ch.net/test/read.cgi/tech/1090324689/

363 ：デフォルトの名無しさん：04/08/15 00:14

Java選択するという事自体がそもそも厨だな。
素人なら兎も角、並みの知性があれば、Javaなんか選択しない。

364 ：デフォルトの名無しさん：04/08/15 01:26

お前はJava使ってる人煽るしか能が無いのかよ？

365 ：デフォルトの名無しさん：04/08/15 01:45

GOFスレでJavaをネタに粘着してる釣り糸に脳味噌などあるわけもない

366 ：デフォルトの名無しさん：04/08/15 02:11

デザパタとJavaって関係ないやん
Java厨ネタはスレ違い

367 ：デフォルトの名無しさん：04/08/15 13:27

いいものがあるよ。
【厨房】言語叩き討論スレッド【隔離】
http://pc5.2ch.net/test/read.cgi/tech/1064841627/

368 ：デフォルトの名無しさん：04/08/19 08:04

俺としては、いつも見当違いの発言を繰り返す、Java厨に消えて欲しいけどな。

369 ：デフォルトの名無しさん：04/08/19 21:48

>>368
両刀使いはどうすっぺ？

370 ：デフォルトの名無しさん：04/08/20 00:22

Javaをちょっとでも使えば立派なJava厨

371 ：デフォルトの名無しさん：04/08/20 00:26

>>370
それは違う。
JavaひきこもりがJava厨。

372 ：デフォルトの名無しさん：04/08/20 00:50

じゃあ5つの言語を使ってる俺は？

373 ：デフォルトの名無しさん：04/08/20 01:06

>>372
その知っている5個のうちにJavaが入っていて、なおかつ、Javaで
全てのケースに対応できると信じきっていたらJava厨なんじゃない？

374 ：デフォルトの名無しさん：04/08/20 01:09

こいつが100の言語を知ってても　やっぱりJava厨ﾀﾞﾛ

121 名前：デフォルトの名無しさん投稿日：2004/08/18(水) 22:51
おまえら計算量って言葉を知ってるか？
いくらC++が速くたって、NPな問題は現実の時間じゃ解けないんだよ。

例えばな
将棋のプログラムをJavaとC++で作っても
強さも体感実行速度も大差ないんだよ。
むしろ、アルゴリズムの問題で
アルゴリズムさえ良ければ
Javaで作ったプログラムにC++のプログラムは足元にも及ばない
なんて事さえ起こる。

インライン展開でもなんでもしてくれていいんだけど、
それがどれくらい利益を生み出したのかを考えるんだな。
もちろん、それが莫大な利益を生み出す事もある。
でも、ほとんどの人が作るプログラムはそんなC++の高速化は無益だったりする。
だってさ、ケータイでゲームが動く時代だぜ？

375 ：デフォルトの名無しさん：04/08/20 01:54

>>374
どこが間違ってると思うんだろう。
計算量の意味を理解してないんじゃないか？

Javaで作った方のアルゴリズムがC++の方のアルゴリズム
より優れていたら、Javaの方が速いってことなんて当たり前
なんだが。

376 ：デフォルトの名無しさん：04/08/20 01:55

あ、「速いって事なんて」じゃなくて、「速いって事があるなんて」だ。

377 ：デフォルトの名無しさん：04/08/20 01:57

スレ違いだけど、gccとJavaのベンチマーク
http://www.excite.co.jp/world/english/web/body?wb_url=http://www.sys-con.com%2Fstory%2F%3Fstoryid%3D45250&wb_lp=ENJA&wb_dis=3

378 ：デフォルトの名無しさん：04/08/20 03:37

> 375 名前：デフォルトの名無しさん投稿日：2004/08/20(金) 01:54
> >>374
> どこが間違ってると思うんだろう。
> 計算量の意味を理解してないんじゃないか？
>
> Javaで作った方のアルゴリズムがC++の方のアルゴリズム
> より優れていたら、Javaの方が速いってことなんて当たり前
> なんだが。

うわぁ、本物のJAVA厨

379 ：デフォルトの名無しさん：04/08/20 04:17

>>378
2chていいなぁ。
アホがいて。

380 ：デフォルトの名無しさん：04/08/20 04:41

本人曰く「何が恥ずかしいか良く解らない」

> 5 名前：デフォルトの名無しさん投稿日：2004/08/20(金) 02:19
> オブジェクト指向を勉強するならオブジェクト指向言語の顔であるJavaしか無いだろ
> C++やDelphiなどとは違う本物のオブジェクト指向が勉強できる
> perlとかrubyみたいな手続き型っぽく安っぽい言語でwebサイトとか作っちゃってその癖が残ると悲惨
> それにJavaはXPやデザインパターンを作り出した実績もあるしこれからも色々作り出していくだろう
> Javaから勉強して余裕があったら、ちょっとグレードの低いスクリプト系に行くのが無難
>
> 13 名前：デフォルトの名無しさん投稿日：2004/08/20(金) 03:55
> >>9
> 何が恥ずかしいか良く解らない
> リンク先だって足し算するだけだからそんなの普通にJavaでも出来るよ
> そこはLispっていう誰も使っていないようなマイナー言語宣伝したいだけでしょ
> それにXPもデザインパターンもJavaだろ
> JUnitだってJavaが最初で他の言語に広まったんだから

381 ：デフォルトの名無しさん：04/08/20 10:10

>>375
｜「A」で作った方のアルゴリズムが「B」の方のアルゴリズム
｜より優れていたら、「A」の方が速いってことなんて当たり前
｜なんだが。

A と B には何を入れてもいいよな。。。

382 ：デフォルトの名無しさん：04/08/20 11:21

アルゴリズムと言語は別物でございます

383 ：デフォルトの名無しさん：04/08/20 12:02

>>382
見分け付いてないか、混同してるやつがJAVA厨

384 ：デフォルトの名無しさん：04/08/20 14:23

>>375
間違っちゃいないが、アルゴリズムが違うなんて前提で速度を比較してどうするんだ。
JavaとC++の速度が大差ないという主張を何ら裏付けないじゃん。
論理展開がJava厨なんだろ。

385 ：デフォルトの名無しさん：04/08/20 17:12

>>368-384
こういう展開が「厨」

386 ：デフォルトの名無しさん：04/08/20 17:44

>>385
レッテル貼っておしまいというのもどうかと。

387 ：デフォルトの名無しさん：04/08/20 18:49

いや、おしまいでいいよ。

388 ：デフォルトの名無しさん：04/08/20 18:57

では一人残らず厨ってことでおしまい。

389 ：デフォルトの名無しさん：04/08/20 19:26

>>384
>>374に書かれていることは、そう言うことだろ。
将棋なんかでは大差ないことは、>>377を見れば分かる。

390 ：デフォルトの名無しさん：04/08/20 20:01

アンチJava厨というのは、Javaを習得出来ない、
Javaを習得するための勉強が出来ない、落ちこぼれだという
ことがよくわかるなー。

391 ：デフォルトの名無しさん：04/08/20 20:13

そろそろdかな

392 ：デフォルトの名無しさん：04/08/20 20:23

>>390
それって理屈通っていないぞ
そう考える判断材料は？
それに、少なくともアンチJavaがこのスレにいるとは思えないし、
Java*自体*を批判している人間は多くない。
Java厨の妄想一人相撲？
Javaって中毒症状があるのかなぁ…こわい

393 ：デフォルトの名無しさん：04/08/20 20:56

>>392
厨とかレッテルはる奴に理屈を求めるだけ無駄。
レッテルの種類にかかわらず、まともな理屈を述べた奴を見た事がない。
まともな頭がないからレッテルを貼るしかないんだろう。

394 ：デフォルトの名無しさん：04/08/20 21:11

JavaはJava厨の言うように万能でも最強でもないけど
技術レベルの低いプログラマでも人海戦術でなんとかできる
使いようによっては便利な言語だよ

まあJava厨に消えてもらいたいってのは
ム板住民の長年の悲願みたいなもんだからな

395 ：デフォルトの名無しさん：04/08/20 21:12

言語を使える、使えない、っていうのは…なんていうか、下等過ぎない？
そろそろ言語の枠を離れたらどうなの。

396 ：デフォルトの名無しさん：04/08/20 21:19

Javaプログラマ ≠ Java厨
Javaが使える ≠ Java厨
Java信者で頭が可哀想な人＝ Java厨

397 ：デフォルトの名無しさん：04/08/20 22:20

＞395
今はどのへんの領域にいるんでしょうか?

398 ：デフォルトの名無しさん：04/08/21 04:54

Perlがもっとしっかりしてれば
http://pc5.2ch.net/test/read.cgi/prog/1092405363/

あーあ

399 ：デフォルトの名無しさん：04/08/21 08:05

↑続々とJava厨が結集中

400 ：デフォルトの名無しさん：04/08/21 09:31

召喚するなよ迷惑だから

401 ：デフォルトの名無しさん：04/08/21 10:19

>>398
可読性の低い言語はロクな物がないと思うが。
いや、もちろんPerlでも可読性高いの書けるだろうが、
一般に書かれたPerlプログラムで今まで漏れの見てきたのは軒並み
可読性低かったしな。
まぁ、運悪くそんなのにしか当たらなかっただけかもしれんが。

で、JAVAだろうが、なんだろうが何で書こうと可読性低けりゃ
（低くしかかけないのなら）クズだし、それがないなら漏れはケースバイケースで
言語なぞ使い分ければいいと思うがな。

402 ：デフォルトの名無しさん：04/08/21 11:47

Javaって可読性最悪
自己満足だけでネーミングするなって漢字

403 ：デフォルトの名無しさん：04/08/21 11:48

ハンガリー使っとけ

404 ：デフォルトの名無しさん：04/08/21 11:58

>>403
ハンガリーは国名。国を使うのか。
知らない人間が見ても後で調べられるようにちゃんと書け。

405 ：デフォルトの名無しさん：04/08/21 12:05

ネーミングとハンガリーの両方が書かれてても検索で見つけ出せないカスは読まないでいいだろ

406 ：デフォルトの名無しさん：04/08/21 12:08

>>405
スキルのことを言っているのではない。
その手間が無駄なのだよ。
万民の教育のために少しでも効率に貢献しろ。

407 ：デフォルトの名無しさん：04/08/21 12:14

知るかボケ

408 ：デフォルトの名無しさん：04/08/21 12:14

>>406
ハンガリーなんてあんなのスキルでもなんでもないだろ。
単なる表記法ぢゃん。
読むなとはいわんが、
表記法もしらなきゃ、スキルと混同するような輩では
あまりまともなソースできそうにない気がするぞ。ｗ

それにハンガリーで書いとけば少しは判りやすくなるわけだから
十分効率に貢献するぢゃないか。
そんなのもわからんのか？

・・・・つーか406はハンガリーが何かもわかってないに１へぇｗ

409 ：デフォルトの名無しさん：04/08/21 12:23

>>408
大いに勘違いしている、読解能力に乏しい408。
405が問題しているのは検索スキルのことであり、
私がスキルと言っているのは検索スキルのこと。

410 ：デフォルトの名無しさん：04/08/21 12:27

わかった。私が悪かった。
どんどん幼稚な話になっていくので止めよう。

411 ：デフォルトの名無しさん：04/08/21 17:30

馬鹿でも規則通りにネーミングがJava流
そのため冗長でセンスのかけらもなし
意味が分かりやすいとか規則的でいいとか自己満足・勘違いしてるが
変質的ネーミングで可読性最悪

412 ：デフォルトの名無しさん：04/08/21 18:24

http://www.geocities.co.jp/AnimeComic-Name/7415/seku_su.swf
セックスパターン

413 ：デフォルトの名無しさん：04/08/22 14:03

>>398
perlは捨ててPythonでもやれ。

414 ：デフォルトの名無しさん：04/08/22 21:43

テキストファイルからデータを読み込んで、それに応じてオブジェクトを生成したり、
メソッドを呼び出したりするのってどのパターンに該当するのでありましょうか
たくさんパラメータがあって、とりあつかうのが難しい……

415 ：デフォルトの名無しさん：04/08/22 21:59

>>414
if-elseifパターンでどうでしょ。

if p1 == nantoka1
　　nantoka1();
elseif p1 == nantoka2 and p2 == nantoka3
　　nantoka23();
elseif p1 == nantoka3
　　nantoka3();

416 ：デフォルトの名無しさん：04/08/22 22:21

>>414
適当に答えるならファクトリじゃねぇのと。

417 ：414：04/08/22 22:43

>415
メインのルーチン上からは実行されているクラスの詳細が見えないで済むようにしたいんです。

>415
ファクトリって、ファクトリメソッドとアブストラクトファクトリって奴ですか。
いまんところ、パラメータ一個に対応して、こんな感じにしてみました。

418 ：414：04/08/22 22:44

class A {
virtual void f1()=0;
virtual void f2()=0;
……
};

class B : A {
void f1();
void f2();
……
};

class C : A {
void f1();
void f2();
……
};

main()
{
char class_type; //'B' or 'C'
//class_typeをどうにかして取得

A *pA;
pA= 何か生成する関数(class_type);
//class_typeに応じて処理が変わる
pA.f1();
pA.f2();
……
}

419 ：414：04/08/22 22:57

f1();
f2();
……
と、基本的なアルゴリズムはパラメータに依らず、固定です。

この上で更に、f1()やf2()の処理内容をパラメータに応じて
それぞれ独立に切り替えたいのです

420 ：デフォルトの名無しさん：04/08/22 23:00

>>418
ポリモフィズム使えば？

421 ：デフォルトの名無しさん：04/08/22 23:03

>>419
ならStateパターンを併用して、
パラメータはStateとして生成して、
pAにセットしてやれば？

422 ：414：04/08/22 23:17

>420
f1()とf2()でそれぞれ独立に切り替えたいんです。どっちかだけならまた継承できるんでしょうけど。

>421
Stateパターンですか。勉強してみます。ありがとん

423 ：デフォルトの名無しさん：04/08/22 23:31

>>414
それはパターン云々の話ではなくて、
インタプリタの作り方が分からないだけではないの？

424 ：デフォルトの名無しさん：04/08/23 00:17

>>414
あまり複雑なようなら、そもそも VM 作っちゃった方がいい場合も。

425 ：デフォルトの名無しさん：04/08/23 00:20

>>424
VMって二度手間ではないですか？

426 ：デフォルトの名無しさん：04/08/23 00:57

言語何よ?
リフレクション使えればモーマンタイ

427 ：デフォルトの名無しさん：04/08/23 00:59

C++

428 ：デフォルトの名無しさん：04/08/23 01:10

クラス名からクラス作れるようにすればいいんでしょ？
typeinfoとか使って実装しる｡

429 ：デフォルトの名無しさん：04/08/23 02:31

>>414
根本的に能力が足りない。

430 ：デフォルトの名無しさん：04/08/23 07:09

>>425
場合によるなぁ。一から自分で作るのが面倒なら lua みたいな既存の
言語 + VM 持ってきて組み込んじゃうのもアリ。

431 ：デフォルトの名無しさん：04/08/23 07:54

>>428
typeinfoは役に立たない

432 ：デフォルトの名無しさん：04/08/23 12:12

＞431
名前取ってくるだけよ

433 ：デフォルトの名無しさん：04/08/23 20:11

>>432
取ってきた名前が役に立たないの

typeinfoが返す名前は規格でどう定義されてるか調べてみ

434 ：デフォルトの名無しさん：04/08/23 22:00

>>433
一意である。と。

435 ：デフォルトの名無しさん：04/08/23 22:25

昔見たんでもう忘れたけど、一意なんでなかったっけ?
一意であれば問題ないが?

436 ：デフォルトの名無しさん：04/08/23 23:19

std::type_infoが返す名前は実装依存。
文字列が実際のクラス名となっている保証は無い。
アプリケーションを通じてユニークなものとなる保証も無い。
アプリケーションを２度実行した場合、同じ名前になる保証も無い。

437 ：デフォルトの名無しさん：04/08/23 23:55

＞std::type_infoが返す名前は実装依存。
問題ない｡一意でありさえすればいい
＞文字列が実際のクラス名となっている保証は無い。
問題ない。クラス名からクラスを作る必要はない。クラス名はファクトリを保存するハッシュキーであればよい

＞アプリケーションを通じてユニークなものとなる保証も無い。
＞アプリケーションを２度実行した場合、同じ名前になる保証も無い。
これだと問題になるけれど、今まで５年動いているシステムで問題になったことはない｡

438 ：デフォルトの名無しさん：04/08/23 23:57

コンパイラ依存のシステム構築したのか。アホだな。

439 ：デフォルトの名無しさん：04/08/23 23:58

>>438
なんで？　世の中、汎用性重視の仕事ばかりじゃないぞ。

440 ：デフォルトの名無しさん：04/08/24 00:02

ハードのスペックが足りないと大変だよね～

441 ：デフォルトの名無しさん：04/08/24 00:11

なんでもいいから動けばいい、と思ってるならいいかもねぇ。
コンパイラのアップデート等で動かなくなるかもしれんけど、まぁそんときはそんときかｗ

442 ：441：04/08/24 00:13

まぁ自分の場合はそれでいいかもしれんが
それを他人に勧めるのはどうかと思うよん。

443 ：デフォルトの名無しさん：04/08/24 00:20

>>441
世の中、コンパイラをブラックボックスとして使わない場合もあるし、
標準規格では明確な規定が無くともほぼ「これは大半の処理系で
間違いなく動く」っつー部分もある。

どこまで踏み込むかは、ケースバイケースでしょ。

444 ：441：04/08/24 00:30

疑問が浮かぶ

本当にそれは「大半の処理系で間違いなく動く」のか？

このスレに救いを求めに来た人は「大半」の範疇から外れた人である可能性は無いのか？

さも当然のように「typeinfoを使って実装しろ」と言ってるが、
せめて「これは処理系依存だけども」、という前フリが必要じゃないのか？

445 ：デフォルトの名無しさん：04/08/24 00:39

そこでいっている処理系依存ってのは、テンプレート動くのかしらといってるのとどうレベルの話では?
少なくともtype_infoは標準仕様なわけでレアな処理系なら自衛すべきでは?

446 ：デフォルトの名無しさん：04/08/24 00:43

何言ってるかよくわからん。テンプレートも標準仕様だろう。

447 ：デフォルトの名無しさん：04/08/24 01:18

type_infoは標準仕様　の”は”は、主題の意味で使われているのであってテンプレートを対照とするものではないと思う。

448 ：デフォルトの名無しさん：04/08/24 02:49

ここにもまたJava厨･･･

449 ：デフォルトの名無しさん：04/08/24 13:43

＞448
だれのことを指してるのかわからんが．．．

450 ：デフォルトの名無しさん：04/08/24 20:04

結局、>>414に対する答えは無しと（ワラ

451 ：デフォルトの名無しさん：04/08/24 20:10

デザパタなんて理論だけで実用的じゃないからね

452 ：デフォルトの名無しさん：04/08/24 20:17

なんか空想で語ってる人がいますよ。

453 ：デフォルトの名無しさん：04/08/24 21:29

だからおまえら責めてアンカーつけろ

454 ：デフォルトの名無しさん：04/08/24 21:47

お前もつけろ

455 ：デフォルトの名無しさん：04/08/24 21:53

＞454　オマエモナー

456 ：デフォルトの名無しさん：04/08/24 22:58

>>450
これだけ情報が出てて、まだどう扱ったら良いか分からないとしたら、
ちょっと……。

保存するデータの性質なんかについて、もう少し具体的に書けば、
もう少し具体的なアドバイスが来るかもね。

457 ：デフォルトの名無しさん：04/08/24 22:59

>>446
だけど、規格を 100% 実装できてるコンパイラはほとんど無いという罠。

458 ：414：04/08/25 00:19

>456
あれこれ出た情報を手がかりにもちっと勉強して来ます。
知識が足りないと質問するのが難しいです……

459 ：デフォルトの名無しさん：04/08/25 00:23

＞458
つかどんなことしたいのかも少し詳しく書け｡
それしだいでどこまでじっそうするのかどうかがか割る

460 ：デフォルトの名無しさん：04/08/26 23:54

結城氏のデザパタ本で勉強中ですがbuilderパターンとabstract factoryパターンが理解できません。。。

461 ：デフォルトの名無しさん：04/08/27 00:16

>>460
factoryが分かってんなら，abstract factoryは難しく無いと思うが．．．．

462 ：デフォルトの名無しさん：04/08/27 07:47

いまだにそんな糞本読んでる香具師いるのな

463 ：デフォルトの名無しさん：04/08/27 08:59

すでに古典の域に入っている
でも古典イイ!

464 ：デフォルトの名無しさん：04/08/28 03:25

読んだけどはっきりいって厨用

465 ：デフォルトの名無しさん：04/08/28 03:30

丁寧に書いてあったり、わかりやすかったりしたら、
なんでも厨用だと思う人ってよくいるよね

結城の本は確かに厨用だと思うけど

466 ：デフォルトの名無しさん：04/08/28 05:12

厨用 = 厨しか感心できない低レベル

467 ：デフォルトの名無しさん：04/08/28 07:19

NGワード：厨

468 ：デフォルトの名無しさん：04/08/28 15:48

>>462 >>464-466
なに！今さっき１時間前に買ってきた漏れって一体・･･。
日立ＳＫの研究所だかが出してる奴もあったんだけど、迷いに迷って結城のにしてみたんだけど
どの本がいいの？またはネットで探す？

469 ：デフォルトの名無しさん：04/08/28 15:53

>>468
具体的な一例を挙げて解説してあるので、わかりやすいと思う。
ただ、それ一冊では満足できないんじゃないかな。

470 ：デフォルトの名無しさん：04/08/28 16:38

>>468
あんたの勘が良ければ、それだけでも割とOK。
でもまあ、凡人ならそれを読んでからGOFを読め。
いきなりGOFではつらかろう。

471 ：デフォルトの名無しさん：04/08/28 20:27

>>466
ならてめーには厨時代は無かったのかよ！！！！！！！！！！

472 ：463：04/08/28 20:48

ごめんGOFと間違えた

473 ：デフォルトの名無しさん：04/08/28 21:23

>>471
無かった。マニュアルだけで言語を覚え、他人のプログラムを読んでプログラミングを覚え。
昔は厨だったら使いものになりようがなかった。

474 ：デフォルトの名無しさん：04/08/28 21:30

普通の人生
精子 -> 赤ちゃん -> 子供 -> 大人

>>473の人生
精子 -> 大人

475 ：デフォルトの名無しさん：04/08/28 22:16

>>470
次に読むオススメの本はありますか？

476 ：デフォルトの名無しさん：04/08/28 22:32

>>475
定番だと、リファクタリングかな。もう読んだ？

477 ：デフォルトの名無しさん：04/08/28 22:47

>>473
酷い記憶力だね，健忘症かもよ。

478 ：デフォルトの名無しさん：04/08/29 00:34

>>475
デザインパターンにこだわるなら、
結城の本→（独習デザインパターン）→GOFって順番がお勧め。
結城のあとにGOFを読んで、難しければ独習デザインパターンを買えばいい。

あとは>>476も挙げてるけど、リファクタリングとかテスト駆動開発入門かなあ。
後者は訳が腐ってるけど。

そこそこ分かるようになったら、「アジャイルソフトウェア開発の奥義」が超お勧め。
これは買え。そして読め。名著だ。すばらしい。

ちなみに俺はXPの本はまともに読んだ事がないのでその点は留意してくれ。

479 ：デフォルトの名無しさん：04/08/29 01:22

ジャバって簡単にエディタやワープロが作れるらしいですね。
文字一つ一つがオブジェクトで色や大きさ位置といった属性を持たせるそうです。
そのときに使うのがフローレイアウト。
多くの書籍でそう紹介されています。
大笑いですが、便利そうですね。藁

480 ：デフォルトの名無しさん：04/08/29 04:55

>>479
あんたアホ？理論的に合理的な設計手法だよ。デザインパターンくらい勉強しろよ。

481 ：デフォルトの名無しさん：04/08/29 08:15

>>480
追記しとくと、ふつーは一文字一文字に情報を持たせると重複が多くなるので
もう少し工夫する。それもデザパタのカタログにあるけど。

482 ：デフォルトの名無しさん：04/08/29 08:56

ttp://www.amazon.co.jp/exec/obidos/ASIN/4797327030/ref=ase_javanomichi-22/249-4251103-3156367
結城氏のデザパタ本は改訂されていたのか。GOF以外のパターンも追加されたのかな？

ttp://www.amazon.co.jp/exec/obidos/ASIN/4797311126/ref=pd_bxgy_text_1/249-4251103-3156367
GOF本

483 ：デフォルトの名無しさん：04/08/29 11:21

バカとハサミは使いよう

484 ：デフォルトの名無しさん：04/08/29 12:39

>>473
>昔は厨だったら使いものになりようがなかった。

言い換えると、今は誰でも理解できる分かりやすい入門書がある。
よって結城氏の入門書は過去には存在しなかったほどの分かりやすい本である。
473 は結城氏の入門書を褒めてるんだね。

485 ：デフォルトの名無しさん：04/08/29 12:41

>>480
デザパタは理論的に合理的。

ってのが笑いどころですよね？

486 ：468：04/08/29 23:44

結城本(改訂版)買った者です。
当方、厨(デザパタ無知)なのですが、わかりやすくて非常にいいです。入門にはかなりよい本なのではないかと。
ただ、>>460が言うように Abstract Factory の章がわかりにくかった。サンプルコードが悪かったような。

>>469
たしかに。初歩は理解できたのでもう少し高度な使い方が知りたいところ。

>>470
うぃっす。先生。さっそく読んでみます。

>>482
中身を見直して、わかりやすくしたみたい。パターンの追加はなしです。

487 ：デフォルトの名無しさん：04/08/30 03:54

読むならGOFとアジャイルソフトウェア開発の奥義
あたりで十分な希ガス

488 ：デフォルトの名無しさん：04/08/30 05:26

リファクタリングも外せない。

489 ：デフォルトの名無しさん：04/08/30 08:34

解読不能なコーディングをして「正しく動くことを確認しました。問題ありません。（何が悪いんですか？）」
言うヤツばっかりの職場でデザパタを浸透させるにはどうすればいいでしょうか。

490 ：デフォルトの名無しさん：04/08/30 10:11

>>489
そんな職場にデザパタ持ち込んだら、489以外の人にとって解読不能なソースができると思うぞ。
いきなりパターンの前に、その前の知識から浸透させた方がよいかと。苦難の道だけど。

もしくは、リファクタリングテクニックとして教えるとか。例えば、
「ほら、ここに重複しているコードがあるだろ。こういうのは、
こうやってこうやると・・・ほら、１箇所にまとまった。
これから似たようなコード書く時は、このクラスを継承して使うといいよ。
こうすれば簡単に作れるでしょ？コピペもしなくていいし。
ちなみにこういうのはTemplate Methodパターンと呼ばれていてね・・・」
みたいな感じで。

491 ：デフォルトの名無しさん：04/08/30 10:37

>>490
muri

492 ：デフォルトの名無しさん：04/08/30 13:16

>>489
デザパタ云々以前に相互にメンテナンスさせたら？
それでお互いのソースが彼らにとってメンテナンスし易いのなら
異物は貴方だけということだ。

493 ：デフォルトの名無しさん：04/08/30 13:27

動いてるソースにケチつけて弄くりまわしてバグ仕込み
リファクタリングだとかいって得意になってる給料泥棒はJava厨だけ

494 ：デフォルトの名無しさん：04/08/30 13:32

>>493
釣？

495 ：デフォルトの名無しさん：04/08/30 18:34

>>489
解読不能なコードの内容による。

単に読み手の知識が足りない為に「これは解読不能で
汚いソースだ」と評価される事が結構ある。

496 ：デフォルトの名無しさん：04/08/30 19:32

>>495
デザインパターンを知ってるというと、うちの職場じゃトップクラスだ。
そのトップクラスが解読不能だと言うほど高度なコードを書くかな。
もしそうなら羨ましい限りだ。

497 ：デフォルトの名無しさん：04/08/30 19:37

>>489
「（何が悪いんですか？）」
に対して
「これこれこうだから悪いんです。こうして下さい。」
という仕組みを作る。
デザパタとは全然関係無い。

498 ：デフォルトの名無しさん：04/08/30 20:03

＞489
デザパタでやるとこんなにすばらしいんだよというのを納得させなさい．

499 ：デフォルトの名無しさん：04/08/30 20:26

>>495
だから問題なんだよな。
デザパタでかかれたソースが「解読不能で汚いソース」扱いされて、
圧倒的多数でデザパタ知ってるやつが負けるんだから。

500 ：デフォルトの名無しさん：04/08/30 20:33

>>487-488
リーンなんたらってのは？

501 ：デフォルトの名無しさん：04/08/30 21:19

デザパタ以前に、上の人間にオブジェクト指向を徹底的に嫌っている
のが多いから、オブジェクト指向の良さの説明から始めなきゃならない。
全く同じようなコードを、コピーしまくったり、一時変数や静的変数が星の
数のようにあったり、何百行のメソッドがそこらにあったり。
そういうのが読みやすいコードと胸張って言われたら、反論のしようが
ないよ。

502 ：デフォルトの名無しさん：04/08/30 21:21

どんなもの創ってるんです？
うちは金融系だったけど作る人が若手だけで全員オブジェクト指向バリバリだったからそういうのはなかったな．

503 ：デフォルトの名無しさん：04/08/30 21:56

おまえらとだったら仕事したいわ。
うちの会社はもうだめだ。だめすぎる。

504 ：デフォルトの名無しさん：04/08/30 22:26

>>501
この業界に限らず、理解出来ないものには攻撃的になる人間は
結構多いらしい。

>>502
正直うらやましい。
レベルの高い職場に就けるのは、レベルの高い人間だろうね。

505 ：デフォルトの名無しさん：04/08/30 22:56

>>490
関数で良いじゃん。ライブラリ作りゃいいじゃん。
厳密なオブジェクト指向よりも仕様を満たしたシステムをとにかく早く。

結局はこの辺に落ち着く。

506 ：デフォルトの名無しさん：04/08/30 22:57

>>501
＞そういうのが読みやすいコードと胸張って言われたら、反論のしようがない。

事実だからな。当然だ。

507 ：デフォルトの名無しさん：04/08/30 23:01

そういう場合ヒューマンインターフェース研究で使われている様な
検証方法を使ってみたらいいかもね。

508 ：デフォルトの名無しさん：04/08/30 23:02

基本的に何かに自分で何かやらせる。他の人にお願いしたりされたりするって感じで創るんで、関数とかライブラリだけで作るのがぴんとこない.

509 ：デフォルトの名無しさん：04/08/30 23:04

>>508
俺の日本語コンパイラがfatal errorを投げてきた。

510 ：デフォルトの名無しさん：04/08/30 23:07

>>500
正式名称を教えてくれ。

>>501
クラスの分割やメソッド分割や嫌う傾向がある気がする。
だから巨大なクラスやメソッドができる。
メソッドのコールが少ない方がよいらしい。
処理の流れを追っかける、という観点だけでみてるうちは納得してくれないだろう。

>>502
紹介してくれ。薄給でいいから。

>>503
ここ眺めてると、なんでデザインパターンを知ってる奴が
こんなに居るんだろう？と思うよな。俺の周りにはほとんど居ない。

511 ：デフォルトの名無しさん：04/08/30 23:09

>>505
そんな感じで作られたシステムの保守でウンザリしてる。

512 ：デフォルトの名無しさん：04/08/30 23:12

結局従来の構造化が向いてる分野もあればOOが向いてる分野もある。
適材適所。

無理にOOを提唱して過去の資産を敢えて使わず新規開発したバグだらけのコードを
徹夜で試験するのが良い考えかと言えば・・・君たちにも分かるだろう。

513 ：デフォルトの名無しさん：04/08/30 23:14

>>511
OOだと三倍うんざりするよ。

この糞クラスのインスタンスはどっから沸いた？
おいおい！こいつもまたサブクラスだよ！！いつになったら親クラスが見つかるんだ？
おーい。。。このメソッドprivateだと困るんだが・・・・え？基底クラスから変更？試験やり直しかよ？

514 ：デフォルトの名無しさん：04/08/30 23:17

>>512
同意。なんでも盲信はｲｸﾅｲ

515 ：デフォルトの名無しさん：04/08/30 23:20

関数型を忘れてませんか

516 ：デフォルトの名無しさん：04/08/30 23:22

＞513
ごめんそれ正直設計が糞だと思う．．．

517 ：デフォルトの名無しさん：04/08/30 23:26

オブジェクト指向では実装よりも設計に時間をかけるもの。

518 ：デフォルトの名無しさん：04/08/30 23:39

>>517
構造化でも然り。と言うかソフトウェア工学的にそれ常識。
今更胸を張って言われても困る。

519 ：デフォルトの名無しさん：04/08/30 23:43

デザパタで書かれたコードを理解してない時に読んだ時は、なんじゃこのわけわからん設計はアホか。とか思ったけど、
デザパタを理解してから読むと、おお、なにこれ素晴らしい。天才？とか思えた。

つまり、なにが言いたいかというとデザパタの良さを知らない奴にがんばって普及運動をしても無駄だと思う。
なんじゃこのわけわからん設計はアホか。と思われるのが落ちかと。
デザパタは確かに素晴らしいけど、無理に普及はｲｸﾅｲと思われ。

>>509
おまえ、うまいこと言うな

520 ：508：04/08/30 23:49

（・ω・）ｼｮﾎﾞｰﾝ．．．　いいたいのはサブシステムにわけて各々に自主性もたせて他の人のことは知らないようにするってことだったのでふ．．．

521 ：デフォルトの名無しさん：04/08/30 23:52

http://se.aist-nara.ac.jp/papers/IPSJ-MGN450713.pdf

522 ：デフォルトの名無しさん：04/08/30 23:57

オブジェクト指向をすべての開発案件に適用しようってのは
無理があるんじゃないか？
じゃあ、オブジェクト指向が適さない案件ってどんなのがあるのさ？＞教えてエロい人

523 ：デフォルトの名無しさん：04/08/31 00:01

>>516
設計が糞な構造化と設計が糞なOOとどっちがましだと思う？
俺はまだ構造化の方がましだと思う。
そして俺の職場では必ず設計が糞だ。
だから構造化の方がましだと思う。

524 ：デフォルトの名無しさん：04/08/31 00:08

＞523
ウンコとげろとどっち食べるっていわれてもなー

525 ：デフォルトの名無しさん：04/08/31 00:14

Java厨の被害妄想って惨いな。
自分は実力があると勘違いしてるのが学習能力欠如の原因だろうな。
引き籠もりくらいしか生きていく術がなさそうだ。

526 ：デフォルトの名無しさん：04/08/31 00:19

>>524
どっちも嫌っていうのが無しなら、げろを食べるな。

>>525
極端なアンチJava厨もわりとひどいよね。

527 ：デフォルトの名無しさん：04/08/31 00:19

Java厨叩きしか能が無い厨はいいかげん死んでくれんか？

しかも特にJavaの話は出てないのに、なんでお前はチョロチョロ湧き出てくるの？普通にウザイ

528 ：デフォルトの名無しさん：04/08/31 00:24

有能な香具師なら、デザインパターンの学習にかかる時間は、多分１週間程度というところだろう。
その程度で、次々といろいろな知識を身につけていけば、デザインパターンは１つの手法に過ぎず、
「デザインパターン最高！」みたいな、無能をさらけ出さずにすむんだろうが。
死にものぐるいで必死こいて、デザインパターンをやっと覚えたアホは、自分は有能だとか、
デザインパターン書いた香具師は天才だとか、逝わずにはいられないんだろうか？
そんな勘違い馬鹿が入れる会社の同僚は、似たり寄ったりの無能ばかりで、
デザインパターンくらいしか知識がない勘違い君を、同じように無能だと逝っているんだろうな。
目糞鼻糞なのに。

529 ：デフォルトの名無しさん：04/08/31 00:25

＞525
そうだね．君を見てるとそう思うよ．

530 ：デフォルトの名無しさん：04/08/31 00:26

Java厨じゃない折れは、全然頭にこないな。余裕でスルー。

531 ：デフォルトの名無しさん：04/08/31 00:27

JAVA厨の勘違いなんて
今に始まった事じゃないでしょうにねぇ

532 ：デフォルトの名無しさん：04/08/31 00:28

>>528
(･∀･)ｸｽｯ

533 ：デフォルトの名無しさん：04/08/31 00:30

>>528
お前は目糞と鼻糞のどっちなの？

534 ：デフォルトの名無しさん：04/08/31 00:43

＞528
ま、でもデザパタに合わせて物創ることはないよな．
あれは必要な考え方学ぶだけでしょ。あとはたまにドンなんだったっけと見直すぐらい．

535 ：デフォルトの名無しさん：04/08/31 00:51

厨は、自分を厨だと自己分析できるスキルがないから、困るんだよね。
ある程度のスキルがあれば、デザパタにあわせて設計とかいわないよな。
設計してみたら、あのパターンとこのパターンの変形が、あそこで使われてたみたいなことはあるけどさ。

536 ：デフォルトの名無しさん：04/08/31 00:53

ほ～ら、厨厨言ってたら　ねずみさん　になっちゃうぞ～

537 ：デフォルトの名無しさん：04/08/31 00:59

今までボウと読んでた．．．orz　逝って来る．．．．

538 ：デフォルトの名無しさん：04/08/31 01:01

こっこに書いてるやつは、威勢のいいのは偏差値の低いガッコのなかだけってかんじ？
社会で通用してるとは、とても思えないんだけど。（無職引き籠もり？）

539 ：デフォルトの名無しさん：04/08/31 01:05

>>538
筑波大学だが、うらやましいだろ

540 ：デフォルトの名無しさん：04/08/31 03:29

＞539
この間筑波いったが寂しいところだ．．．
自殺者が出るのもよくわかる

541 ：デフォルトの名無しさん：04/08/31 03:46

このスレ住人的にはソフトウェアパターンはどうなのよ？

542 ：デフォルトの名無しさん：04/08/31 08:35

有用。プログラマの嗜み

543 ：デフォルトの名無しさん：04/08/31 22:20

>>528
勘違い君でも、彼なりにやる気があるからまだいい。
やる気の無いやつ、覚える気のないやつばかりが集まった中でどう開発しろと。
会社辞めるぞ。（思うだけ。ゲロゲロ）

544 ：デフォルトの名無しさん：04/08/31 22:45

>>543
技術力が評価につながらない人事システムだとやる気にはならないだろうね。
うちがそうなんだが。だから、同僚にも勉強しろとは言いづらい。
勉強してもいい事無いから。
俺なんて技術力を付けたばっかりに、周りのダメっぷりにイライラするようになっちゃったし。
こんなことならボンクラのままだった方が良かったよ。

545 ：デフォルトの名無しさん：04/08/31 22:50

技術が要らないのに金が貰えるなんて夢のような職場ですね

546 ：デフォルトの名無しさん：04/08/31 22:58

ごり押しも技術のひとつですが何か。

製品を完成させる事だけが正義。

547 ：デフォルトの名無しさん：04/08/31 23:02

>>546
ある意味真。

デザインパターンと言う高尚な考え方を導入しようとしているので明日の納期２ヶ月伸ばしてくれませんか？

とかもう見て欄内。

548 ：デフォルトの名無しさん：04/08/31 23:10

>>547
いくらなんでも納期の前日に交渉する奴は居ないと思うが……。いるのか？

549 ：デフォルトの名無しさん：04/09/01 00:00

>>547
そんな理由を客に述べてるんなら、それはそいつが馬鹿なだけだ。
技術以前の問題だな。

納期ではないが、オブジェクト指向の利点を客に語りたいなら、
初期費用は高いが保守費用は安い、とかそういう表現をするもんだ。

550 ：デフォルトの名無しさん：04/09/01 00:06

>>549
そのようなことは道徳的に誤っている。

551 ：デフォルトの名無しさん：04/09/01 00:27

>>549
実際、年間の保守契約料金を安く出来ないなら、詭弁であり詐欺である。

552 ：デフォルトの名無しさん：04/09/01 00:31

保守で稼ごうぜ、ただでさえモチベーションさがる仕事なんだしよう。

553 ：デフォルトの名無しさん：04/09/01 00:45

>>550
客と話すときは、システムを作る側ではなく、客の視点で語れと言っているのだ。
関係ないが、保守が安くならないって前提なのな、君。

554 ：デフォルトの名無しさん：04/09/01 00:46

人に言われて作るプログラミングほどモチベーション下がるものはないな．．．

555 ：デフォルトの名無しさん：04/09/01 00:50

>>554
学生さん？

556 ：デフォルトの名無しさん：04/09/01 00:54

こういうイタいスレ展開はマ板でやれよ

557 ：デフォルトの名無しさん：04/09/01 00:54

んにゃ。パッケージメイン

558 ：デフォルトの名無しさん：04/09/01 02:07

デザインパターン導入の真のメリットって，
共通タームを使うことによる，設計フェーズにおけるコミュニケーション精度の向上くらいかなあ。

559 ：デフォルトの名無しさん：04/09/01 02:09

まあ，一種のカルチャーだから，知らないと恥ずかしいくらいのデメリットしかないかもね。

560 ：デフォルトの名無しさん：04/09/01 02:12

一人だけ知らないと村八分にされるし，
一人だけ知ってても村八分にされる。
それだけの話。

561 ：デフォルトの名無しさん：04/09/01 02:41

デザインパターンの導入というか、オブジェクトの設計するとああなるんでないの？

562 ：デフォルトの名無しさん：04/09/01 07:32

デザインパターンを「導入」するって時点で、何か間違ってると思うぞ。
アルゴリズムだって「導入」はしねーべ。

563 ：デフォルトの名無しさん：04/09/01 07:55

>>558
真のメリットはコーディングの再利用以上に、設計の再利用。
GOF本の序章に書いてあったかな。しかしGOF本の序章は
デザパタを賛美しすぎてデザパタに対する誤解、過剰な期待をする原因でもあると思う。
本当に良いものなんだから自画自賛する必要は全く無いのに。

564 ：デフォルトの名無しさん：04/09/01 07:57

基礎知識に導入も糞もないよな
導入とか逝ってる時点でｲﾀｲ

565 ：デフォルトの名無しさん：04/09/01 08:04

>>563 自己分析乙

566 ：デフォルトの名無しさん：04/09/01 18:37

>>564
一人だけ知ってても村八分にされる。

567 ：デフォルトの名無しさん：04/09/01 19:10

＞566
デザパタも知らないソフトハウスやばくね？

568 ：デフォルトの名無しさん：04/09/01 19:34

･･･と言う事を学生や玄人気取りの引きこもりはよく言うわけです。

569 ：デフォルトの名無しさん：04/09/01 22:13

>>567
そんな事逝ったら、うちの会社はどうなっちゃうのよ？お？

570 ：デフォルトの名無しさん：04/09/02 06:20

結城氏の本、俺はだめだ。
きっちりした感じがだめだ。

571 ：デフォルトの名無しさん：04/09/02 07:25

日立の本はどうよ。これも入門書としていいぞ。

572 ：デフォルトの名無しさん：04/09/02 10:17

デザインパターン以前に、オブジェクト指向を知らないソフト会社とか
いっぱいあるでよ。

573 ：デフォルトの名無しさん：04/09/02 10:19

>>572
構造化を理解してないところも...orz

574 ：デフォルトの名無しさん：04/09/02 11:27

>>573
まあ、PHPやVBなら何とかなるけどな。

575 ：デフォルトの名無しさん：04/09/02 11:35

Delphiもなんとかなったようだどー

もう保守いや

576 ：デフォルトの名無しさん：04/09/02 11:53

VBの部署を手伝ったときに、サブルーチンや関数なんかはほとんど作らずに
イベントハンドラにコピペコピペで何百行もコードを書いてる先輩から、
「お前のコードはあちこち飛んで見にくい」と叱られたことがあるよ。

577 ：デフォルトの名無しさん：04/09/02 12:19

ドキュメントちゃんとしろよ

578 ：デフォルトの名無しさん：04/09/02 12:26

>>576
かわいそう…

579 ：575：04/09/02 13:08

>>576
おお、言語が違えど全く同じ。

DelphiをVisual Pascalとしてしか
つかっとらんのでコピペだらけでもう。

580 ：デフォルトの名無しさん：04/09/02 16:41

>>579
羽津かしながら、Delphiでコピペ三昧の経験あり

コピペ前提でスケジューリング。常に時間に追われているって事もあるし
周りがコピペしてると、自分だけ別のことできない。コードの整合性。仲間受けの問題
とにかく全体的な設計が無いから、デザパタなんて怖くて使えない。意味が無い・・・

まあ要するに会社のレベルは超えられない・超えてはならないつー事。
さくっと転職しました。

581 ：575：04/09/02 17:34

>>580
お察し致します。
他の人がいると、なかなか一人で良い事出来ないですよね。
頭の人が音頭取っていっちょやろうぜっていってくれると
いいけど、頭の人は新しい事やりたがらないし。

俺は出向先での話だから（といっても何年もいっぱなし）
自社に帰ってから小さ目の案件で羽を伸ばせました。

582 ：デフォルトの名無しさん：04/09/03 00:49

転職パターンのコンクリートカキコミがいっぱい。

583 ：デフォルトの名無しさん：04/09/03 01:00

>>580
そういうコードばかり書かされて、自己嫌悪の日々です。

言われない限りは、こっちの好きにやらせてもらうけど、
バレたら即書き直し。
無駄な努力かな？

584 ：デフォルトの名無しさん：04/09/03 01:08

>>583
非常に同情するが、バレなくても腐れコードを書け。
おまえ以外だれも保守できないコードを書いても意味がない。
おまえのせいで組織全体のパフォーマンスが落ちる。
勝手なまねをするな。それがサラリーマンだ。

585 ：デフォルトの名無しさん：04/09/03 01:17

>>583
>バレたら即書き直し。
この時点で無意味だろ。
賽の河原で石を積むのが生産的な作業か？

反逆者になりたくない？
では、革命家になりたまえ。

586 ：デフォルトの名無しさん：04/09/03 10:02

>>580
プログラムを外注に委託するとこんなコードばかりが納品される。
外注業者は全部こんなもん？

587 ：580：04/09/03 10:29

>>586
元請けだけどこんなもん

>>585
> では、革命家になりたまえ。
革命家は派手だが、どこかで命を落とすよ。

（別の会社の話・愚痴）
頭の人というか、少し階級が上がった時、OO良いよ。デザパタ使おうよ
運動を実施した。作業効率UP。社内革命。喜ばれた。

が、振り返れば、皆おんぶにだっこ。漏れが作った物・考えた事使っているだけ。
上司からは、すごいね～と褒められたけど、給料上がらず、ノルマあっぷ。

新人は、ぜひ教えてくださいと熱心だが、教えてもらうの当然って感じ。
授業料払って無いくせに・・・その上、転職を企んでいる。

で、OO・デザパタ導入なんだが、所詮は今回も会社のレベルに合わせた妥協の産物。
これ以上やるには、さらに上流の設計が重要。ツールも買ってもらわんと・・・

で、上の人と相談するが、話が噛み合わず・・・微妙に逆鱗に触れたらしい。
周りに気を使って、プライドを傷つけず、楽をさせ、手取り足取り教え、
成果を出し、整合性も考え、浮かないようにしたけど、やっぱり駄目。

その上、別件事件発生で、社内ごちゃごちゃ。無理な任務。命の危険が・・・
革命家は断頭台の送られる前に、逃げ出しましたとさ。

588 ：デフォルトの名無しさん：04/09/03 15:52

夢想家が作り話を語るスレですか？

589 ：デフォルトの名無しさん：04/09/03 21:01

おまえら基本が分かってない。

生産性を上げたって社員にはメリットがありませんよ。

590 ：デフォルトの名無しさん：04/09/03 21:21

生産性が上がらんと、メリット以前に会社無くなるけどな。

591 ：デフォルトの名無しさん：04/09/03 21:28

無駄な保守とかトラブルとかかかわらんでいいならいいがそでないなら自衛のためにやっておけ

592 ：デフォルトの名無しさん：04/09/03 21:33

>>590
そういう緊張感があればいいんだろうがな。
何やったって潰れないくらい経営的にはしっかりしてる。
その分だけ給料が安いけどな。

>>591
俺一人きちんとしてたって意味ないもの。プロジェクトだから。
料理の鉄人1名＋凡人10名＋林真須美1名でカレー作ったって食えないじゃん？

あと余談だが、デスマーチの発生に生産性はあまり関係がない。
営業とか管理がでかいな。

593 ：デフォルトの名無しさん：04/09/03 21:39

>>592
プロジェクトに林真須美が居ればスリルあるだろうなあ。
ニセの仕事でも与えてんの？

594 ：デフォルトの名無しさん：04/09/03 21:51

＞592
何つーかおまい負け犬の発想してるな

595 ：デフォルトの名無しさん：04/09/03 22:02

>>594
うむ。二戦二敗だからな。手に負えない。
夢とか希望を抱いてるなら羨ましいよ。

ちなみに無能でかつ学習する気がない連中が相手だ。
そして技術力を身につけても良い事がない職場だ。
何とかするコツがあったら教えてくれ。

596 ：デフォルトの名無しさん：04/09/03 22:03

よい環境に動け

597 ：デフォルトの名無しさん：04/09/03 22:09

>>596
協力会社やってるからさ、他の会社の人たちも一緒に仕事するんだけど、
どこの会社も似たようなものじゃないの？

業界が腐ってる気がするんだけど。

598 ：デフォルトの名無しさん：04/09/03 22:12

高度なものを作ってる会社はいくらでもあるぞ？
SI企業はどうかしらん。

599 ：デフォルトの名無しさん：04/09/03 22:36

>>598
例えばどんなところ？
正直想像がつかない。鬱だ。

600 ：デフォルトの名無しさん：04/09/03 22:50

>>599
同意。オレも想像つかない。

コンサルティング会社が入って体質改善できた実例も実際は聞いたことが１つも無い。
(文献はよく読むけど。）

601 ：デフォルトの名無しさん：04/09/03 22:57

>>599
Microsoft とか EA あたりどうよ？

602 ：デフォルトの名無しさん：04/09/03 23:11

金融系ならシンプレクステクノロジ。
実情はしらんがMAYA作ってるところなんかどうだ？

603 ：デフォルトの名無しさん：04/09/03 23:15

>>602
Maya といや、対応するビデオカード作ってるメーカーの方もスゴいわな。
設計に使ってる CAD システムとか、面白そうだ。

604 ：デフォルトの名無しさん：04/09/03 23:59

アジャイルスレって無いのな。

605 ：デフォルトの名無しさん：04/09/04 00:01

協調性がないのは社会人として問題。

606 ：デフォルトの名無しさん：04/09/04 00:10

http://pc5.2ch.net/test/read.cgi/tech/1091773629/
【XP】Agile Process 第2イテレーション【UP】

607 ：デフォルトの名無しさん：04/09/04 00:35

事なかれな協調性なんかｲﾗﾈ
奴隷帰れ

608 ：デフォルトの名無しさん：04/09/04 01:07

>>607
チーム開発なんて糞食らえなフリー学生がうらやましいっす。

609 ：デフォルトの名無しさん：04/09/04 01:11

もめてでも改革しろよボケ。うちはケンかしょっちゅうやってるぞ

610 ：夢のない男２号(!608)：04/09/04 01:22

>>609
それ人間関係に疲れないか？
そんなことで意思疎通がしづらくなって、仕事の能率が悪くなるのなんて嫌だし。
もう漏れは会社は給料もらうところだと割り切ってるよ

611 ：デフォルトの名無しさん：04/09/04 01:52

けんかするのは技術的な話だからな。
製品の売上と給料ほぼ直結してるからみな気合は言ってる.

612 ：デフォルトの名無しさん：04/09/04 06:04

いっけん人当たりのいい事なかれ主義のヤツは
後になってから「実は・・・」取り返しの付かないのが多い。
八方美人。最悪。

613 ：デフォルトの名無しさん：04/09/04 10:28

実は・・・すら言えない我が校の石像>>612がご迷惑をおかけしました。
こいつが就職率100%の名に泥を塗りそうで困っております。

614 ：デフォルトの名無しさん：04/09/04 10:38

意味不明な輪が請うの石造>>613がご迷惑をおかけしました。
コイツが就職率100%のナニ泥を塗りそうで篭っております

615 ：デフォルトの名無しさん：04/09/04 13:01

OK、俺が会社立てるわ
入社資格を持つのはここの連中だけな

最初は給料でないよ？

616 ：デフォルトの名無しさん：04/09/04 13:02

>>615
そして2日後に解散。

617 ：デフォルトの名無しさん：04/09/04 15:57

デザパタすれで、こんな事いうのも何だが
正直、技術力磨いても、あんまり意味無いよ。

IT長者見たって、技術者は居ないでしょ？
営業系の人ばっかり。

勉強＝技術者の良心・楽しみ・自己満足。

618 ：デフォルトの名無しさん：04/09/04 16:05

>>617
ばりばりの技術者ならこういうだろう

金儲けのためにやってるんじゃない

619 ：デフォルトの名無しさん：04/09/04 19:39

>>618
二秒でクビだな。

620 ：デフォルトの名無しさん：04/09/04 19:44

>>619
クビどころか重用される

621 ：デフォルトの名無しさん：04/09/04 19:53

>>620
誰にも読めないコードを書くんだから、嫌われるに決まってるじゃん。

622 ：デフォルトの名無しさん：04/09/04 20:01

>>621
確かに誰にも読めないコードを書くと嫌われるということはわかる

けど、いまいち話のつながりがわからないだけど…

623 ：デフォルトの名無しさん：04/09/04 20:04

>>618
0の状態から新しいモノを作るならそれでよい。
結局どうやってもできるもんに他人の受け売りの技術を使いたいと。

うふふ。

624 ：デフォルトの名無しさん：04/09/04 20:24

>>622
一人だけ高度な技術を駆使してソースを書いても、
その他の連中は無能だから読めないので嫌われるという意味。
技術者の自己満足とか評されるのもこのタイプ。
自分に何が求められているのか分かってないのだな。

誰にでも保守のできるコピペまみれの腐ったコードの方が、
高度な技術を駆使した誰にも読めない素晴らしいコードよりも、
会社にとって価値のあるコードだ。

全社員が無能でなくなればよいのだが、無理だろうな。

625 ：デフォルトの名無しさん：04/09/04 20:26

でも傷つかぬように嘘は繰り返される

626 ：デフォルトの名無しさん：04/09/04 20:30

>>624
デザパタが手放しでよい方法かと言われるとそれはそれで疑問な訳で。

かつて同じように鳴り物入りで出てきた技術はごまんとある。

て言うか技術なんて大層なもんでないっしょ？これ。
タダの手法。

事の本質は客を幸せにして会社の利益を追求すること。

そのために何をすればいいのかなんて本の上の理想論なんぞと一致するとは限らない。

それをはき違えている方々が一杯いると。

627 ：デフォルトの名無しさん：04/09/04 20:35

>>624
デザインパターンも高度な技術だとでも？
これは技術というよりも設計の定石のようなものであって、
保守性を高めるためのものであるから、
どこから引っ張ってきたのか解からないようなコピペの羅列を見せられるよりは
ましだと思うけどね。
それに、きちんと設計したものにはきちんとしたドキュメントも添えるのが
当り前だし、高度なアルゴリズムを実装したとしても、設計で分割され、
部分部分は非常に単純になる。

628 ：デフォルトの名無しさん：04/09/04 20:38

>>627
構造化指向入門ありがとうございました。

629 ：デフォルトの名無しさん：04/09/04 20:40

>>624
その前にコピペまみれの腐ったコードって今時あるのか？
うちの会社はそれほど良くもないけどコピペまみれのコードってのはないよ。
会社変えたら？

630 ：デフォルトの名無しさん：04/09/04 20:42

逆にコピペまみれで動くって事はしっかりモジュール化されてるって事では？

631 ：デフォルトの名無しさん：04/09/04 20:50

とりあえず、本題に戻して。

結城ヒロスィィの本は読み終わったので今度は「独習デザインパターン」って本を買ってきました。
GOFは見てみたけど、でかい上に字が小さくて、１ページ読むのも大変そうだったのでやめました。
日立の奴も買って全部、評価してやるぜぃ。

632 ：デフォルトの名無しさん：04/09/04 20:53

>>631
本買う前に物事の本質を見ろ。

633 ：デフォルトの名無しさん：04/09/04 20:54

こういうやつが厄介なんだよな

634 ：631：04/09/04 21:00

>>632の言う物事の本質って？例えば？

635 ：デフォルトの名無しさん：04/09/04 21:19

>>634
本の質。

装丁は丁寧か？
上質紙か否か？
フォントは美しいか？
でかい上に字が小さくて、１ページ読むのも大変そうではないか？

636 ：デフォルトの名無しさん：04/09/04 21:37

＞631
おまい本読んだだけじゃ意味ないんだぞ．理解してるのか？

637 ：624：04/09/04 21:40

>>627
デザインパターンなんてもう、超高度だよ。
俺の周りは継承がむずかしいとか、ポリモーフィズムが分からないとか、
そういうレベルだからね。勉強しないのが原因だと思うんだけど。

ちなみに俺は誰でも読めるように、あえて腐れコードを書いてる。
ってことは折角身につけた技術が無駄になってる事じゃん？
人にも勉強しろとは言えないよ。無駄に終わるのに。

>どこから引っ張ってきたのか解からないようなコピペの羅列を見せられるよりは
>ましだと思うけどね。

これには同意できない。
やってる事が分かるコピペの羅列の方が、ほとんどの奴が理解できない
綺麗なコードよりマシ。読めないコードに価値はないよ。

>>629
コピペまみれってのはちょっと誇張があった。すまん。でも腐ってるよ。
いろんな会社の人が作ったコードを見たけど、まともなのは無かったな。
たぶん、各社一名くらいは趣味で技術を覚えたまともな人がいると思うんだけど、
その他の奴が無茶苦茶にしてるんだと思う。

>>630
別にしっかり動いてないもの。一見動いてるだけ。

638 ：デフォルトの名無しさん：04/09/04 21:41

>>636
本読んで物作って誰かの役に立って改良して末永く誰かの役に立つ！

これだよね（キラーン）

639 ：デフォルトの名無しさん：04/09/04 21:41

>>637
なんか小さい人間だなぁ。とだけ。

640 ：デフォルトの名無しさん：04/09/04 21:49

>>639
大物とお見受けしました。
現状を打破する知恵をお授けください。

641 ：デフォルトの名無しさん：04/09/04 21:52

＞たぶん、各社一名くらいは趣味で技術を覚えたまともな人がいると思うんだけど、

どこにでもいるんだよな・・・技術ヲタ。

642 ：デフォルトの名無しさん：04/09/04 21:53

>>639
ちなみに今のところ、誰にでも読めるコードを書く事によって、
組織としてのパフォーマンスを最大にする事を目標にしております。

643 ：デフォルトの名無しさん：04/09/04 21:56

>>642
それで正解。企業の目的は営利の追求と社会の発展だ。
趣味の昇華は余所でやればよい。

644 ：デフォルトの名無しさん：04/09/04 22:03

つかおまいらどんなもの作ってるの？

645 ：デフォルトの名無しさん：04/09/04 22:12

プログラミングは趣味でやるのが最良かと

646 ：デフォルトの名無しさん：04/09/04 22:19

話にならないな。
技術の進歩もなにもあったものじゃない。

647 ：デフォルトの名無しさん：04/09/04 22:21

>>646
協調性のないヲタ社員。

て言うかお前学生だろ。

648 ：デフォルトの名無しさん：04/09/04 22:24

>>646
＞技術の進歩もなにもあったものじゃない。

それはなにも無いところから何かを生み出した人のセリフです。
それは通常企業の至上命題ではありません。

今からでもそう言うのに理解のある幹部のいる会社に行けばどうだ？
陶器の形を変えるより望みの形の陶器を探す方が簡単だぞ？

649 ：デフォルトの名無しさん：04/09/04 22:43

妙に負の方向に悟った奴らウゼェ

自分の糞会社を基準に物事を考えるな

650 ：デフォルトの名無しさん：04/09/04 22:44

なんかまた極端な論理展開の応酬が…
業務の効率の改善につながる技術があるとしたら採用を検討してみたりするもんだろ普通は。
普通のことができにくい業界ではあるけどさ。

651 ：デフォルトの名無しさん：04/09/04 22:46

＞業務の効率の改善につながる技術があるとしたら採用を検討してみたりするもんだろ普通は。

皆の中で検討した結果葬られたから上がってこないのでしょう。

652 ：デフォルトの名無しさん：04/09/04 22:47

>>649
その糞会社で悶々としてるのはお前では？

653 ：デフォルトの名無しさん：04/09/04 22:52

>>652
会社では悶々としてないな

こういう系のスレを、お前らのようなバカがみんな糞スレにしてくれる

そんな糞スレで悶々しているのがオレだ

654 ：デフォルトの名無しさん：04/09/04 22:53

もうこのスレは見てもプラスにはならないな、と思いつつ見てしまいました。
おかあさんごめんなさい

655 ：句読点書けないバカをサマージャンボする俺 ◆9NQzQ21lx. ：04/09/04 22:55

>>653

656 ：631：04/09/04 22:56

協調性うんぬんの前にここはデザインパターンを語るスレなのでは？
確かに会社では協調性のあるコードを他人にわかりやすいコードを重視するべきだが、
ここはそんなものを無視して、デザインパターンについてお勉強するスレだと思うのだが。

>>635
不覚にもﾜﾗﾀ

>>636
自分では理解できてると思ってます(´∀｀；）ゞ

657 ：デフォルトの名無しさん：04/09/04 22:58

>>656
じゃあまず会社で云々とか言い出した奴を糾弾すべきでは？

658 ：デフォルトの名無しさん：04/09/04 22:58

>>650
>業務の効率の改善につながる技術があるとしたら採用を検討してみたりするもんだろ普通は。
で、問題になっているのは大抵小手先のテクでは無くて要件定義そのものだったと。
兵器の性能向上(＋兵隊の練度)だけでは戦闘には勝てるだろうが戦争には勝てないよなぁ。

659 ：デフォルトの名無しさん：04/09/04 22:59

>>655
ハァ？

>こういう系のスレを、お

字も読めない池沼か。もう死ねよ

660 ：デフォルトの名無しさん：04/09/04 22:59

これ以上はマ板行け

661 ：デフォルトの名無しさん：04/09/04 23:00

>>660
お前がな。

662 ：631：04/09/04 23:01

>>657
糾弾するスレでもないからもういいんじゃないか。
トイレットペーパーのようにさっとふき取って水に流そうや。

663 ：636：04/09/04 23:02

＞656
んにゃデザインパターンを適用するのにトラブルあるってことでこういう話題もいいのでは．

んー本読むの楽しいんだけどそうすると段々自分で物事考えなくなるんで．．．その境目が難しい．．．

664 ：デフォルトの名無しさん：04/09/04 23:06

次からスレタイ

　　デザバタ盲信教

にしてくれ

665 ：631：04/09/04 23:08

>>663
おお、それもそうですね。
どういった状況で適用すべきか。というのも確かに有益な情報。
とりあえず、上の展開を見ると業務系の開発ではあまり使わない方がよさそう。

666 ：デフォルトの名無しさん：04/09/04 23:10

>>665
使わない方がよいのではなくて、使おうとするのが困難。

667 ：636：04/09/04 23:15

ぶっちゃけ業務系とかで必要ないなら無理に使うことないんでね．構造化でもいいじゃない．
自分は慣れてるので使うけど。コピペは許さんが。ありえん。

668 ：デフォルトの名無しさん：04/09/04 23:34

>>664
お前はアンチデザパタスレやアンチOOスレでも立てて、
そこでお前の会社がいかに糞かを主張しててくれや。

669 ：デフォルトの名無しさん：04/09/04 23:45

めづらしく書き込みが、と思ったら
荒らしが湧いたのか…orz

670 ：デフォルトの名無しさん：04/09/05 02:21

ペアプログラミングを取り入れましょうと言って来たヤツが居たので余裕で無視。オレは忙しいんだ。
javaを使っている部署に居る同僚がうやらましくてコードを見せてもらったら1クラス余裕で3000行。言語は関係ないなと実感。

671 ：デフォルトの名無しさん：04/09/05 06:41

>>670
1機能1モジュールでクラスが肥大化するのは仕方ないと思われ。
肝心なのはカプセル化ですよ。中身なんてどうでも良い。

672 ：デフォルトの名無しさん：04/09/05 07:23

問題と対策はこんな感じ？

似てるんだけど、ちょっとずつ違う・・・継承
あっちに飛んだり、こっちに飛んだり・・・モジュール化
（変数を）あっちで変更、こっちで変更・・・カプセル化
この部分だけ再利用したいのよ・・・クラス細分化・モジュール化
仕様変更ドミノ倒し・・・細分化・モジュール化＋融通の利く仲介クラス

673 ：デフォルトの名無しさん：04/09/05 07:30

>>672
？

674 ：デフォルトの名無しさん：04/09/05 08:58

>>672
>似てるんだけど、ちょっとずつ違う
テンプレート。その他多数のでざぱた

675 ：デフォルトの名無しさん：04/09/05 09:14

>>674
盲信してますね。

676 ：デフォルトの名無しさん：04/09/05 10:33

>>631
独習より結城本の方がレベルが高い希ガス。

677 ：デフォルトの名無しさん：04/09/05 10:36

デザパタで成功した開発事例キボンヌ

678 ：デフォルトの名無しさん：04/09/05 11:17

>>676
結城本、サンプル・コードは良いのだが、本文が駄目駄目
本文読んだら、コードの意味が分からなくなる。

679 ：デフォルトの名無しさん：04/09/05 11:43

結城本わかりやすいが。

初心者本をしっかり読んで基礎を固めないとちんぷんかんぷんというのは同意。
でも、あそこまでつっこんだハイレベルな記述してる本って他にないよな。

680 ：デフォルトの名無しさん：04/09/05 11:58

著名な元本（GOFなのか？）があると駄目という典型。
GOFマンセーな人には、馴染み易いのかもしれないが・・・

ところで、結城本の前に読むべき、初心者本って何？

681 ：デフォルトの名無しさん：04/09/05 11:58

結城本読んでないのだがGOF本とはまたちがうの？

682 ：デフォルトの名無しさん：04/09/05 12:03

>>680
一行目の日本語がどうしてもparse errorになるんだが。

683 ：デフォルトの名無しさん：04/09/05 12:08

>>680
結城本って十分初心者向きだとおもうんだけど…

684 ：デフォルトの名無しさん：04/09/05 12:10

>>680
憂鬱なプログラマのためのオブジェクト指向開発講座。
すこし古いけれどわかりやすい。

685 ：デフォルトの名無しさん：04/09/05 12:23

>>678が無能という結論に至ってしまうのでこれ以上は言及しないことにしないか？

686 ：デフォルトの名無しさん：04/09/05 12:23

デザインパターンに興味をもって、
このスレに来るようなレベルの人間なら
結城本からはじめても構わないような希ガス

687 ：デフォルトの名無しさん：04/09/05 12:27

そういえば先週まで近所の本屋にたくさん積んであった結城本が売り切れてました。
デザインパターンって結構注目されてる？
デザインパターンが当たり前の時代が来るのかねぇ。

688 ：デフォルトの名無しさん：04/09/05 12:27

>>687
邪魔だったので返本しただけです。

689 ：デフォルトの名無しさん：04/09/05 14:40

結城氏の著作はダメ発言は説得力が無いものばかり。
ページ数まで書いて具体的に言ってくれ。

690 ：デフォルトの名無しさん：04/09/05 15:12

>>689
作者乙

691 ：デフォルトの名無しさん：04/09/05 15:15

>>690
お前ソレばっかだな。具体的に言えないなら出てこないでいいから。

692 ：デフォルトの名無しさん：04/09/05 15:21

結城のキリスト教マンセーうざい

693 ：デフォルトの名無しさん：04/09/05 15:37

1000

694 ：デフォルトの名無しさん：04/09/05 15:42

>>689
うーん、例えばAbstract Factoryパターン

「抽象的な工場では、抽象的な部品を組み合わせて抽象的な製品をつくります」
「部品の具体的な実装には注目せず、インターフェース（API）に注目する」
「そして、そのインターフェース（API）だけを使って、部品を組み立てて、
製品にまとめるのです」

間違っているわけじゃないけど、分かり易くは無い。
Factory->工場・製品と例え話をしたつもりだろうが、微妙に的外れ。

695 ：デフォルトの名無しさん：04/09/05 15:44

>>694
理解力無いだけじゃないの？

696 ：デフォルトの名無しさん：04/09/05 15:55

>>695
太字以外に１ページも使って、うだうだ例え話はちょっとね。
出来の悪いコードを見ているようで、苛苛する。

ページ数水増しか？

697 ：デフォルトの名無しさん：04/09/05 16:01

「互いに関連したり依存し合うオブジェクト群を，その具象クラスを明確にせずに生成するためのインタフェースを提供する」
の方がスッキリしている。

698 ：デフォルトの名無しさん：04/09/05 16:21

>>697
じゃあ勝手に本書けよ。

699 ：デフォルトの名無しさん：04/09/05 16:48

>>698
だからさぁ。
結城本、サンプル・コードは良いのだが、本文が駄目駄目って事。

700 ：デフォルトの名無しさん：04/09/05 16:48

>>699
批評しかできないヲタ

701 ：デフォルトの名無しさん：04/09/05 16:58

>>694
同意。
あの説明では「A工場からA製品」「B工場からB製品」「C工場からC製品」と拡張しろと
言っているようにしか読めない。分かりにくいよりも明らかな間違い。
手元に本が無くて確認してないんだがオレの理解力が問題かな？突っ込み待ち。

702 ：デフォルトの名無しさん：04/09/05 17:43

685デフォルトの名無しさん[sage] 04/09/05 12:23 ID:
>>678が無能という結論に至ってしまうのでこれ以上は言及しないことにしないか？

↑
これが木に触ったのか？謝った方が良いか？

703 ：デフォルトの名無しさん：04/09/05 17:55

　　　　　　　　　　　　　　　　　　　　　　　/　　気　　!
　　　　　　　　　　　　　　　　　　　　　　　　　　 l　　　　　　|
''''''''''‐-､, 　　　　　　　　　　　　　　　　　　　 |　　に　　｜
::::::::::::::::::::＼　　　　　　　　　　　　　　　　　　 | 　　　　　|
:::::::::::::::::::::::::ヽ　　　　　　　　　　　　　　　_,,,,,,_ .|　　　す　　|
:::::::::::::::::::::::::::::':, 　　　　　　　　,.-''"::::::::::::｀l　　　　　|
::::::::::::::::::::;ﾍ::::;::i 　　　　　　　　／::::::::::::::::::::::::|　　る　　 l
::::::::::::::::::::'､|ヽ!ヾ　　　　　　　/::::::::A:::;::::/!::ﾑli 　　　　　|
:::::::::::::::::::､:'､　　　　　　　　,':::::::::ハ;ハ;l ﾚ' '|ヽ　な　　/
:::::::::::::::;:::| `!　　,.,.._　　　　　ﾚi::;lV. ┃　　 ┃''"ﾑ　　／
::::::/l:::ハ:|,/　　i　ヽﾍ,　　　　　　 '〈|　　　　　　　　　ソ'''''､
:::/ ,|/,,／　　　',　 l, ヽ.　　　　　　 l､　　 r一‐:､　 /:::::::::::'､
/　| ''　　　　　　＼丶.ll''r､.,_　　　/::`':.､ヽ--‐',.イ､::::::::::::::'､
:‐┴:､.　　　　　　　`i''y'l |: : : ｀`''ヽ‐''ヾil´`i';､''" /　 >､:i､::::::',
　　　＼　　　　　　 '-'､/ : : : : : : :`: : : lL,, l　　/_ ,//: :＼'､;::､

704 ：デフォルトの名無しさん：04/09/05 19:47

デザインパターンの話題になると、結城の本の話で盛り上がるｗｗ
実際にパターンを使うとかじゃなくてｗｗｗ

705 ：デフォルトの名無しさん：04/09/05 19:48

技術の話と違って人の話は馬鹿でもできるしな。

706 ：デフォルトの名無しさん：04/09/05 21:12

と文句を言う奴に限って、碌な話題を提供できない。

707 ：デフォルトの名無しさん：04/09/05 21:32

>>677
構造化で成功した開発事例キボンヌ

708 ：デフォルトの名無しさん：04/09/05 21:35

>>696
初心者にわかりやすいだろ。
知っている人が読んだらそらいらいらして普通。

709 ：デフォルトの名無しさん：04/09/05 21:48

>>707
システムの一部分をごっそり他のシステムへ転用する時
本当に必要な部分だけ、取り出す事が出来れば、
構造化はかなり上手く行っていると思われ。

710 ：デフォルトの名無しさん：04/09/05 21:51

システムの一部分をごっそり他のシステムへ転用する時
本当に必要な部分だけ、取り出す事が出来れば、
オブジェクト指向はかなり上手く行っていると思われ。

こっちの方がしっくりくるんだが

711 ：デフォルトの名無しさん：04/09/05 21:54

>>677
Java。の標準クラスライブラリ

712 ：デフォルトの名無しさん：04/09/05 22:01

>>710
基本的には目標は同じだからね

713 ：デフォルトの名無しさん：04/09/05 22:05

つかオブジェクト指向で設計してくとおのずからデザパタ的になると思うが．．．

714 ：デフォルトの名無しさん：04/09/05 22:15

>>713
デザパタ知らん奴は、デザパタとは程遠い物
デザパタ知っているだけの奴は、デザパタと似ているだけの物
を作ってくれる。

715 ：デフォルトの名無しさん：04/09/05 22:59

>>711
javaはある意味成功

716 ：デフォルトの名無しさん：04/09/05 23:04

デザインパターンもいいけど、関数型のスタイルも場合によっては良いものだよ

717 ：デフォルトの名無しさん：04/09/05 23:58

>>714
＞デザパタ知らん奴は、デザパタとは程遠い物
＞デザパタ知っているだけの奴は、デザパタと似ているだけの物
＞を作ってくれる。

GoFのはじめにを読み直せ

718 ：デフォルトの名無しさん：04/09/06 00:01

>>716
でも今更Prologとかでアプリ組みたくないっす・・・。

719 ：デフォルトの名無しさん：04/09/06 00:09

>>716
関数型ってーと、λ計算とかのやつ?

720 ：デフォルトの名無しさん：04/09/06 00:25

>>718
Prolog は論理型。関数型だと Lisp, Scheme, Haskell あたり。
>>19
Yes.
関数そのものを動的に構成できるのと、変数の書き換えを原則として行わない
（ループの代わりに関数再帰呼び出しを使うとか）のが特徴。

C++ テンプレートまわりが、かなり関数型風味。C++ だと実行時に関数を動的
構成するのは無理だが、コンパイル時に動的構成するのは可能。bind1st とかね。
またテンプレート仮引数は演算不可なので、必然的にテンプレートメタ
プログラミングは関数型言語っぽいスタイルになる。

>>716
で、唐突に何で関数型の話が出てきたんだ？

721 ：デフォルトの名無しさん：04/09/06 00:32

>>720
C言語の関数主義みたいなのと混同してるんだと思われ。

て言うか知ってて言ってないか？

722 ：デフォルトの名無しさん：04/09/06 00:44

>>721
そこまでバカじゃない

723 ：句読点書けないバカをサマージャンボする俺 ◆9NQzQ21lx. ：04/09/06 00:47

>>722

724 ：デフォルトの名無しさん：04/09/06 00:49

>>720
いや、オブジェクト指向だけが至高の考えかたでは無いという意味で…

725 ：デフォルトの名無しさん：04/09/06 00:57

まぁどっちにしろコピペはありえん

726 ：デフォルトの名無しさん：04/09/06 01:08

Cにクロージャがあればオブジェクト指向イラネ

727 ：デフォルトの名無しさん：04/09/06 06:26

デザインパターンを勉強するために
オブジェクト指向における再利用のためのデザインパターン
とかいうの買って読んでたんだが…
これがGoF本だったのね＿|￣|○

728 ：デフォルトの名無しさん：04/09/07 00:19

>>727
いまどきjavaではない本をよく選んだね。

729 ：デフォルトの名無しさん：04/09/07 03:52

Ａ「デザパタって糞だな。」
Ｂ「デザパタ嫁。デザパタに、デザパタは素晴らしいって書いてある。少しはデザパタ勉強しろ。」

730 ：デフォルトの名無しさん：04/09/07 05:38

>>728
Javaは好きじゃないので。
先頭小文字のメソッドとか

731 ：デフォルトの名無しさん：04/09/07 09:15

たしかにGoFの問題点を指摘すると、GoFに良いって書いてあるだろみたいなのいるね。
それって根拠になるのかと小一時間・・・

732 ：デフォルトの名無しさん：04/09/07 16:05

スレ伸びてたから一瞬嬉しかったけど、
伸びたら伸びたでつまらんレスばかりだなぁ…

733 ：デフォルトの名無しさん：04/09/07 16:17

>>732
それは違う
馬鹿でも語れる幼稚な話題
主観で語っても反論が来にくく、気持ちよく自己満足に浸れる話題

などだからこそ、スレが伸びるんだよ
各言語スレ見てみても分かるだろ

734 ：デフォルトの名無しさん：04/09/07 16:55

>>731
そのすぐそばに盲信はするな。今から述べる理想型がどこでも使えると思うな。と書いてあるんだけどな。

それは完全なファクトリ者ねぇよばーか。とか言う奴ってちゃんちゃらおかしい訳で・・・。

735 ：デフォルトの名無しさん：04/09/07 17:35

>>732
デザパタは道具だからね。
使う対象が無いと、あんまり面白くない。

オープンソースなアプリを題材に、ここはこのパターンだろ。
ありえない。みたいなスレになってくれれば、かなり面白い。

736 ：デフォルトの名無しさん：04/09/07 17:41

>>735
既に動いてるもんに文句付ける必要なんてないっしょ。
事の本質を見ろよ。

737 ：デフォルトの名無しさん：04/09/07 18:14

> 既に動いてる

定番だなw

738 ：デフォルトの名無しさん：04/09/07 18:47

>>729
その例だと、根拠を明示しているだけＢの方がマシな気がする。
理由もなしに糞呼ばわりって終わってると思うけど。

739 ：デフォルトの名無しさん：04/09/07 19:35

>>736
そんな事言ったら、何にも出来んよ。
既に生きてるんだから、医学の研究しちゃ駄目みたいな話。

740 ：デフォルトの名無しさん：04/09/07 19:57

今日からここはリファクタリングを語るスレになりました。

741 ：デフォルトの名無しさん：04/09/07 20:04

>>739
人は様々な要素で変化するがソフトウェアは変化しない（変なウイルスはこの際除いてくれ）。

742 ：デフォルトの名無しさん：04/09/07 20:31

>>736
つまり、「火打ち石があるからライターは要らない」
または「ライターがあるからガスコンロは要らない」ということか。
がんばってライターで鍋料理作ってくれ。

743 ：デフォルトの名無しさん：04/09/07 20:33

>>742
カップラーメンを作るのに原発の1次系の水持ってこい。それ以外認めん！

とほざいてる奴が何人かいるのは仕様ですか？

744 ：デフォルトの名無しさん：04/09/07 20:43

原発作る人とカップラーメン作る人が一緒に書き込んでるからね。

745 ：デフォルトの名無しさん：04/09/07 22:02

ただ一つ言えることは

　厨　は　キ　モ　イ

746 ：デフォルトの名無しさん：04/09/07 22:08

>>745
きもいっていうやつがきもいんだぞ

747 ：デフォルトの名無しさん：04/09/07 22:13

既存のシステムを再分析して研鑚をつむのはいいことだぞ。スレのネタにもなるし。
暇なら今後も付き合うライブラリの糞ソースもごりごりリファクタリングしてしまえ。
動けばいいで済むならデザパタはいらんのじゃ。

748 ：デフォルトの名無しさん：04/09/07 22:18

ボーイング747

749 ：デフォルトの名無しさん：04/09/07 22:22

Bridgeパターンは、Templeteパターンより偉いですか？

750 ：デフォルトの名無しさん：04/09/07 22:23

>>736
ホンキで言ってる？

再利用のえらい人たちをなぎ倒すような発言だな。

751 ：デフォルトの名無しさん：04/09/07 22:29

>>750
事の本質を見なさい。

752 ：デフォルトの名無しさん：04/09/07 22:32

というか
>>747 とか >>750 のほうがホンキかって感じだよ
俺のプロジェクトにいたら即クビにするね
自己満足の趣味でシステム壊す気かよ
お前には本当にデザパタは毒にしかなってない

753 ：デフォルトの名無しさん：04/09/07 22:32

>>750
フォースを感じなさい。

754 ：デフォルトの名無しさん：04/09/07 22:36

>>752
「オープンソースなアプリを題材に」だろ

755 ：デフォルトの名無しさん：04/09/07 22:36

>>752
同意。ソース指向の奴が多すぎる。
コーディングは単なる過程であることを認識しないといけない。

756 ：デフォルトの名無しさん：04/09/07 22:37

>>752
うーん。いいものをもっと良くしようって気はないの？
車だって走ればいいのか？
燃費よくしたり、操作性よくしたり、完成した後でも色々改良点はあるだろ。

とまあそんな感じのことを>>747や>>750は言いたいんだと思うが。

757 ：デフォルトの名無しさん：04/09/07 22:38

>>754
自分のプロジェクトもソースがすべてオープンになっていることには変わりない。

そこにいるのは今そこにあるコードを引っかき回して再試験の憂き目にあわせるのが趣味のお荷物か、
それともその勇気が無く他人のコードに対して陰口をたたくだけの陰湿なだけの人間か。

758 ：デフォルトの名無しさん：04/09/07 22:39

>>756
それはコーディングレベルでやらずに設計レベルでやることです。

759 ：デフォルトの名無しさん：04/09/07 22:42

>>747
同意。「動けばいい」と言うヤツこそ首だ。

752のプロジェクトは完成しない。
または納品先の客は不満だらけで完成。
もしかしていまどき「仕様変更は出来ません」なんて言葉がまかり通ってる？

760 ：デフォルトの名無しさん：04/09/07 22:46

>>759

>>758

761 ：デフォルトの名無しさん：04/09/07 22:47

×動けば良い
○既に動いている物に変更に要するコストを支払う価値は無い

その辺曲解するな。

762 ：デフォルトの名無しさん：04/09/07 22:52

>>761
趣味の人には分からんのでしょう。
ソースをいじった結果がバグになってもマイナーバージョンを1上げればすむ話とかその程度の認識。
それをコストとして計上しろという方が無茶。

763 ：デフォルトの名無しさん：04/09/07 22:55

>>761
それだとデザインパターンの話題が振りにくいと思うんだが。
デザインパターンの話題を盛り上げていくために、
とりあえず既存のオープンソースをリファクタリングしようという話の流れではないの？

「既に動いている物に変更に要するコストを支払う価値は無い」とか関係ない。
ここはデザインパターンで盛り上がれればいいわけさ。

764 ：デフォルトの名無しさん：04/09/07 22:55

>>758
貴方の設計はコーディングに入ってからの仕様設計の修正は一切無いのか？
それなら神。

コーディングに入ってからユーザーの仕様変更要求は無いのか？
無い世界なら幸せだね。

またはプロジェクトが小規模なだけだったりー。またはcobol辺りでバッチ処理？

765 ：デフォルトの名無しさん：04/09/07 22:57

>>763
「あえて」やろうということなら否定する気は全くないけど、759はそうではない。
なぜかクビとか持ち出してるし。

766 ：デフォルトの名無しさん：04/09/07 22:59

>>765
それは>>752の人がクビとか言い出したから>>759も言ったのでは？

767 ：デフォルトの名無しさん：04/09/07 23:01

>>764
設計が良けりゃ必然的にコードも整理される。
仕様変更に柔軟に対応するにはそれを念頭に設計を行わなければならない。
無理のある仕様変更なら設計フェーズの時点で無理が生じる。

仕様変更->ソース変更ってのは日曜大工のすることだよ。

>>763
どっちかというとUMLをコードに落とす際にこんな風にデザパタを適応すれば違和感なく記述ができる。
とかそっちに絡めていった方が良いと思われ。

768 ：デフォルトの名無しさん：04/09/07 23:01

>>764
仕様とか設計とかがどんなものか調べる事をオススメするよ。
仕事でプログラムを組むときは箇条書きが設計書になるわけじゃないんだよ。
プログラムの構造にかかわる事をプログラマの裁量で好き勝手に実装できると思っているの？

プロジェクトが小規模とかcobolとか馬鹿にする前に
もっと基本に目を向けないと話にならないよ。

769 ：デフォルトの名無しさん：04/09/07 23:03

>>766
752は関係ない。759が例を曲解してまで挙げ足取りをしているから、
そこのところを指摘しただけであって、オープンプロジェクトを例に～の話の流れと直接関連があるわけじゃないもん。

770 ：デフォルトの名無しさん：04/09/07 23:03

つうか、勉強の為にやるんだからさぁ、
事の本質とか意味不明な戯言いってんじゃねぇよ。

ちょっと前に書いたばっかしだろうが。
お前の糞会社自慢なんかきいていねーんだよ。
アンチしたいだけならそれ用のスレでやれや。

771 ：デフォルトの名無しさん：04/09/07 23:04

>>768
＞仕事でプログラムを組むときは箇条書きが設計書になるわけじゃないんだよ。

だらだらとした文章がそれになるわけでも無いけどな。

772 ：デフォルトの名無しさん：04/09/07 23:04

あ、キレた。
ここはマンセースレでもないんだから、アンチがいても不思議はないでしょう。

773 ：デフォルトの名無しさん：04/09/07 23:07

>>770
その勉強の方針が間違っていると言っている。

GoFの序章300回書き取れ。

774 ：デフォルトの名無しさん：04/09/07 23:08

嵐も楽しいけど、デザパタと関係ある話にしないか？そろそろ

775 ：デフォルトの名無しさん：04/09/07 23:09

結局、ソースって評価されないもんなぁ・・・。

776 ：デフォルトの名無しさん：04/09/07 23:12

>>768
完璧な設計、変更の無い仕様書。
自分には出来ない。
参考書など勉強の仕方を教えて欲しい。

777 ：デフォルトの名無しさん：04/09/07 23:15

リファクタリングするとバグが出てコストが嵩むというのが前提なんだなｗ

778 ：デフォルトの名無しさん：04/09/07 23:15

>>774
ホビーや勉強ではなく仕事としてデザパタやアジャイルプラクティスは真に有効なのかは興味有る。

779 ：デフォルトの名無しさん：04/09/07 23:16

オプソのソース使って云々言ってた君は、こんな感じで勉強すればいいと思うよ。

1. オプソのソースからソフトウェア構造を洗い出す。
2 その.ソフトウェア構造を再利用性や保守性などテーマを決めていじってみる。
3. できた新ソフトウェア構造にデザパタを当てはめてみる。
4. おお。なんか効率良さそうじゃんとほくそ笑む。

仕様書のない悲しいシステムをいじるときの定石（ある種のデザインパターン）だけどね。

ココデザパタ使えんのに使ってねぇじゃん。ﾌﾟﾌﾟｰ

ってのは勉強になってないんで注意した方が良いっす。

780 ：デフォルトの名無しさん：04/09/07 23:20

>>777
大きく間違ってないよ。
新規コードとシステム全体に対しての試験は当然必要。つまり試験に対するコストが発生する。
未試験のコードにはバグがいると考えるのは大前提と考えるがどうか？

話は変わるがSONYの偉い人は、

「設計から量産まで全部やりなさい。」

と言う文句を残しているよ。

量産まで任されたらその人は初めっから量産を意識して設計を行う。
そうすれば量産用に図面を引き直すコスト（時間、人件費）を削減できると言う話。

781 ：デフォルトの名無しさん：04/09/07 23:27

>>777
きっと、設計が良いからファクタリングする必要のあるコードは存在しないのが前提なんだよｗ

782 ：デフォルトの名無しさん：04/09/07 23:32

>>780
それは根本的な部分ですでにデスマーチの隊列に加わってるってことだな。
脱出成功を祈る。

>>777
どこを弄るかはセンスの見せ所だな。デザパタ適用するかどうかは別にしても。
糞ライブラリは「バグうちでの小槌」なんで文句言われても改訂しちゃっていいと思う。
そういうのはたいがい文句は言っても元には戻せないｗ

この辺のバランス感覚の優れたマネージャがいるといい職場になるかもな。
実際には保守性を上げたり過去を再分析することを絶対善だと思ってる奴と、
そういう作業が出来ないためにルサンチマン燃やして「余計なこと」としか見ない
奴との戦場だがな。ﾊﾊ、、

783 ：デフォルトの名無しさん：04/09/07 23:34

>>781-782
的外しすぎ

784 ：デフォルトの名無しさん：04/09/07 23:38

＞プロジェクトが小規模とかcobolとか馬鹿にする前に
＞もっと基本に目を向けないと話にならないよ。
確かに言い方悪かった。スマ。

デザパタやリファクタリングが必要ない分野も多く存在すると言いたかっただけ。

785 ：デフォルトの名無しさん：04/09/07 23:38

事の本質云々ほざいてたキミは、こんな感じで勉強してるんだね。

1. 2chで、相手をバカに出来たるようなスレを洗い出す。
2 その.スレを再利用性や保守性などテーマを決めていじってみる。
3. スレに自分の考え、価値観を押し付けてみる。
4. おお。なんかオレって頭いいじゃんとほくそ笑む。

2chの厨の定石（ある種のデザインパターン）だけどね。

ココオレの価値観と違うじゃん。ﾌﾟﾌﾟｰ

っての厨丸出しなんで注意した方が良いっす。

786 ：デフォルトの名無しさん：04/09/07 23:39

>>781
将来起こるあらゆる仕様変更にも、改変なしで耐えられるソースコードか・・・
現実がオモイ。

787 ：デフォルトの名無しさん：04/09/07 23:40

>>785
別人だけど、それここのデザパタ厨。

788 ：デフォルトの名無しさん：04/09/07 23:41

>>786
逆にそんなことで来たら俺らなんていらん訳でな。

789 ：デフォルトの名無しさん：04/09/07 23:42

>>782
「そういう作業が出来ないために」
この表現よく分かる！

790 ：デフォルトの名無しさん：04/09/07 23:43

ドライビングテクニックにこだわるタクシーの運ちゃんはプロとして失格って話だろ。

791 ：デフォルトの名無しさん：04/09/07 23:46

>>787
ここの？匿名掲示板で他のスレに出てくる奴が、
ここのスレの奴だって判別できるのか？エスパーか？

確定なのは、デザパタスレにでしゃばってるお前だけ。

792 ：デフォルトの名無しさん：04/09/07 23:46

ドライビングテクニックにこだわらないレーシングドライバー
あ、結構居るか（ｗ

793 ：デフォルトの名無しさん：04/09/07 23:47

またわけの分からん例えを。

794 ：デフォルトの名無しさん：04/09/07 23:47

> デザパタやリファクタリングが必要ない分野ある

同意。
けど、これについてこのスレでやる意味はあんま無いと思う。

795 ：デフォルトの名無しさん：04/09/07 23:48

静的な仕事やそもそもリファクタリングでメリットが出ない状況を念頭において
「ソース弄るな」って言うのと、流動的な仕事を念頭において「ソース弄れ」って言うのは
どうも非生産的になるね。

796 ：デフォルトの名無しさん：04/09/07 23:48

>>792
結局の所相手より速く走れりゃなんでも良い訳だ。
そうするためにはドライビングテクが必要になってくる。

単純にそれだけの話。

ドラテクだけ磨いてレースに出ないレーサーに意味はない。

797 ：デフォルトの名無しさん：04/09/07 23:50

>>795
リファクタリングなんぞする暇合ったら初めっから再利用を前提とした設計をした上で
コード規約作ってアホな名前付けるボケを排除しろと。

798 ：デフォルトの名無しさん：04/09/07 23:51

オヤジくさい例えが続く。面白いけど。

799 ：デフォルトの名無しさん：04/09/07 23:53

鶏と卵なボケも早めに排除してください

800 ：デフォルトの名無しさん：04/09/07 23:55

で、結局のところ再分析してﾆﾔﾆﾔしてはいかんのか？してもいいのか？

801 ：デフォルトの名無しさん：04/09/07 23:57

実際リファクタリングってどうなの？

出荷後のシステム->気に入らん所変更->バグあり糞システム（何に使うんですか？）
　　　　　　　　　　　　　　　　|
　　　　　　　　　　　　　　　　->出荷物と同程度の試験->出荷する予定のない改変されたシステム
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（次回も似たような案件なら良いですね）

てな感じであんまりメリットが見いだせないんですがなんかメリットを教えて欲しいです。

802 ：デフォルトの名無しさん：04/09/07 23:58

>>800
設計フェーズまで戻ってやるならよし。
コードちょこっといじってにやにやしてる奴はヲタ。

803 ：デフォルトの名無しさん：04/09/08 00:02

>>801
リファクタリング
＝自社の基盤フレームワーク・共通部品を既存のコードから抽出するといった
　戦略的な目的をもってトップダウンで行うもの

804 ：デフォルトの名無しさん：04/09/08 00:07

>>803
ああ、なんだ。フレームワーク作ったりライブラリ作ったりすることか。
普通にやってるじゃん。次のプロジェクトの時に。

805 ：デフォルトの名無しさん：04/09/08 00:10

>>800
このスレはもとからきとーな趣旨だし>>1。
ところでGOFパターンはそもそも開発プロセスとは断絶してる、という基礎知識はOKですか。
再分析というのがマニュファクチュアなことを言ってるなら、
スレ的にNoGood!! してもいいかどうかは状況次第ということになるのでは。

806 ：デフォルトの名無しさん：04/09/08 00:12

>>803-804
なんで気が合ってるんだおまえらー

807 ：デフォルトの名無しさん：04/09/08 00:13

青臭くていいから、学生や学究の住人だけで、なにか一つ取り上げてみたいな。
オレも趣味グラマだし、会社でどうとかあまり興味ないんで。
趣味で組んでるソースの見通しを良くし、分かりやすくしたいだけなんだよね。

別スレがいいかな？

808 ：デフォルトの名無しさん：04/09/08 00:20

時期は悪いがここしかないだろｗ
業務ネタはさんざん同じ内容でループしてるから、なんかもう慣れてきたぞ。

809 ：デフォルトの名無しさん：04/09/08 00:21

>>807
自分なりにフレームワークを作ればいいよ。
自分の趣味のプログラムって結構パターンが決まってくるから。

できないとかほざく奴は自分の抽象化能力に疑問を持った方がよい。

810 ：デフォルトの名無しさん：04/09/08 00:25

>>804
単純に前のプロジェクトから、引っこ抜いてくるだけだろ。

シンプルに、使いやすく、拡張しやすく作り変えないと駄目。本当はね。
だが通常、そんな事やっている暇はない（泣

前のプロジェクトやっている時は、
次に再利用するなんて、全然知らずに作っちまったコード達が
お嫁に行く恐怖。そんなコードを知らずに貰っちまった恐怖を体験せよ！！！

811 ：デフォルトの名無しさん：04/09/08 00:39

で、Bridgeパターンは、Templeteパターンより偉いのか？

812 ：デフォルトの名無しさん：04/09/08 00:42

>>808-809
うーん、やっぱり別スレの方が良さそうな気がする。
テスト終わったら資料と題材揃えて立ててみるよ、すぐ落ちるかもしれないけど。
その前に誰かやるならそれでも良いし。

813 ：デフォルトの名無しさん：04/09/08 03:06

もう充分みんな分かってると思うけどさ、Java厨(=デザパタ厨)ってのは、
自己満足と妄想だけで生きてる、社会不適合者の基地外なんだよ。
（無職引き籠もり）

814 ：デフォルトの名無しさん：04/09/08 06:09

午前３時に無職引きこもりと言われても説得力が無い。

782辺りが説得力の有る結論じゃないかと思う。

815 ：デフォルトの名無しさん：04/09/08 07:14

>Java厨(=デザパタ厨)

Java廚ってのはもともと、Javaしかできないうえにそのソースがひでぇ奴らの事だったハズだが
いつから「オブジェクト指向全般できちんと設計する人」を指すようになったんだ？

最近、自分が理解できないモノを必死で否定するヤシ大杉

816 ：デフォルトの名無しさん：04/09/08 07:55

というかjava厨は放置しろ
また粘着し出すじゃねーか

817 ：デフォルトの名無しさん：04/09/08 07:57

>ハズだが

誰が決めましたか？
厨はみんな厨だし、無根拠に～（デザパタ）原理主義な発言ばかりしてるアホも厨に相違ないですね。

>きちんと設計する人

自分はそうであると思い込みたいのですね。

818 ：デフォルトの名無しさん：04/09/08 09:08

>>801
そもそも少しデザパタとは少し違うんだけど
>出荷後のシステム->気に入らん所変更->バグあり糞システム（何に使うんですか？）
>　　　　　　　　　　　　　　　　|
>　　　　　　　　　　　　　　　　->出荷物と同程度の試験->出荷する予定のない改変されたシステム
>　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（次回も似たような案件なら良いですね）

リファクタの話でてるから漏れのわかってる範囲でＸＰも考慮にいれて考えると、
（間違ってたり足らんとこは適時喪前ら様達で保管してくれ）
>出荷する予定のない改変されたシステム
元々使いもせんような機能いれんだろ。
つーかある時点でおかしい。
使うか使わないかわからん機能入れるための変更なんてリファクタでもなんでもないと思うぞ。
逆にそー言うのを剥ぎ取ってスリム化して保守しやすくするための物がリファクタ（の一部）だと思うが。
>バグあり糞システム
バグを見つけ出し、撲滅するためにテストするんだろ。
で、テストに工数掛けられないからユニットテスト等の自動化ツールがあるんでは？
書き捨てでテストもしないシステムなんてリファクタでもなんでもないと思う。
単にシステム壊してるだけでは？
リファクタはテストを行うことが大前提でやる物だと漏れはおもってるが。
でないと変更後の正当性保障できないからね。

他の目的には803さんの言うのもあるが。

819 ：デフォルトの名無しさん：04/09/08 09:12

どこに機能追加なんて書いてある

820 ：在日参政権反対：04/09/08 09:14

知性のないやり取りは見るに耐えない．．．

821 ：デフォルトの名無しさん：04/09/08 19:01

結城本と日立本では、Factory Methodが別物だけど
どっちが正しいの？

822 ：デフォルトの名無しさん：04/09/08 19:34

>>820
今時右翼？

823 ：デフォルトの名無しさん：04/09/08 19:35

>>821
その本を両方とも持ってる奴は居るのかなあ？

824 ：デフォルトの名無しさん：04/09/08 19:45

>>823
呼んだ？

825 ：デフォルトの名無しさん：04/09/08 19:45

>>823
日立はネットでもある程度公開してるので、結城本もってるなら比較できるはず。
たしかに>>821の言うとおり使い方が違うね。

結城本はTemplate Methodの応用といった感じで書かれてる。
日立は↓
http://www.dmz.hitachi-sk.co.jp/Java/Tech/pattern/gof/factory_method.html

826 ：デフォルトの名無しさん：04/09/08 20:01

>>825
結城・・・専用のFactoryクラス＋その上に抽象クラス
日立・・・あるクラスに、他のクラスのコンストラクタをくっ付けるだけ

結城本は、小難しくしすぎか？

827 ：デフォルトの名無しさん：04/09/08 20:30

結城本を読むのに必要な基礎知識は
o Javaの文法
o UML
です。
先にUMLを覚えておかないとオブジェクト指向関連の本は読み難いですよ。

# ひさびさにUML技術者認定試験について調べてたら、
# オージス総研からUMLモデリング推進協議会ってところに移っていたみたいです。
# いま初めて気づきました…
# 面白半分にブロンズとってみたけど。。

828 ：デフォルトの名無しさん：04/09/08 20:57

結城本は、フレームワークの説明をしたかっただけなんじゃ？
Factory Method大迷惑

829 ：デフォルトの名無しさん：04/09/08 21:19

両本の第一小見出しにパターンの利用目的が書かれているが、GOF本は短く的確に
書かれているのに対して、結城本は簡単に説明しようと試みるも、逆に抽象的で
意味がとらえ難く、冗長になっている感がある。初心者にとっては理解しやすい
かもしれないが、ある程度の経験者になるとぱっと見て理解し難いだろう。

GOF本は、
目的、動機、適用可能性、構造、構成要素、協調関係、結果、実装、サンプルコード、使用例、関連するパターン
と、全てのパターンについて一貫した項目構成になっており、それぞれのパターン
を比較しやすく、辞書引きも便利になっている。
結城本はパターンの紹介を一項目で行い、いきなりサンプルプログラムを出してい
るが、抽象的で冗長な紹介文をいちいち読まねばどんなパターンかというのが解か
らない。

830 ：デフォルトの名無しさん：04/09/08 21:20

GOF本でいうところの、
動機、適用可能性
の部分が結城本での、
あなたが考えを広げるためのヒント
の一項目にあたり、この部分は初めの方にあった方が、これからどんなパターン
を使うのかということを把握しやすい。

関連パターンの紹介は結城本の方がリンクを明確にしている分わかりやすい。

サンプルコードは、GOF本は古いせいもあってC++、結城本はJavaになっているが、
実際にまともな作品としてプログラムを組む場合はC++が大半だと思うので、
GOF本のサンプルのほうが参考になるという人も多いだろう。
ただ、結城本のコードはより具体的に"動くもの"として掲載されているので実際に
動かして確認できる分、初心者にとってやさしいと言えるだろう。

あと比較するとしたら、
結城本は左上の欄外にパターンの名称が書いてあるから調べやすい。
GOF本の欄外には書いてない。

くらいかなぁ…

831 ：デフォルトの名無しさん：04/09/08 21:25

>>821-
おいおい、このスレにはGoF本を読んだことのない香具師しかおらんのか?

GoF本に載っているFactory Methodパターンに忠実なのは結城本のほうだ。

832 ：デフォルトの名無しさん：04/09/08 21:28

>>831
忠実とか言ってるお前はGoFの序章読み返せ。

833 ：デフォルトの名無しさん：04/09/08 21:33

>>831
Java厨きたー

834 ：デフォルトの名無しさん：04/09/08 22:14

むっ、GoFってやっぱり、読んだ方がよさそうですね。
１ページ、1ページのボリュームが凄まじかった、
読むの辛そうなので敬遠してたけど今度読んでみよう。

835 ：834：04/09/08 22:15

s/凄まじかった/凄まじかったから/

836 ：デフォルトの名無しさん：04/09/08 22:15

>>834
序章がすべての肝と言っても過言ではない。三回は読むように。

837 ：834：04/09/08 22:18

>>836
あれ？序章が肝なの？
立ち読みしてたとき、序章飛ばして、
いきなり個々のパターンのページに飛ばそうかと思っちゃったんですけど。

４回は読みます。

838 ：デフォルトの名無しさん：04/09/08 22:22

>>837
お前が一流のエンジニアになるか一流のヲタになるかの分かれ目がそこだ。

839 ：デフォルトの名無しさん：04/09/08 22:29

GOFもデザパタも読みやすい、分かりやすい。結城氏などの入門書を飛ばしてもいいと思う。
プログラムの達人＝解説の達人は成り立たたないから昔は読みにくいものばかりだったのに
良い時代になったものだ。

840 ：デフォルトの名無しさん：04/09/08 22:45

またしてもどの本がどうたら
と
か
いう話かｗｗ

841 ：デフォルトの名無しさん：04/09/08 22:52

デザパタ至上主義もどうかと思っていたので
昨日のアンチの話には興味が有ったんだがとんだ肩透かしであった。

842 ：デフォルトの名無しさん：04/09/08 23:05

GOF本・・・正座をして読む
結城本・・・あぐらをかいて読む
日立本・・・ごろ寝して読む

843 ：デフォルトの名無しさん：04/09/08 23:09

>>842
それプラス全裸が基本スタイルだよな

844 ：デフォルトの名無しさん：04/09/08 23:15

GOF本・・・バイブで
結城本・・・本に挟んで
日立本・・・手で

845 ：デフォルトの名無しさん：04/09/09 00:08

世の中に必要ない人が、ずいぶん頑張ってるスレですね(w

846 ：デフォルトの名無しさん：04/09/09 00:10

>>845
自己紹介
http://etc3.2ch.net/intro

847 ：デフォルトの名無しさん：04/09/09 00:41

BuilderパターンとCommandパターンって、やっている事は同じですか？

848 ：デフォルトの名無しさん：04/09/10 16:34:17

やっている事は同じですね

849 ：デフォルトの名無しさん：04/09/10 17:16:20

委譲使っている奴は皆似ているなー。
Bridgeとか・・・

850 ：デフォルトの名無しさん：04/09/10 23:17:52

デザパタにあてはめていくと小さいクラスがたくさん出来てしまうんですがこれでいいですか？

851 ：デフォルトの名無しさん：04/09/10 23:19:25

>>850
そこでlight weightですよ。

852 ：デフォルトの名無しさん：04/09/10 23:42:46

>>850
OO ってそういうもんだよ。小さいクラスになってるからこそ、変更に強いわけで。

853 ：デフォルトの名無しさん：04/09/10 23:43:54

「小さいクラス」じゃなくて「たくさん」を問題視してるんだろ。

854 ：デフォルトの名無しさん：04/09/11 00:03:57

具体例がないと、ちょっと分からんなぁ。

855 ：デフォルトの名無しさん：04/09/11 00:05:34

>>854
そんなバカな自分を形成している父の精子と母の卵子を恨め。

856 ：デフォルトの名無しさん：04/09/11 00:06:56

>>855
じゃ、回答よろしく。

857 ：在日参政権反対：04/09/11 01:05:31

＞850
人間の体考えれば分かるだろ．
クラス細分化結構!!

858 ：デフォルトの名無しさん：04/09/11 01:08:34

2000行越えたらout

859 ：デフォルトの名無しさん：04/09/11 01:12:49

一つのメソッドを理解するのに30秒以上かかったらout
そのメソッドは分割されるべき。

860 ：デフォルトの名無しさん：04/09/11 06:24:39

長いメソッドを分割する話にすり替えるなよ。
短いメソッドが大量に発生する話だろ。

861 ：デフォルトの名無しさん：04/09/11 06:25:48

過ぎたるは及ばざるがごとし

862 ：デフォルトの名無しさん：04/09/11 08:29:40

>>857
人間の体とクラスに何の関係があるんだ？

863 ：デフォルトの名無しさん：04/09/11 13:08:29

>>862
たとえば人間の体がたった一つのクラスで構成されてたら、ちょっとした
爪先を怪我しただけで最悪体丸ごと総とっかえなわけです。
しかし細分化しておけば爪クラスを補修してあげればいいわけです。

このメタファでわかるといいんだけど。

>>859
>>860
>>861
オブジェクト指向ってのは人間の理解のためのものなので、クラス設計
もメソッドの行数もメソッド数も人間の可読性が基準になると思う。
だから理解に30秒以上かかるメソッドは当然処置対象だと思うし、
短いメソッド乱発ってことはクラス分割されるところがあるはずだと疑う
のが普通。

そういう点からすると
>過ぎたるは及ばざるがごとし
ってのは今までの失敗経験から痛いほどわかるわけで。orz
そういうのの指針にするためにもデザパタって必要だと思うんだけどな。

864 ：デフォルトの名無しさん：04/09/11 14:45:01

＞たとえば人間の体がたった一つのクラスで構成されてたら

大げさすぎる例ｗｗ

865 ：デフォルトの名無しさん：04/09/11 15:25:18

規模によるじゃないの。
デカイ時にチョッコウ性を上げすぎると後々面倒。

866 ：デフォルトの名無しさん：04/09/11 15:30:20

＞爪先を怪我しただけで最悪体丸ごと総とっかえなわけです。
つめ先だけ直して再コンパイルすりゃええじゃないの。何が困るわけ？
って話になっちゃうんじゃないかね？

867 ：在日参政権反対：04/09/11 16:10:38

いいたかったのは人間というシステムもいろんな臓器や、循環系、神経系、免疫系などのシステムが有機的に結合して出来ているし、それらもさらに細かい部品から成り立っているということだったんだが．．．
全部同じ細胞クラスから派生してたりね．

868 ：デフォルトの名無しさん：04/09/11 16:14:47

相互に依存しまくりでちょっといじったら生命を維持できなくなるぞ。

869 ：デフォルトの名無しさん：04/09/11 18:06:30

脳味噌を入れ代えるときはStrategyパターンでいいのですか？

870 ：デフォルトの名無しさん：04/09/11 18:34:25

>>869
いいかもしんない

871 ：デフォルトの名無しさん：04/09/12 17:28:04

>>863
障害の局所化の話をしたいのか？
冗長な説明だね，というか焦点がボケるなあ，その喩えだと。
DNAの一元性の問題や遺伝子発現等の別領域のテーマと干渉する喩えだね。
敢えて突っ込まないが．．．

872 ：デフォルトの名無しさん：04/09/12 21:14:43

>>859
1つのメソッドが理解しやすくなっても
メソッドが多くなりすぎて1つのクラスとして理解しにくくなると思う。

873 ：デフォルトの名無しさん：04/09/12 21:17:42

>>872
そう思う。
だからあまり多くなり過ぎたらクラスを分割する。

874 ：デフォルトの名無しさん：04/09/13 01:03:28

おれはあほなので30秒ではほとんど理解できません。

875 ：デフォルトの名無しさん：04/09/13 23:13:06

>>871
何て言うかカップが付いてるのを知らずにひたすらカップの上からアイスクリームをなめているような、そんなしゃべりですね。

876 ：デフォルトの名無しさん：04/09/13 23:13:40

>>873
さらに増やすのか。

877 ：在日参政権反対：04/09/13 23:28:20

＞８７３
（・ω・）人（・ω・）　ナカーマ

878 ：デフォルトの名無しさん：04/09/13 23:34:09

どうしよう・・増えちゃったよ(>>877)

879 ：デフォルトの名無しさん：04/09/13 23:47:16

システム内できちんと位置を占めてて単純なものなら大クラス主義でかまわん。

880 ：デフォルトの名無しさん：04/09/14 00:23:54

>>877
（・ω・）人（・ω・）人（・ω・）モレーモイレテーヨ

881 ：デフォルトの名無しさん：04/09/14 00:40:48

>システム内できちんと位置を占めてて単純なもの
それはすでに大クラス主義とは言わないのでは？

882 ：デフォルトの名無しさん：04/09/14 01:19:21

長くなったら短くすればいいとか
多くなったらクラスを増やせばいいとか
本だけ読んでいい気になってるリア厨ですか？
短いメソッドが大量発生しても１つのメソッドは理解しやすいし
クラスを増やせば全部オッケーですかあーそーデスか
最適な粒度ってのは行数やメソッドの数じゃないんだよ
死ぬまでJavaでもやっててください

883 ：デフォルトの名無しさん：04/09/14 01:33:17

また痛い香具師が一匹湧いたな・・・・

884 ：デフォルトの名無しさん：04/09/14 01:47:42

アホのせいで頭痛が痛くなってきた

885 ：在日参政権反対：04/09/14 03:04:59

マジレスすると自分はクラス細分化されてるの好きだし、メソッドどんどん作る主義。
そのほうが見やすい。そこらへんは個人差でないの？

886 ：デフォルトの名無しさん：04/09/14 06:51:02

知ってますか？ここ俺栞の中で最低スレですよ？

887 ：デフォルトの名無しさん：04/09/14 07:26:18

>>886
だから？

888 ：デフォルトの名無しさん：04/09/14 08:32:02

素朴な疑問
やっぱこのスレってJava厨多いの？

889 ：デフォルトの名無しさん：04/09/14 08:40:27

一番無意味で非生産的な質問の形態として「だから？」の一言レスというのがありますね。

890 ：デフォルトの名無しさん：04/09/14 08:50:22

>>889
あっさり釣られてやがんの（ﾌﾟ

891 ：デフォルトの名無しさん：04/09/14 08:52:05

あーあ、最後に「釣り」って言っちゃった。わかりやすい負け犬宣言だなぁ。

892 ：デフォルトの名無しさん：04/09/14 09:06:12

>>891
負け犬はそっちだろヴォケ。氏ね

893 ：デフォルトの名無しさん：04/09/14 09:07:29

朝から香り高い香具師が２人ほどいますね。

894 ：デフォルトの名無しさん：04/09/14 09:08:51

晒しage

895 ：デフォルトの名無しさん：04/09/14 09:11:41

>>890=負け犬

896 ：デフォルトの名無しさん：04/09/14 09:12:09

>>890=負け犬

897 ：デフォルトの名無しさん：04/09/14 09:16:32

>>895 >>896
焦って二重カキコですか（禿藁
貴方の怒りで震える右手の人差し指が目に浮かびますよ（ﾌﾟ

898 ：デフォルトの名無しさん：04/09/14 09:17:55

>>890=負け犬

899 ：デフォルトの名無しさん：04/09/14 09:21:30

怒りの余り脳の論理回路が停止して短い単語しか繰り返せなくなったか。
池沼だな。

900 ：デフォルトの名無しさん：04/09/14 09:21:58

>>890=負け犬

901 ：デフォルトの名無しさん：04/09/14 09:31:41

>>899
で、釣られているのが自分だという罠w
別人に怒ってやんのw

902 ：デフォルトの名無しさん：04/09/14 09:37:03

>>901
プッ。見え透いた嘘を。IP全部同じじゃん。馬鹿ですか？

903 ：デフォルトの名無しさん：04/09/14 09:38:31

>>902
見え透いた嘘はそっちだろw

904 ：デフォルトの名無しさん：04/09/14 09:40:21

>>903
削除人はホスト名をいつでも自由に閲覧できる事をお忘れなく（ｗ

905 ：デフォルトの名無しさん：04/09/14 09:42:46

>>904
初心者ですか？

906 ：デフォルトの名無しさん：04/09/14 10:43:40

>>890=負け犬

907 ：デフォルトの名無しさん：04/09/14 10:56:02

　 | 　 |　　|　|　　 |　　 |　　| ｜　 |　　 | 　 |｜　|　|
　 | 　 |　　|　ﾚ　　|　　 |　　| ｜　 |　　J 　 |｜　|　|
　 | 　 |　　| 　　 J　　 |　　| ｜　　し　　　 |｜　|　|
　 | 　ﾚ　｜　　　　　　｜　ﾚ｜　　　　　　　|｜Ｊ　|
　J 　　　し　　　　 | 　　 |　　　　　　　｜|　　 J
　　　　　　　　　　　　　｜　　し　　　　 J｜
　　　　　　　　　　　　　Ｊ　　　　　　　　　ﾚ
　　　　　／V＼
　　　　/◎;;;,;,,,,ヽ
　＿　ﾑ::::(l|lﾟДﾟ)|　バカじゃねーか…　こんなに釣り糸垂らしやがって…
ヽﾂ.（ﾉ::::::::::.:::::.:..|）　それで俺たちが釣れると思ってたら大間違いだ…
　ヾソ:::::::::::::::::.:ﾉ　　どこか別の釣堀り逝ってこい！
　　｀ー U'"U'

908 ：在日参政権反対：04/09/14 12:08:11

たまにすれ伸びたかと思ったら全部釣り針ですか．．．

909 ：デフォルトの名無しさん：04/09/14 12:18:37

↓という事でデザパタの話をどうぞ

910 ：デフォルトの名無しさん：04/09/14 13:28:43

クラス設計とデザパタの区別が付いてない奴が多くないか？

911 ：在日参政権反対：04/09/14 13:32:07

＞910
の言う区別とは？

912 ：デフォルトの名無しさん：04/09/14 14:24:29

↓という事で24個目のパターンをどうぞ

913 ：デフォルトの名無しさん：04/09/14 15:45:36

フィッシングパターン

914 ：デフォルトの名無しさん：04/09/14 16:59:24

そもそも小さなたくさんのクラスにわけろっていう教えを
説いたのはケント・ベックだからなあ

異議のある人は御大に直接意見してほしいものだ

915 ：デフォルトの名無しさん：04/09/14 17:02:35

権威に盲従パターン

916 ：デフォルトの名無しさん：04/09/14 17:42:58

>>915
社民党パターン(先ず反対を唱えておく)

917 ：デフォルトの名無しさん：04/09/14 18:13:42

>>916
内容より名前で勝負パターン

918 ：デフォルトの名無しさん：04/09/14 18:51:07

>>917
名前がそのまんまパターン（ってこれもだ）

919 ：デフォルトの名無しさん：04/09/14 19:01:13

ていうか、
「"大きなクラスを小さなクラスに分けるパターン" はあるが、
"小さなクラスを大きなクラスに纏めるパターン" 等というものは無い」
という事実が、全てを語っていると思うのだが・・・

920 ：デフォルトの名無しさん：04/09/14 19:11:01

>>919
リファクタリングの話ではあるけど、一応
「メソッドのインライン化」や「クラスのインライン化」というのがあるので、
無いというのは正確ではないかと。

921 ：デフォルトの名無しさん：04/09/14 21:18:26

>>919
パッケージ化して公開インターフェイスだけを使わせたらいいのだよ。

922 ：デフォルトの名無しさん：04/09/14 21:19:08

俺の考えたデザインパターンを見てくれってやつはおらんのか。
ＧｏＦの時代から進歩ねえなあ。

923 ：デフォルトの名無しさん：04/09/14 22:06:41

まぁ基本だがGoF以外のパターンもあるわけで、
そうそう新しいのは出てこないなぁ。
自分で新しいのを広められたらうれしいけどねぇ。

http://c2.com/cgi/wiki?PortlandPatternRepository

924 ：デフォルトの名無しさん：04/09/14 22:23:02

大抵GoFのパターンを元にしていろいろカスタマイズして使えるからねぇ。
カスタマイズしたやつが新しいパターンと言えなくもないが。。

925 ：デフォルトの名無しさん：04/09/14 22:28:55

>>924
GoFの序章を23回書き写せ。

926 ：デフォルトの名無しさん：04/09/14 22:36:20

>>925
たぶん私が言いたいことが君には伝わってない。
面倒だから言い直さないけど。

927 ：デフォルトの名無しさん：04/09/14 22:46:42

>>926
テレパシーでも覚えれば？

928 ：デフォルトの名無しさん：04/09/14 22:47:48

>>927
それよりも電波受信してもらう方が簡単だよ

929 ：デフォルトの名無しさん：04/09/14 23:44:37

Comositeパターンで謎なのは、Compositeクラスだけでなく、なぜか、Componentクラスにも
AddChildやRemoveがあること。
なんで？

930 ：在日参政権反対：04/09/14 23:54:26

止めて－スレを汚さないデー

931 ：デフォルトの名無しさん：04/09/14 23:57:47

ダウンキャストしなくても良いように。
でもそれがCompositeパターンと言うわけではなく、
ダウンキャストを前提とした実装のパターンもある。

932 ：デフォルトの名無しさん：04/09/15 07:56:05

java5ではダウンキャストもコンパイルエラーではじいてくれる？

933 ：デフォルトの名無しさん：04/09/15 14:10:52

だれか「クラスの粒度」について真面目に語ってみてくれないか

934 ：デフォルトの名無しさん：04/09/15 17:25:40

前にも書いたが

システムの一部分をごっそり他のシステムへ転用する時
本当に必要な部分だけ、取り出す事が出来れば、
その「クラスの粒度」は正しい

935 ：デフォルトの名無しさん：04/09/15 19:12:47

>>934
粒度が過度に細かい場合も必要な部分だけ取り出せない？

936 ：デフォルトの名無しさん：04/09/15 20:09:06

>>935
あまり快適じゃないけどね。
ドキュメント見て、あ、これも追加か・・・とか。

「ストレスなしに」を付け加えた方が良いのかな>>934

937 ：デフォルトの名無しさん：04/09/15 20:37:21

そこで Facade パターンですよ

……隠した先のクラスがどれか分からないと取り出せないか(´･ω･`)
ライブラリそのものを丸ごと引っ越すならともかく

938 ：デフォルトの名無しさん：04/09/15 23:21:42

>>933
コレがお手本だ！なんてオープンソースのコードはないかねえ。javaで。

939 ：デフォルトの名無しさん：04/09/15 23:47:13

>>938
java 自身は？

940 ：デフォルトの名無しさん：04/09/16 21:54:28

フィッシングパターン
内部のフックをファサードで隠蔽しながらエサを偽装するパターン

941 ：デフォルトの名無しさん：04/09/16 21:56:41

>>875
俺の発言にレス付いてるじゃん，驚いた。
でも，内容が無いよう．．．

942 ：デフォルトの名無しさん：04/09/16 23:54:42

Javaのライブラリは、デザパタ悪用糞ライブラリの代表。

943 ：デフォルトの名無しさん：04/09/17 00:42:48

使いこなせないからひがんでるんですね（￣ー￣

944 ：デフォルトの名無しさん：04/09/17 01:09:11

てかJavaライブラリマンセーの方が変じゃねーか？

945 ：デフォルトの名無しさん：04/09/17 01:25:36

何かを悪いと指摘する場合は、
良い例を示さないと説得力無いねぇ。
そして、この板常駐の忍者ハッタリくんが、
例を示して人を納得させる技量が無い事は、
皆が知っている

946 ：デフォルトの名無しさん：04/09/17 01:36:08

>>942 >>944
そうかね？
結構、よい設計だと思うんだが。
基本部分のjava.ioとかjava.langあたりは。

しかし、何でage?

947 ：デフォルトの名無しさん：04/09/17 03:16:39

java.ioのストリームクラスとかReader/Writerとか使いにくいよー。
もっとパッと組みたいんだよ、パッと。

948 ：デフォルトの名無しさん：04/09/17 03:57:52

>>947
RPGつくーるでも使ってなさい

949 ：デフォルトの名無しさん：04/09/17 08:36:09

これだからJAVA厨は・・・

950 ：次スレ案内：04/09/17 11:37:33

【GoF】デザインパターン 3
http://pc5.2ch.net/test/read.cgi/tech/1095388499/l50

951 ：デフォルトの名無しさん：04/09/17 12:24:00

java.ioはデコレータパターンの成功例だと思うんだけどな。

952 ：デフォルトの名無しさん：04/09/17 13:32:43

デザパタ嫁とか
デザパタに書いてあるとか
デザパタに従ってるから成功だとか
教典を盲信する新興宗教の信者ですか？

953 ：デフォルトの名無しさん：04/09/17 14:51:57

>>952
その通り。
危険だから君はこのスレに近寄らない方がいいよ。

954 ：デフォルトの名無しさん：04/09/17 15:26:33

ツールはあくまで使うもの。
それに使われ始めたら厨の始まり。

得意になって、覚えたてのデザパタを使う為にがんばっちゃうような奴ばっかだよな、このスレ。
で、知識をひけらかしたがる。

955 ：デフォルトの名無しさん：04/09/17 16:10:28

>>954
禿同
デザパタなんぞ、所詮枠や雛形に過ぎない。
どーやってデザパタと同形にするかとかより、
デザパタをどー取り込んで使うかが大事だと思う。
取り込んだ結果が使おうとしてたデザパタと違っても
所詮雛形なんだから変わるのは全然問題なし。
（跡形もなくなるとソレはそれで別の問題があるだろうが。）

956 ：デフォルトの名無しさん：04/09/17 16:18:32

長々とテンプレどおりの一般論をご苦労様。

957 ：デフォルトの名無しさん：04/09/17 20:39:20

新しく出てた亜蛇射る開発本(≠Agileシリーズ)も、
デザパタをネタに各章が構成されてたっけ。
デザパタはえいえんにふめつです！
あと、POSAとPLoP本もよろすくねｗ

958 ：デフォルトの名無しさん：04/09/18 00:05:13

>>957
ｷﾁｶﾞｲ?

959 ：↑（´∀｀）ｽｸﾞｺﾚﾀﾞ：04/09/18 00:14:43

960 ：デフォルトの名無しさん：04/09/18 01:01:05

>>959
ﾎﾝﾆｿ?

961 ：デフォルトの名無しさん：04/09/18 01:37:45

以上、アンチがｷｰｷｰわめくだけの猿スレでした。
次スレは皆の心の中に…

962 ：デフォルトの名無しさん：04/09/18 01:41:04

Aransk?

963 ：デフォルトの名無しさん：04/09/18 03:39:50

>>961
いやほんとだな
アンチは何しにわざわざこのスレ来てるんだ…

信者の集団と言われても良いから、前向きにデザパタを語るスレが欲しいよ
「デザインパターン信者の集い」スレとか、立てていい？

964 ：デフォルトの名無しさん：04/09/18 07:30:20

>>963
お前のBBSにしてくれ。

965 ：デフォルトの名無しさん：04/09/18 08:29:58

てかJava厨消えてくれ

966 ：デフォルトの名無しさん：04/09/18 11:33:36

↑その猿

967 ：在日参政権反対：04/09/18 12:32:35

アンチはなー．．．
今プログラムするとしたらデザパタの要素は必ず入ってるだろうに．．．

968 ：デフォルトの名無しさん：04/09/18 12:39:21

アンチってその可哀相な人生をいつまで続けるの？
さっさと市ねよ

969 ：デフォルトの名無しさん：04/09/18 12:41:27

アンチデザパタじゃなくて
アンチJAVA厨ね
かってにすり替えるなよJAVA厨

970 ：デフォルトの名無しさん：04/09/18 12:45:27

口の減らない基地外だなぁ～

971 ：デフォルトの名無しさん：04/09/18 13:40:39

>>969
C++ですが、なにか？
構文が似通ってると同じに見えるんですか？

972 ：デフォルトの名無しさん：04/09/18 13:51:46

>>969
こういう馬鹿って、なんで生きてるんだろうなぁ。
劣等感丸出しで恥ずかしい奴だｗ

973 ：デフォルトの名無しさん：04/09/18 14:48:13

Java厨じゃないから特に腹も立たないな

974 ：デフォルトの名無しさん：04/09/18 14:53:18

俺はJava使ったこともねえけども、
デザインパターンの話をしようとすると必然的にJavaの話にならないか？
Javaもそこまでうまく利用できているわけではないけど、
ほかにまともにデザインパターン利用できてる言語ってないし。

975 ：デフォルトの名無しさん：04/09/18 14:57:00

>>954
こんなスレ、まさに知識をひけらかすためのスレじゃねえの？
で、俺みたいな理解してない馬鹿がその恩恵を授かると。

976 ：デフォルトの名無しさん：04/09/18 15:02:47

>>974ほかにまともにデザインパターン利用できてる言語ってないし。
ほう、っていうか、「利用できてる」言語って何だ？

977 ：デフォルトの名無しさん：04/09/18 15:10:26

やっぱJava厨には消えて欲しいでFA

978 ：デフォルトの名無しさん：04/09/18 15:18:33

Smalltalk以外はマムコ

979 ：デフォルトの名無しさん：04/09/18 15:22:56

デザインパターンは言語で利用するものなのか？
俺の感覚だと
『上手な設計』⇒『よし、デザパタとして憶えておこう』⇒<別の案件>⇒『ここにはあのパターンが使える』
だから
＞デザインパターン利用できてる言語ってないし。
って言い方が違うと思うぞ？

最初設計した際に使用した言語と別の案件で使用する言語の違いは設計にもろに出るから
Java 以外にデザパタってあまり見ないのはこの違いのせいだと思ってるが……

980 ：974：04/09/18 15:23:59

>>976
漏れの日本語に対する指摘か？
んじゃ、　「利用できてる」　⇒　「活用できている」　かな。

981 ：979：04/09/18 15:29:16

>>980
あ、俺の感覚を書いただけだから、違うと思ったら別にそれでもいいんスけどね
指摘なんてレベルには達していないです

＞「活用できている」
おｋかと

982 ：974：04/09/18 15:30:05

>>979
>デザインパターンは言語で利用するものなのか？
おお、そういう意味ね。確かに勘違いするかも。
漏れのいいたかったことは
「デザインパターンという概念はjavaでしか使えない」と言いたいのではなくて
「デザインパターンを適用してる言語は今のところjavaしかなさそう」と言いたかったんです。

あ、C#とかもVB.NETとかも使ってるのかな。

983 ：デフォルトの名無しさん：04/09/18 15:39:16

漏れもJava厨には消えて欲しいでFA

984 ：デフォルトの名無しさん：04/09/18 16:06:39

今日もループだねえ

985 ：デフォルトの名無しさん：04/09/18 16:53:17

>>982
Javaのクラスライブラリってことか？
Javaの言語仕様でデザパタ活用してるなんて思えないし。

.NETとかWxWidgetsとかもデザパタ使ってるとおもうんだけど
どしてJava「しか」ないの？

986 ：974：04/09/18 17:06:22

>>985
>Javaのクラスライブラリってことか？
そです。

>どしてJava「しか」ないの？
それは漏れが.NETを使ったことないからさ！ъ（ﾟｰ^）
正直スマンカッタ

987 ：976==910：04/09/18 17:17:19

で、いつもいつも思うんだけど、
デザパタって使用するものじゃなく、自然とそうなるものだろ？

既存のデザパタが使える部分が 100% って事はまず無いが、
沢山のライブラリを見て「これはひとつのパターンなんじゃないか？」ってのを
抜き出したのがデザパタなんだから、
自然とそうなったものを「ここはデザパタを使用しました」って単純に言うのは間違いだと思う

デザパタを使ったか使ってないかは、それこそ設計者に聞くしかない
外見がデザパタっぽくても

と思うんだけど間違ってる？
ちなみにこれが >>910 の説明

988 ：デフォルトの名無しさん：04/09/18 17:18:21

デザインパターンは囲碁の定石だよ。

989 ：976==910：04/09/18 17:29:25

>>988
だけど囲碁でも「ここはこのパターンで……」という様な思考は無いだろ？
「ここはこうすると……」なら大いにあるけど。

一番ありふれたパターンは、俺は Facade だと思う。
自分が書いたコード内で、Facade が無意識の内に使われていた事って、
結構あることだと思うんだけどなぁ……
それを『デザパタを使用しました』って胸を張って言うのは感覚的に間違っている気がする

たしかに「ここはこのパターンで……」と考えると、
自分が考えたものより良いものができる場合もあるけど。

990 ：976==910：04/09/18 17:30:05

>>988
とりあえず囲碁の定石だって事に異論は無いっスが

991 ：デフォルトの名無しさん：04/09/18 17:34:33

>>989
囲碁の定石には名前はないのかい?
となると、解説の人は大弱りだと思うんだが。

992 ：次スレ案内：04/09/18 17:39:19

【GoF】デザインパターン 3
http://pc5.2ch.net/test/read.cgi/tech/1095388499/l50

993 ：976==910：04/09/18 17:40:43

>>991
いや、名前の有る無しは別

自分が設計したものが、偶然あるパターンそっくりになっても、外部から見ればデザパタ使った風にしか見えないから、
それを考えると『デザパタを使用している』って単純に言うのは間違ってるんじゃないか、って言いたいだけ

『ここはこのパターンに似ている』なら大いに結構
単に日本語の問題かもしれない

自分でも言いたい事が良く分からなくなってきたorz

994 ：デフォルトの名無しさん：04/09/18 17:41:51

意識してよく使うのはCompositeで、
無意識のうちに使っているのはAdapterかなぁ。

995 ：デフォルトの名無しさん：04/09/18 17:46:21

>>993
一人きりで書く場合には別かもね

996 ：976==910：04/09/18 17:48:09

>>995
何か間違えた？俺

997 ：デフォルトの名無しさん：04/09/18 17:55:58

なんでこんな空しい議論をいつまでも続けるの？

次スレ必要なっし

998 ：デフォルトの名無しさん：04/09/18 17:58:58

998

999 ：デフォルトの名無しさん：04/09/18 18:04:46

　　　　　　／/
　　　　／　.人
　　　 / 　（＿_）ﾊﾟｶ
　　　/ ∩(＿___）　　　おいすー＾＾
　　 /　.|（・∀・）＿
　　/／ |　　　ヽ／
　　"￣￣￣"∪

1000 ：デフォルトの名無しさん：04/09/18 18:05:31

　　　　　　／/
　　　　／　.人
　　　 / 　（＿_）ﾊﾟｶ
　　　/ ∩(＿___）　　　あ、ぽこたんインしたお！
　　 /　.|（・∀・）＿
　　/／ |　　　ヽ／
　　"￣￣￣"∪

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。