1001コメント331KB

【GoF】デザインパターン 3

レス数が1000を超えています。これ以上書き込みはできません。

00011

NGNG

賢者は歴史に学び、愚者は自分の経験に学ぶ

関連情報は >>2-10

0002デフォルトの名無しさん

NGNG

過去スレ
デザインパターンの単純そうな質問 - (1)
http://pc5.2ch.net/test/read.cgi/tech/994836140/
【GOF】デザインパターン - (2)
http://pc5.2ch.net/test/read.cgi/tech/1087050664/

関連スレ
デザインパターン
http://piza.2ch.net/tech/kako/976/976074878.html
「デザインパターンって、○○のようなもんだよ」
http://piza.2ch.net/test/read.cgi?bbs=tech&key=994690114
リファクタリング、させてくれ
http://pc5.2ch.net/test/read.cgi/tech/1081863662/l50
【XP】Agile Process 第2イテレーション【UP】
http://pc5.2ch.net/test/read.cgi/tech/1091773629/l50
【綺麗】デザインパターンは美しい！【究極の美】＠プログラマー板
http://pc5.2ch.net/test/read.cgi/prog/1089077456/l50

0003デフォルトの名無しさん

NGNG

Web Page [ja]
デザインパターンあれこれ
http://www.dmz.hitachi-sk.co.jp/Java/Tech/pattern/
Javaプログラマのためのデザインパターン入門
http://objectclub.esm.co.jp/DPforJavaProgrammers/DPforJavaProgrammers.html
Javaなページ
http://home.catv.ne.jp/dd/chiba/ken/Java/JavaMain.html
デザインパターン入門 (ちとわかりずらい…)
http://www.netlaputa.ne.jp/~hijk/study/oo/designpattern.html
Inversion of Control コンテナと Dependency Injection パターン
http://www.kakutani.com/trans/fowler/injection.html
Inversion of Control
http://wiki.bmedianode.com/Spring/?Inversion+of+Control
Smalltalkイディオム(GoF本のサンプルコードが読めない人のためのSmalltalk入門)
http://www.sra.co.jp/people/aoki/SmalltalkIdioms/index.htm
[en]
Patterns Home Page
http://hillside.net/patterns/
Design pattern (computer science) - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

0004デフォルトの名無しさん

NGNG

書籍
増補改訂版Java言語で学ぶデザインパターン入門
http://www.hyuki.com/dp/index.html
Java言語で学ぶデザインパターン入門マルチスレッド編
http://www.hyuki.com/dp/dp2.html
独習デザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4798104450/
Javaデザインパターン徹底攻略標準プログラマーズライブラリ
http://www.amazon.co.jp/exec/obidos/ASIN/4774115797/
Javaの格言
http://www.amazon.co.jp/exec/obidos/ASIN/4894711877/
Javaの鉄則
http://www.amazon.co.jp/exec/obidos/ASIN/489471258X/
Effective Java
http://www.amazon.co.jp/exec/obidos/ASIN/4894714361/
オブジェクト指向における再利用のためのデザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4797311126/
リファクタリング
http://www.amazon.co.jp/exec/obidos/ASIN/4894712288/
アジャイルソフトウェア開発の奥義
http://www.amazon.co.jp/exec/obidos/ASIN/4797323361/

0005デフォルトの名無しさん

NGNG

書籍一つ加えておきます。
「Ｃ＃デザインパターン」
http://www.amazon.co.jp/exec/obidos/ASIN/4822281698/

0006デフォルトの名無しさん

NGNG

書籍
デザインパターンによるJava実践プログラミング
http://www.amazon.co.jp/exec/obidos/ASIN/4756141552/
Java実践プログラムによるデザインパターン入門講座
- Swingプログラムで体得する23のパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4894712563/
J2EEデザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4873111781/

0007デフォルトの名無しさん

NGNG

信者ｳｻﾞｲ

0008デフォルトの名無しさん

NGNG

デザパタ信者というよりJAVA厨の溜まり場なんだよ(だから低レベルで浮き世離れしてる)

0009ぱたんまんせ

NGNG

POSA本とPLoP本もよろしくね！！！

官話九大

IBMのe-Business patternsって、
アメリカ合衆国のEA決める官庁でもネタにされてるくらい、
認知率が高くて、国内でもITなんたら推進室が寝たの孫引きしてる。
まぁ、飴ちゃんは「ベストプラクティス！！！」とか好きだし、
国内の馬鹿役人は飴理科追従が仕事みたいなもんだし、ぷぷぷ

それを真似して .NET pattern & practice とかやってるM$は、なんか哀れ

0010デフォルトの名無しさん

NGNG

このスレの命題にも言えることだが
＞POSA本とPLoP本
無理やりこういう略しかたする必要あるのか？
頭悪すぎ

0011デフォルトの名無しさん

NGNG

＞官話九大
使い方が間違ってるからわざと違う漢字にしてるのですね。

0012デフォルトの名無しさん

NGNG

>>11
そのとおりですが、何か？

0013デフォルトの名無しさん

NGNG

何とも言ってませんが？

0014デフォルトの名無しさん

NGNG

>>9
すんません。まじで何のことを言っているのかさぱーりです。
わかるよーに説明希望

0015デフォルトの名無しさん

NGNG

>>14 かまわないほうが...

0016デフォルトの名無しさん

NGNG

痴呆老人がネガティブな粘着をしてるようだな

さっさと市ねよ

0017デフォルトの名無しさん

NGNG

関係ないが前スレの976は俺でその後何にも書いてないのに
話が進んでるのはなぜだ…？

0018デフォルトの名無しさん

NGNG

>>17
それは俺がレス番号の間違いに最後まで気づかなかったからだ
今気づいた
マジでｽﾏｿOTL

0019デフォルトの名無しさん

NGNG

＞マジでｽﾏｿOTL
あ、イヘイヘ、面白かっただけなんで。

0020デフォルトの名無しさん

NGNG

デザインパターンを使うと、メソッド1つだけのクラスやら
実質１つのクラスしか使っていないインターフェイスやらが
たくさん増えるんだがこれでいいのでしょうか？
クラスの数ばかりが増えてあまり意味が無いような気がしてしまいます。

0021デフォルトの名無しさん

NGNG

>>20 お前デザパタまったく理解出来てない。そういう対策もデザパタに書いてある。ちゃんとデザパタ読んで勉強し直せ。

0022デフォルトの名無しさん

NGNG

Ａ「ユダヤ人はどの民族よりも優れています。」
Ｂ「その根拠は？」
Ａ「ユダヤ教の教典にそう書かれています。」
Ｂ「・・・」

0023在日参政権反対

NGNG

＞20
デザパタ本に書かれてるかはわすれたが、
そのクラスの役割にメソッドの数は関係ないし、インターフェースの本質は役割の規定だが、たまたまその役割を受け継ぐクラスがひとつだけだったのであって、その役割の規定が正しいのなら問題ない

0024デフォルトの名無しさん

NGNG

>>21
そういうのはデザパタ本じゃなくてリファクタリング関係の本じゃないのか？

0025デフォルトの名無しさん

NGNG

厨房隔離ｽﾚｗｗｗ

0026デフォルトの名無しさん

NGNG

オブジェクト指向と同じで、厨がキモイな

デザインパターンやってみる
　↓
理解できない
　↓
やつ当たりで2chで暴れる

0027デフォルトの名無しさん

NGNG

>>26
それは無理がある。デザパタを理解しないうちに2chで暴れると、かえって
手負いの傷を負う。叩きのめされるからなｗ

0028デフォルトの名無しさん

NGNG

デザパタは勉強してるけど、
実際にコーディングで役に立つことは少ないかも・・・

decoratorパターンなんて、java.io以外で
有用な例を挙げられないのだから・・・

0029デフォルトの名無しさん

NGNG

そうですか。

0030在日参政権反対

NGNG

えぇぇぇ使いまくりですが．．．
そのままじゃないですけど

0031デフォルトの名無しさん

NGNG

技術板でコテハンやめろ、ウザくてむしろ賛成したくなってくる
いや、それが狙いか？

0032デフォルトの名無しさん

NGNG

同意、しかもつまらんレスばかりだし。

0033乾燥者

NGNG

コテハンにします。

0034デフォルトの名無しさん

NGNG

>>20
> メソッド1つだけのクラスやら実質１つのクラスしか使っていない
> インターフェイスやらがたくさん増えるんだがこれでいいのでしょうか？

ブロック／クロージャがない言語だとそうなってしまうのは仕方ないと思われ

0035デフォルトの名無しさん

NGNG

>>32
何を期待しているのかと。

0036デフォルトの名無しさん

NGNG

GoF の読み方は「ゴフ」

0037デフォルトの名無しさん

NGNG

乙一の本は「ゴス」

0038デフォルトの名無しさん

NGNG

classloaderもデコレータパターンに近い気がするけどどうだろ。

0039デフォルトの名無しさん

NGNG

>>21
おまえ普及させる気あるのかこのやろう。
新参者にはやさしく愛撫しながらスマイルで答えてさしあげろ

いや別に普及させる気ないならいいんだけど。

0040デフォルトの名無しさん

NGNG

>>38
振る舞いという意味ではChain of Responsibilityパターンのような気が。
どっちでもいいんだけどね。構造で分類するか振る舞いで分類するかの違いだけで。

0041デフォルトの名無しさん

NGNG

たんなる再帰呼び出しと違う？

0042デフォルトの名無しさん

NGNG

>>41
クラスやオブジェクトの構造に言及している点が違う。
再帰呼び出しといった場合、手続き内から同一手続きを呼び出すという
手続きの振る舞いを述べているだけだが、
DecoratorパターンやChain of Responsibilityパターンと言った場合、
クラスの静的構造（クラスローダが別のクラスローダへの参照を持っている、
全てのクラスローダはClassLoaderクラスのサブクラスである、など）についても
述べたことになる。
「オブジェクト指向で再帰呼び出しするなら普通そうするだろ」と思うかもしれないが、
DecoratorパターンやChain of Responsibilityパターンでない再帰呼び出しもあり得る
（メソッド引数に移譲先のオブジェクトを渡す場合）のでそうとも言えない。

0043デフォルトの名無しさん

NGNG

>>42
下らないことにもったい付けてるだけ

0044デフォルトの名無しさん

NGNG

ダメだよ、自分が不勉強だって認めなきゃ（ｸｽ

0045デフォルトの名無しさん

NGNG

>>44 あんたレベル低すぎだよ・・・

0046デフォルトの名無しさん

NGNG

ていどひくい

0047デフォルトの名無しさん

NGNG

会社で何かいやな事でもあったのかと。

0048デフォルトの名無しさん

NGNG

>>28
>decoratorパターンなんて、java.io以外で
>有用な例を挙げられないのだから・・・
デザパタで成果を挙げているのはライブラリやフレームワーク側だけで
フロントのアプリケーションでは使わない結論。

0049デフォルトの名無しさん

NGNG

Java厨は自分のアプリをすべてデザインパターン化しようと必死だぞ

0050デフォルトの名無しさん

NGNG

>>46
すぐにレベルが低いとかそういう事いうやつは
スネオ並って事ですね。

0051在日外国人参政権反対

NGNG

＞48
そこまでよく出来たフレームがあるとフロントは楽でいいですね

0052デフォルトの名無しさん

NGNG

Java厨曰く
せっかく覚えたデザパタに従ってないライブラリは全て糞

0053デフォルトの名無しさん

NGNG

デザインパターン通りかどうかが
判断基準の全てなんだよな
JAVA厨って
だから糞な物作って自己満足(以下自主規制

0054デフォルトの名無しさん

NGNG

以上、テンプレ終了

腐った餌は放置の方向で

0055在日外国人参政権反対

NGNG

せっかく新スレになったんだから、Java厨批判で無駄に汚すの止めてくれ

0056デフォルトの名無しさん

NGNG

てかJava厨消えてくれ

0057デフォルトの名無しさん

NGNG

コテハンも一緒に消えてくれ

0058デフォルトの名無しさん

NGNG

せめてデザパタの話をしれ

0059デフォルトの名無しさん

NGNG

>>48
そこでサクッと
フレームワークを
ageれば
みんな
納得するんだけど

0060sage

NGNG

Singleton パターンを用いるシーンが思いつきません。
クラス変数をプロパティとして持ち、そのアクセサ・メソッドを持つクラスで、
事足りるのでは？と思ったのですが、どうなのでしょうか？

インスタンスが一つだけという目的ならクラス変数を使用するようにすれば
良いのでは、と。

Java 厨と呼ばれても仕方が無い質問かもしれませんが、分かりやすく
教えていただければ助かります。

0061デフォルトの名無しさん

NGNG

＞Singleton パターンを用いるシーンが思いつきません。

無いから。

0062デフォルトの名無しさん

NGNG

俺は FlyWeight を兼ねて１つのクラスを Singleton にしたことがある
あまり意味のあることだとは思えなかったが、とりあえずやってみて結局意味無かった

0063デフォルトの名無しさん

NGNG

俺はログ出力用のクラスを Singleton にしたことがある
あまり意味のあることだとは思えなかったが、とりあえずやってみて結局意味無かった
今は反省している。

0064デフォルトの名無しさん

NGNG

ここでJava厨のデザパタ鵜呑み発言↓

0065在日外国人参政権反対

NGNG

サブシステムとしてグローバル的に使うものに多用してまふ
スレッドマネージャーとかそういう奴

0066デフォルトの名無しさん

NGNG

さすがJava厨のデザパタ鵜呑み発言↑

006763=66

NGNG

つーか、そろそろデザパタの話をしようぜ
もうこのスレじゃ無理っぽいけど。

0068在日外国人参政権反対

NGNG

＞66
ではそういうときにジャバ厨でない人のやり方をどうぞ
↓

0069デフォルトの名無しさん

NGNG

1. Singletonのインスタンスを2つ以上に変更できる
2. Singletonのインスタンスの振る舞いを、継承により変更できる

1. は、正直言って利点とは思えん。GoF本にはそう書いてあるが
そんなシチュエーションに出会ったことがない。

2. は、インスタンスメソッドなので継承が使えるということ。staticメソッドだと無理だから。
これを行う場合、ちょっとした言語依存の小細工が必要になる。
Javaなら、JDBCドライバのようにstatic initializer使えば何とかなるけど、
言語によっては他のパターン（Abstract Factory）を併用する必要がある。

ちなみに2だが、Webサービスクライアントで、通常時とデバッグ時で
異なるSingletonを渡して振る舞いを変えるコードを書いたことがある。

0070デフォルトの名無しさん

NGNG

いま開発中の会社のアプリは大半のクラスがSingletonになってる。
デザパタは分かりやすくていい。

0071デフォルトの名無しさん

NGNG

>>70
ご愁傷様です。これだからSingletonパターンは危険なんだ。

0072デフォルトの名無しさん

NGNG

>>71
いや、プロトタイプベースな言語ならば問題ない……と言ってみる

0073デフォルトの名無しさん

NGNG

>>69
>1. Singletonのインスタンスを2つ以上に変更できる
>2. Singletonのインスタンスの振る舞いを、継承により変更できる
3.どこからでも参照できる。

一番の利点だね。

0074デフォルトの名無しさん

NGNG

>>73
staticメソッドもどこからでも参照できますが。

0075デフォルトの名無しさん

NGNG

それじゃ、
staticメソッドを使わず、あえてSingletonを使う意義というものを
まじめに議論して見ましょう。

FIGHT! ⊂(ﾟ(ｴ)ﾟ)⊃

0076デフォルトの名無しさん

NGNG

コーディングしている全てのクラスがFacadeパターンと言えないか？

0077デフォルトの名無しさん

NGNG

>>75
例えば ClassA を Singleton にしても ClassA のオブジェクトとしてつかえることに変わりは無い
Singleton な ClassA をある日突然 Singleton じゃなくしても何も問題は起きない

>>76
そうなればより正しい設計といえるんじゃないか？

007877

NGNG

>>77 の下部
別に俺はデザパタヽ(´ー｀)ノﾊﾞﾝｻﾞｰｲじゃないとは言っておく
ただし、ごちゃごちゃしたクラスの塊は扱いたくない

007963=66=67

NGNG

>>68
ごめんなさい。
ちょっと矢印ではさんでみたかっただけなんです。
悪気はなかったんです。
ごめんなさい。

008060

NGNG

思ったより反応があったので喜んでいるのですが、ふと疑問に感じたことがあります。

>>69
>2. Singletonのインスタンスの振る舞いを、継承により変更できる
継承する場合、親クラス (Singleton) のコンストラクタへのアクセスって、
どうするのでしょうか？

>>74
私もそう思いました。

>>77
>Singleton な ClassA をある日突然 Singleton じゃなくしても何も問題は起きない
って、ClassA を Singleton だという前提で使用しているクラスがあれば、問題になるのでは？

0081デフォルトの名無しさん

NGNG

>>80
一段落目：コンストラクタはprotectedで公開するだろうしサブクラスからは問題なくアクセスできるんちゃう？
二段落目：staticメソッドでアクセスできてもインスタンス化してないんじゃ状態をもてないでしょ。
三段落目：Singletonインスタンスへのリファレンスが一意であるとしてsomeObj == otherObjとしたときは問題になるかも。
でも、そういうことを避けるために隠蔽をかけるわけで、someObj.equals(otherObj)とやらせて==使ったときの挙動は保障しませんよとする。
C++とかではグローバルなスコープに一個だけオブジェクトを作成して他からexternさせる形をとる変わりに、
ファクトリメソッド使わせて一個のインスタンスを共有させるとか。

0082デフォルトの名無しさん

NGNG

>>60
>クラス変数をプロパティとして持ち、そのアクセサ・メソッドを持つクラスで、
>事足りるのでは？と思ったのですが、どうなのでしょうか？

それはMonostateパターンという名前が付いている。

0083デフォルトの名無しさん

NGNG

>>80
んーと、Java依存の話だけどこう。
class Singleton{
　static protected Singleton instance;
　// Singletonインスタンスを取得する例のコード。略。
}

class SubSingletonA{
　static{
　　instance = new SubSingletonA();
　}
}

class SubSingletonB{
　static{
　　instance = new SubSingletonB();
　}
}

当時はこうやった。instanceがprotectedなところは、
Singletonのコンストラクタでセットすれば良かったかも。こんな感じ。
private Singleton(Singleton s){
　instance = s;
}
で、サブクラス側はこう。
private SubSingletonA(){
　super(this);
}
色々書いていて、もはやAbstract Factoryなんじゃないかと思ってきた。
実際このクラスは様々なDAOのFactoryだったわけで。

008469=83

NGNG

それから、上のSingletonを使う側のコードはこんな感じです。最初の１回目にこうやって、
if(Bを使いたい){
　Singleton instance = SubSingletonA.getInstance();
} else {
　Singleton instance = SubSingletonB.getInstance();
}
あとはAかBか気にせずに以下のように使用する。
Singleton instance = Singleton.getInstance();

JDBCみたいにClass#forName()でもいいんだけど。

0085デフォルトの名無しさん

NGNG

ぶっちゃけ Java案件って保守性低いよね。
個人の趣味が出すぎる

0086デフォルトの名無しさん

NGNG

フレームワークをつかえ

008760

NGNG

>>81
>一段落目：コンストラクタはprotectedで公開するだろうしサブクラスからは問題なくアクセスできるんちゃう？
protected で宣言している場合は継承できると思いますが、同一パッケージから
new 出来るっていうのは、Singleton パターンと呼べるのでしょうか？

>二段落目：staticメソッドでアクセスできてもインスタンス化してないんじゃ状態をもてないでしょ。
状態、と表現するのか分からないのですが、クラス変数で良いのでは？と思ったのです。

>>82
Monostate パターン....勉強不足でした。
これから調べてみます。

引き続き、この板は読みつづけますが、レス下さった皆さん
ありがとうございました。

0088デフォルトの名無しさん

NGNG

フレームワーク使っててもなんだかんだで自己満足な美意識を存分に発揮して
おかしなコードを書くやつが出てくる。

Cの案件ではコーディングルールを一律化して車輪は厳禁にしてるんで
仕事は早いしPGの差し替えも利く。

0089デフォルトの名無しさん

NGNG

ぐぐって引っかかった奴
ttp://www.sk-jp.com/java/pattern/singleton.html
ttp://www.hyuki.com/techinfo/singleton.html
http://www.hyuki.com/dp/dpinfo.html
ttp://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?forum=12&topic=5000
ttp://homepage3.nifty.com/satoshis/oo/memo.html#singleton

設定ファイルごとにシングルトンのラッパークラスを書くのって変？

0090デフォルトの名無しさん

NGNG

好きにすればいいと思うよ

0091デフォルトの名無しさん

NGNG

設定ファイルはSingletonの用途の成功例だろうと思うが

0092デフォルトの名無しさん

NGNG

百済ねー

0093デフォルトの名無しさん

NGNG

デザパタつかってりゃ、みんな成功例なんだろ
JAVAのライブラリの～は、～パターンの成功例だしな(　＾∀＾)ｹﾞﾗ

0094デフォルトの名無しさん

NGNG

なんか、

Javaを莫迦にする香具師は死んだほうがいい
http://pc5.2ch.net/test/read.cgi/tech/1092308415/

ここと雰囲気似すぎてる様な。

とりあえず、
Javaな人はGoFスレ出入り禁止にしよう！
このスレこないでね！

0095デフォルトの名無しさん

NGNG

馬鹿はﾆﾔﾆﾔしながら放置
自演始めてもぐっとこらえて放置

0096デフォルトの名無しさん

NGNG

> Javaな人はGoFスレ出入り禁止にしよう！
そうでもしないと
いつまでたっても建設的な話にならない悪寒

0097デフォルトの名無しさん

NGNG

＞ぐっとこらえて放置
つまり貴方はJAVA厨ってことですね？

0098デフォルトの名無しさん

NGNG

>>85
>>88
>>92
>>93
>>97
.dispose

0099デフォルトの名無しさん

NGNG

>>93
「デザパタつかってりゃ、みんな成功例なんだろ」

「デザパタ使っていれば成功です。」
誰かに言われ言葉の返事？
このスレには全く書かれてない。
すると貴方の職場で言われた？
ではなぜこのスレに返事するので？
職場では返事できないから？

なんてね。

0100デフォルトの名無しさん

NGNG

>>99 日本語勉強してから出直してこい

0101デフォルトの名無しさん

NGNG

>>60
DBCP

0102デフォルトの名無しさん

NGNG

ジブロモクロロプロパン・・・じゃないな
データーベースコネクションプール？

0103デフォルトの名無しさん

NGNG

ドラゴンボール厨房パワー

0104デフォルトの名無しさん

NGNG

>>10をもう一度読むこと

0105デフォルトの名無しさん

NGNG

必死で覚えたデザパタを
使うことが目的なんだから
使ってあれば成功例なのは当然

0106デフォルトの名無しさん

NGNG

Singletonの利点は、あくまでそれが生成のみに関るってことだと思う。
例えば基本クラスXと派生クラスXA・XBがあって、XAとXBのインスタンスを
それぞれひとつに制限したいとする。
でも、Monostateでは共通部分（特にクラス変数）をXに書くわけにはいかないよね？
（C++ならtemplate等で実装共有するって手もあるだろうけど）
Singletonは生成方法を制限しているだけで、XAとXBは独立したインスタンスだから
そういう問題は出ない。

あと、>>74の言うようにメソッドまでstaticにするとさらに問題が……。
俺は以前、高速化のためにSingletonをやめて変数／メソッドを全部staticに
したことがあるんだけど、二つのインスタンスを共通の方法でアクセスする方法が
なくなって難儀した（ｗ
（実装はtemplateやマクロで共有。C++の話ね）
そんときはアクセス用のクラスを作って、アダプタかませてしのいだけど。

0107デフォルトの名無しさん

NGNG

>>106
正解

0108デフォルトの名無しさん

NGNG

またJava厨の自演かよ

0109デフォルトの名無しさん

NGNG

>>108
正解

0110107

NGNG

>>108
不正解
106 と 107 は別人だ

どちらにしろ、言ってることはあってる

0111デフォルトの名無しさん

NGNG

まだいってるよ
誰が見ても >>106 = >>107 = >>110 だよな
あんな見当はずれなレスに
正解とかいう奴本人しかいないって(稾

0112106

NGNG

>>111
見当はずれだったか？　すまん。

でも俺、コードはC++で書く方が好きなんだけど……。
それでもJava厨なのか？　訳わかんなくなってきた。

0113デフォルトの名無しさん

NGNG

放置

0114107

NGNG

>>111
ま、真相は俺と 106 氏のみが知っているということでFA
おまえら、別に俺が 106 氏と同一人物じゃなくても構わないんだろ？
ならどっちだっていいじゃねーか

それから付け加えると、Singleton は“生成に関するパターン”だな。
コレくらい、感覚でわからないのか？

ちなみに俺は C++/C# だな。そもそも Java は遊びでしかやらん

0115デフォルトの名無しさん

NGNG

>>108 = >>109 = >>111みたいな馬鹿へ丁寧にレスしなくていいよ。
荒れるだけだから。

0116デフォルトの名無しさん

NGNG

これがJava厨って生き物ですか(；´Д｀)

0117デフォルトの名無しさん

NGNG

さわるなよ～

0118デフォルトの名無しさん

NGNG

このスレには「Java厨」は居ないが「Java厨かよ」と書き込んで話題を止めるヤツが常駐しているな。

0119デフォルトの名無しさん

NGNG

>>118
正解

0120デフォルトの名無しさん

NGNG

またJava厨の自演かよ

0121デフォルトの名無しさん

NGNG

ageで書いてるあたり120は本物の池沼くさいなｗ

0122デフォルトの名無しさん

NGNG

>>120
正解

0123在日外国人参政権反対

NGNG

Java中とか言ってる奴

　　馬鹿じゃねーの

0124デフォルトの名無しさん

NGNG

Java厨氏んで

0125デフォルトの名無しさん

NGNG

>>123
荒らしは死ね
Ｒｂｕｙ１！！！！！！！！！！！！１１Ｒｂｕｙｓａｉｋｙｏｕ！！！！！！！！！！
Ｒｕｂｙｓａｉｋｏｕｇｅｎｇｏ！！！！！！
Ｒｕｂｕｙａｎｔｏａｐｏｊｎｔｅ４ｐ２２２２２２２２２２２２
Ｒｕｂｙ！！！！！！！！！！

0126デフォルトの名無しさん

NGNG

もっともデザインパターンに向いている言語はマクロアセンブラ

0127デフォルトの名無しさん

NGNG

もっともデザインパターンに向いている言語はひまわり

0128デフォルトの名無しさん

NGNG

もっともデザインパターンに向いてる言語はHSP!!!

0129デフォルトの名無しさん

NGNG

いいかげんJava厨ｷｴﾛ

0130デフォルトの名無しさん

NGNG

C#の言語仕様はJavaの言語仕様を全て含んでいるので
Javaでできることは全てC#でそのままできる。
それなのに何故
｢デザインパターンに最も適した言語はJavaだ」
という言説が生まれるのか？
よく分からんな・・・
言語仕様がシンプルだからいい、とでも言うのか？？？

0131デフォルトの名無しさん

NGNG

>>130
本がいっぱい出てるから。

いやまじでこれは大きいよ。

0132デフォルトの名無しさん

NGNG

>>130
どの発言に対するレス？

＞｢デザインパターンに最も適した言語はJavaだ」
どこに書いてあるの？

0133デフォルトの名無しさん

NGNG

デザインパターンに最も適した言語はＲｕｂｙ！

0134デフォルトの名無しさん

NGNG

>>132
脳内のヒト。

0135デフォルトの名無しさん

NGNG

>>130
(´∇｀)ｹﾗｹﾗ
C# に Java のような匿名クラスなんて無いよ
Java に C# のようなデリゲートなんて無いよ
C# と Java の内部クラスの挙動は激しく違うよ

0136デフォルトの名無しさん

NGNG

というか>>130は｢デザインパターンに最も適した言語はJavaだ」という言説をどこで読んだんだ？
このスレで話題に上がっていないことを、突然語られても困るんだが。

0137130

NGNG

>135
匿名クラスも内部クラスもデザインパターンで使わないだろ？
そんな瑣末な例を挙げるなよ。

0138デフォルトの名無しさん

NGNG

宗教戦争はもうたくさんだ

0139デフォルトの名無しさん

NGNG

>>138
C ++字軍に参加しませんか

0140135

NGNG

>>137
130 の上から２行に突っ込んだだけだが……
デザパタとは関係ない部分であるにしろ、間違った認識を持つのはマズいぞ？

0141デフォルトの名無しさん

NGNG

>>136
このスレはこのパターンの繰り返し。

0142デフォルトの名無しさん

NGNG

>>136

あー>>130は >>99 これだろ。

0143.Net陣営

NGNG

>>138
では戦争を終わらせる為の戦争に参加したまえ。
我々は全てを飲み込む。

0144デフォルトの名無しさん

NGNG

ブビ廚なんぞハナっから相手ではないわ

0145デフォルトの名無しさん

NGNG

デザインパターンくらい知ってることが基本の職場に転職した。
意思疎通が格段に違う。
設計やビジネスプロセスの検討においても、「いわゆるCompositeで」とか平気で使えるし。

相手にパターンの知識がないことを前提におけない前職よりははるかにやりやすい。

0146デフォルトの名無しさん

NGNG

そらよかったね。

0147デフォルトの名無しさん

NGNG

そういうとこは開発プロセスも
アジャイルとかいう奴なんでしょうか。

0148デフォルトの名無しさん

NGNG

>>145
どこの会社か教えてくれ。

0149デフォルトの名無しさん

NGNG

>>148
それは言えない。でも実在する会社だよ。嘘じゃないよ。

0150デフォルトの名無しさん

NGNG

色んな所に疑問を投げかけてマルチっぽくて
恐縮なんだけど、誰も明確にレスつけてくれないんで
145にききたいんですが。

もしその会社が、開発手法もバリバリアジャイルだったら
どうやって顧客に見積りを提示して
受注したのかすんごく知りたいのです。
色んな本読んでもどこにもその事が書いてなくて
すんごい疑問で、アジャイル開発ってとてもよいと思うけど
現実感がちいともわかんのです。

0151145

NGNG

>>150
見積もりは、最終的なかたちは人月計算にしてる。
ただ、見積もりの再計算の機会を何回か設けている。

要件を追加するごとにお金を要求するのは、現実的ではない。
経営としてGOがでれば、成功時利益の5%とかできるけど、リスクが激高でこれも現実的ではない

特段に変わったことはしてないよ。
「要件定義が終わった段階で再見積り」という提案書を書く企業は多いでしょ。
顧客が予算を確保しやすい形にしてあげないと、本末転倒だし。

アジャイルにやっていく上で必要な管理は、要件を可視化してあげること。
プロジェクトが火を噴きそうになったときに、要件に優先度ABCをつけたりするでしょ。
あれをプロジェクトの最初からやるのが必須。
要件ごとに属性として締め切り期日やステータスを明示しておく。

UsecasePointみたいな方法は、
それこそ相当数の母集団による統計値があってはじめて成立するし。

# >>149は自分じゃない

0152デフォルトの名無しさん

NGNG

>要件を可視化してあげること
すげーうちのデザパタ厨管理者に見習わせてやりてー。
まともなところは流石だな・・・用件を可視化できないくせに
部下には妄想アジャイルを求めるから最悪だ

0153デフォルトの名無しさん

NGNG

いいかげん自作自演やめて出て逝けよ

0154デフォルトの名無しさん

NGNG

お前がなー

0155150

NGNG

＞151
わー初めて現場の声がきけたうれしー。ありがとう。
ありがとうついでにもちょっと。

所謂ウォーターフォールでも途中で再見積りってのは
確かにありましたが、やっぱりお客さんは良い顔しないものです。

それがアジャイル本読むと、具体的には例えば「実践UML」なんですが
要件が全て明確にならない内にどんどんイテレーションが進んでて
一体何時の段階で顧客との合意をとるのかが全然判らない。
その「要件定義が終わった段階」ってのが全然見えない訳で、
逆にそれが売り文句だったりしてます。
最初は要件は10%もあがればいい、網羅しようと思うなとまで
書いてあります。

あ、要件定義ってのはユースケースの事を言ってます。

一体何時見積もり承認取るのか、何回再見積りするのか、不思議で不思議で。
アメリカと日本の商習慣の違いなのかなあとまで考えてました。

で、おっしゃるように、要件をしっかりと視覚化して、
優先順位をきっちりつけて（トリアージといいますね）、
となると見積りに関する疑問は全く湧きません。私もするでしょう。
ただそうなると、書籍などで説かれるアジャイル開発とはややズレも感じます。
これはけなしてるのではなくて、より実践力がある形になってるという意味です。

他にも、いやうちはユースケース定義もアジャイルでやって
見積りもその都度見直しで顧客を納得させたぜって方のお話も、
本当にあるんだったらききたいです。

いやー本当有難う御座います。

0156デフォルトの名無しさん

NGNG

いいかげん自作自演やめて出て逝けよ

0157在日外国人参政権反対

NGNG

理解できず煽ることしか出来ない人のいるスレはここですか?

0158デフォルトの名無しさん

NGNG

civ3スレ荒らした馬鹿はお前かね？

0159150

NGNG

いいレスつけてもらって感謝すると
大概ジサクジエン。
まあ風物詩ですからそれもまた一興。

でもデザパタスレからすると
スレ違いも否めんですな。すまん。

0160在日外国人参政権反対

NGNG

＞158
自分に対してのレスですか?　civ3が何のことかわかりませんが．

＞159
スレ違いじゃない．もっとやってくれ。

0161デフォルトの名無しさん

NGNG

どっちかって言うとこっちのスレのほうが適切
ttp://pc5.2ch.net/test/read.cgi/tech/1091773629

0162デフォルトの名無しさん

NGNG

指定厨とクソコテがいる限りこのスレは駄目だろ

0163デフォルトの名無しさん

NGNG

Java厨ってほんと見苦しいね
頼むから氏んで(・∀・)

0164デフォルトの名無しさん

NGNG

なんか、脳内世界の発表会みたいなスレになってるね。

0165デフォルトの名無しさん

NGNG

>>164
そうそう。会話になってないよな。

0166デフォルトの名無しさん

NGNG

目を覆いたくなるような恥ずかしい自作自演だ
自分だったら首釣って氏んでるな

0167デフォルトの名無しさん

NGNG

>>166
だからさぁ、誰に言ってんの？
脳内世界の語り手って言われちまうぞ

0168デフォルトの名無しさん

NGNG

脳内世界の語り手登場

0169デフォルトの名無しさん

NGNG

VB.NETでもC#.NETでもいいけど、MS系でデザインパターンしてるやついる？

0170デフォルトの名無しさん

NGNG

MFCで　｡･ﾟ･(ﾉД‘)･ﾟ･｡

0171デフォルトの名無しさん

NGNG

>>169
やってるよ

0172デフォルトの名無しさん

NGNG

SDKで。

0173デフォルトの名無しさん

NGNG

> わー初めて現場の声がきけたうれしー。ありがとう。
ﾜﾗﾀ

0174169

NGNG

>>170
>>171
>>172
MFCとかSDKとかそういうんじゃなくてさ、業務でよ。

0175デフォルトの名無しさん

NGNG

業務でSDKだよ。
MSだろうがなんだろうが
関係ないだろ。

0176デフォルトの名無しさん

NGNG

>>169
>>174
「デザインパターンしてる」って何よ。

0177デフォルトの名無しさん

NGNG

デザパタってる。

0178デフォルトの名無しさん

NGNG

＞174
それらのレスみたらMFCベースの開発でとか、SDKベースの開発でという意味でしょう.
そもそも、言語ならともかく、MS系でというのが何を指すのかよくわからんです...

0179デフォルトの名無しさん

NGNG

モビルスーツか？

0180デフォルトの名無しさん

NGNG

>>178
つまり実務でC#使っているやつは、デザインパターンを知らないどころか、自分でクラス作れるやついないってことだな

0181デフォルトの名無しさん

NGNG

>>180
流石に C# でクラスを作れない奴は居ないだろう。
この場合引き合いに出されるのは　『クラスを使えるか』もしくは『クラスに使われるか』だ。

0182デフォルトの名無しさん

NGNG

実務でC#使っているが、俺のプロジェクト誰一人としてまともなクラス作れてない
C++/Java上がりの連中なんだがな、どうしたものか。

0183デフォルトの名無しさん

NGNG

まともなクラスの定義はなんだよ。
C++/Java上がりの連中はCLRのクラス構成を熟知しているわけじゃないんだから
いきなり投げ込まれても正しく分析なんてできないだろ。

0184デフォルトの名無しさん

NGNG

>>183
逆でしょ、CLRだなんだっての知ってても
それは実装レベルの話じゃん。

普通「まともなクラスが作れない」という場合は
設計レベルの話だよね。言語は関係ない。

他のオブジェクト指向言語経験者なら
出来ると思ってたのになって事でしょ、182は。

0185デフォルトの名無しさん

NGNG

>>182
まず他人と会話してみるのがいいと思うよ

0186デフォルトの名無しさん

NGNG

＞182
俺のプロジェクトが一人プロジェクトだったら面白い

0187デフォルトの名無しさん

NGNG

デザインパターンしてる。
デザパタってる。
デザってる。
パタってる。
ザパってる。
タってる。

>>182
どれがいい？

0188デフォルトの名無しさん

NGNG

デンパってる、がいい。

0189デフォルトの名無しさん

NGNG

IT Pro 技術の広場
羽生田栄一の「オブジェクト論」
http://itpro.nikkeibp.co.jp/members/NBY/techsquare/20040907/1/mokuji.jsp
羽生田栄一の「デザイン・パターン論」
http://itpro.nikkeibp.co.jp/members/NBY/techsquare/20041006/150890/mokuji.jsp

0190デフォルトの名無しさん

NGNG

お気に入りの新着をすべて開くの動作が変わった?
新着あるものすべて開くんだけど、新茶区分を取得しに行かない.

とおもったら、その他のすべてを開くうんぬんで直った　
あと更新チェック５分の待機時間長すぎ

0191デフォルトの名無しさん

NGNG

誤爆スマン

0192デフォルトの名無しさん

NGNG

>>189
宣伝乙

0193デフォルトの名無しさん

NGNG

安定したインタフェースを抽出できなくて困っている。
俺の頭が悪いのか？　･ﾟ･(ﾉД‘)･ﾟ･｡

対象としているもののアルゴリズムは安定しているんだけどな．．．
インタフェースを中心に据えなくちゃオブジェクト指向と言えないですよね？

0194デフォルトの名無しさん

NGNG

>>193
最後の行に書いてるようなことを気にしすぎてはいけない。

これ読め、できれば本も。
ttp://www.ogis-ri.co.jp/otc/hiroba/technical/MPD/

マルチパラダイムデザインの中核となる概念は共通性と可変性だ。
お前のドメインでアルゴリズムが安定要素なのであれば、それに応じた
ソリューションがあるということ。

0195デフォルトの名無しさん

NGNG

>>それに応じたソリューションがあるということ。

それがわからないから苦労してるんでしょ？
閉経

0196デフォルトの名無しさん

NGNG

何も言ってないのと同じだよな。
断言すると叩かれる、だから曖昧にしておく。

0197デフォルトの名無しさん

NGNG

ソリューションドメインの分析をしなきゃいけないようだけど
>>193の環境がわからないことには始まらない。C++だというなら
当てはまるのかも試練が。

0198デフォルトの名無しさん

NGNG

俺も、マルチパラダイムデザインは白眉だと思う。

「共通性と可変性」だけに言及するとなんか当たり前っぽいけど、
凄い分析なのは「共通性と、正の可変性と、負の可変性」に分類したこと。
読め。おら読め。

0199193

NGNG

マルチパラダイムデザインですかー
本自体は聞いたことあるけど読んでみることにします。

>>197 C++です。当てはまるというので期待してます。

0200デフォルトの名無しさん

NGNG

現実の問題領域がシングルパラダイムでは表現できないなんて当然だよな。

インタフェースを中心に据えなくちゃ・・・
なんて風潮があるとしたらほんと有害。

0201デフォルトの名無しさん

NGNG

マルチパラダイムデザイン・・・

売ってない　･ﾟ･(ﾉД‘)･ﾟ･｡

0202デフォルトの名無しさん

NGNG

そこでマルチパラダイムして別の本を買え！

0203デフォルトの名無しさん

NGNG

>>200
俺は据えても構わないと思うんだけど
周りを残しておけば

>>201
bk1 に残ってるみたい。今俺も注文した

0204200

NGNG

>>203
> 俺は据えても構わないと思うんだけど
> 周りを残しておけば

なんかコワい雰囲気・・・
迂闊に近寄ると切られるかも

0205203

NGNG

>>204
切らんよw

0206デフォルトの名無しさん

NGNG

マルチパラダイム届いた。ざっと目を通してみたけど、
設計手法をパターン化し、『一歩離れたところから見て』まとめた
モノとして考えていいの？なにやらごちゃごちゃ書いてあるけど

0207デフォルトの名無しさん

NGNG

読み終わったか？

0208206

NGNG

読み終わった
理解にはもう少し時間かかると思う

0209デフォルトの名無しさん

NGNG

すごいじゃないか！こんな短時間で読み終わるだなんて！！

実は半分しか読んでない俺にエッセンスを教えてくれ

0210デフォルトの名無しさん

NGNG

マルチパラダイムに対する
『シングル』の方はどんなパラダイムなわけ？

0211デフォルトの名無しさん

NGNG

独身パラダイム

0212デフォルトの名無しさん

NGNG

マジレスまたは真面目な付き合いを望む

0213206

NGNG

>>209
無理だ。内容が濃すぎて頭の端から抜けていく^-^;

0214206

NGNG

>>212
とりあえず、全然理解できていない身で悪いが、

『シングルパラダイム』とは、今まで使用されてきたとおりの言語パラダイム
（例えばオブジェクト指向とか）を指すようだ

『マルチパラダイム』は、それらシングルパラダイムを全部ひっくるめて
さらに＋αしたものを考える手法を指っぽい

違うかも。っていうか例の本は生半可な気持ちで読むもんじゃない＝■○＿

0215デフォルトの名無しさん

NGNG

逆に自然体だよなあ

△△を中心に据えよ！

．．．って気張るよりも

0216デフォルトの名無しさん

NGNG

117ページ

オブジェクト指向パラダイムは、型と構造に共通性を仮定する。
そして、実装において可変性を表現する。ファミリの構成員を
この枠組みに溶かし込むことができるのであれば、オブジェク
トパラダイムはよくフィットしているということになる。

・・・やってみなきゃわからないってこと？

0217デフォルトの名無しさん

NGNG

ポリモーフィズムうまく使えるようにモデリングできるかということはないのか？
ポリモーフィズム使えるということは汎化がうまくいって、共通の枠組みに押し込めてるということだから。

0218デフォルトの名無しさん

NGNG

ポリモと言えばp114とp137にあるように広く見てるね

１　多重定義・・・つまりオーバーロード
２　パラメタライズド・・・クラステンプレートと関数テンプレート
３　キャストによる型変換
４　継承による普通の（せまい）意味でのポリモ

の４つをポリモと表現してる

0219デフォルトの名無しさん

NGNG

それは広すぎるんでは？

キャストして他の型にしてからそっちの機能を使うっての
までポリモーフィズム？
テンプレートは「コンパイルタイムポリモーフィズム」と
呼ばれることもあるので違和感少ないが。

0220デフォルトの名無しさん

NGNG

ポリモーフィズムといえば４のようなことを言うんだと思ってた
頭固いかな

0221デフォルトの名無しさん

NGNG

キャストをポリモと解釈しているのは、キャストしても
もとのオブジェクトのアイデンティティが保たれている
と想定しているからだろ。
多態、すなわち同一のものがいろいろな側面を見せる
って意味ではキャストしようが何しようが構わんという
立場。

デザパタとはどんどん離れてないか？

0222デフォルトの名無しさん

NGNG

RMIで扱うスタブを末端のオブジェクトに渡すのってあまりよくないですよね？
皆さんだったらどうしますか？
僕はADAPTERパターンがいいのかな？と感じました。

0223デフォルトの名無しさん

NGNG

Gammaです・・・

ADAPTERパターンがいいと思ったらとりあえず実装してみては？

・・・Gammaです

0224デフォルトの名無しさん

NGNG

>>223
Erich Gammaの事かな？
まだ皆さんの意見を聞きたいですが、早速実装してみます。

0225デフォルトの名無しさん

NGNG

Gammaです・・・

ADAPTERパターンがダメだといっても、たぶんこの人は反論して使うとです。

・・・Gammaです

0226224

NGNG

>>225
人がどのように行動するか不確かな根拠で予言するのはスレ違いだと思います。
でも一応意見を参考にさせていただくことにしました。
今後適応パターンの判断から実装まで弟に任せることにしました。
うちの弟はどうですか？

0227223

NGNG

>>224
偽Gammaに負けずにがんがれ！

0228224

NGNG

>>227
応援ありがとうございます。
でももう弟に任せたから、弟に頑張ってもらうつもりです。
弟もこのスレ利用するかもしれないので、そのときはよろしくお願いします。

0229デフォルトの名無しさん

NGNG

＞228
弟
http://life5.2ch.net/test/read.cgi/jinsei/1097681554/

0230デフォルトの名無しさん

NGNG

State パターン使う場面を見出せなかったが、ゲームの状態遷移に思いっきり使えると気づいた今日この頃
気づくの遅いなぁ orz

0231デフォルトの名無しさん

NGNG

Stateパターンはものすごく参考になった。
switch文はほとんど出番なしなﾖｶｰｿ

0232デフォルトの名無しさん

NGNG

＞229
何このスレ･･･
ねた?

0233223

NGNG

State と Strategy の違いってどんなんだっけ？

0234230

NGNG

>>233
どちらも委譲で挙動をごっそり替える点では同じ

State … クラスで状態を表す
Strategy … アルゴリズムを切り替える
という目的において異なる

0235223

NGNG

ありがとう
でも、目的が異なるって説明はいろんなところで
見た覚えがある（State vs. Strategy に限らず)けど
それだけじゃ異なるパターンとして別にする程のこと？
って思いが残る．．．

0236デフォルトの名無しさん

NGNG

>>235
デザインパターンが主とするオブジェクトパラダイムだと、
現実世界と如何に対応させるかが１つの焦点となるから、
ある意味でこれは自然な事だと思うけど……

0237デフォルトの名無しさん

NGNG

目的が異なるってことだけなら、クラス図は多少違うけど
CommandとStrategyも似ているよね。
違いはサブクラスの許容量の違いだと認識しているんだけど
Strategy・・・何かしらの共通目的をもつ
Command・・・何でも良い。
違う？

0238デフォルトの名無しさん

NGNG

とりあえず例の本を読み切った
『可変性』って言葉は、「仕様の変更に対処するための柔軟性」って読みかえてもいいものだろうか……

そんなことはどうでも良い

『Chain of Responsibility』パターンだけど、
各オブジェクトが「次のオブジェクト」を知っている必要があるのは何となく違和感があるような気もする
俺の場合、単純だが処理にかかわる全てのオブジェクトを保持するクラスを作り

foreach(Handler c in handle) {
    if (c.handleRequest()) {
        break;    // 処理できたら抜ける
    }
}

みたいな感じにすることが多いが、『CoR』パターンって使ったことある人いる？

0239デフォルトの名無しさん

NGNG

構文木みたいのも一種のChain of Responibilityじゃないかな。
それなら何度も使ってる。

0240デフォルトの名無しさん

NGNG

>>238
イメージ／オーディオ／ビデオのフィルタみたいなのもCoRじゃないのかな？
同型インターフェイスを持つオブジェクトを自由に接続して連鎖的に処理させるやつ。

> 各オブジェクトが「次のオブジェクト」を知っている必要があるのは何となく違和感があるような気もする
例えば、各オブジェクトが「次のオブジェクト」の持つ属性によって処理を変えたい場合とか。

0241238

NGNG

>>239-240
あ～何となく分かった
今まで CoR を「処理を行うオブジェクトを探す」用途としてしか見てなかったみたい

確かに処理のパイプラインみたいなのも、CoR の一種として考えられるような気がする
サンクス。参考になった

0242デフォルトの名無しさん

NGNG

もうGoF本から外した方がいいパターンはないかね？

・・・投票の結果、4つのパターンが締め出された。
Factory Method、Bridge、Flyweight、そしてInterpreterだ。

ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?OOPSLA2004

BridgeはStateとStrategyがあるからもういいや、ってこと？

0243U ◆CZtFsGiu0c

NGNG

>>242
Bridgeは特定の言語以外では有効な使い道がないからじゃないですかね。
JavaやSmalltalkでBridgeの使い道ってありますか?

Flyweightは、富豪的プログラミングに反するからですよね:-)

0244デフォルトの名無しさん

NGNG

用途が特化されすぎると「用途が限られるからパターンじゃない」と言われ
用途が一般的過ぎると「そんなのパターンと呼ばなくても普通に使うだろ」と言われる。
適度に用途が限定されたパターンというのはそんなに多くないかもね。
http://hp.vector.co.jp/authors/VA020635/system/dpattern.html

0245デフォルトの名無しさん

NGNG

0246在日外国人参政権反対

NGNG

なんかいろんなスレで本文のない書き込みがあるんだが、誰かなんか作って変なテストしてるのか？

0247デフォルトの名無しさん

NGNG

>246
クソスレ見すぎ

0248デフォルトの名無しさん

NGNG

クソコテがクソスレをつくる

0249在日外国人参政権反対

NGNG

またチ（ｒｙ

0250デフォルトの名無しさん

NGNG

糞スレを作るのは、コテハンをみると決まって過剰反応する厨房名無しだろ。

0251デフォルトの名無しさん

NGNG

臆病者が伏せ字を使っていい気になってるスレはここですか？

0252デフォルトの名無しさん

NGNG

>>250
同意
俺の場合246は透明あぼ～んされている
これお薦め

0253デフォルトの名無しさん

NGNG

>>244
ところでマジネタなんだが、パターンってつまり『クラス間の関係を表す』ものだと俺は認識してるから、
＞「そんなのパターンと呼ばなくても普通に使うだろ」
ってすごく変な感じがする。

デザパタって、困ったときの道具箱じゃないのにな～

0254デフォルトの名無しさん

NGNG

『アンケート』
実際に使ったことのあるデザインパターン
さぁどぞ

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

0255デフォルトの名無しさん

NGNG

visitor

0256デフォルトの名無しさん

NGNG

し、しんぐるとん…　にゃんにゃん

0257デフォルトの名無しさん

NGNG

State

0258デフォルトの名無しさん

NGNG

composit, iterate, visitor, builder, facade

0259デフォルトの名無しさん

NGNG

Product Trader パターンについて詳しく書かれているサイト or 本ってないですか？

0260デフォルトの名無しさん

NGNG

Singleton,Observer,state,Strategy,facade,Composite,Command,

0261デフォルトの名無しさん

NGNG

Singleton, Mediator, Strategy, Composition, Visitor

0262デフォルトの名無しさん

NGNG

卑怯な手段としての
Mediator

0263デフォルトの名無しさん

NGNG

どんな場面で使ったとかコメントもあるとおもしろいかも
300取ったやつカウントよろしく
じゃ続き

↓↓↓↓↓↓↓↓↓↓↓↓↓

0264デフォルトの名無しさん

NGNG

Mediatorっていうか今思うとFunctorだな。
Mediatorの抽象ベースクラスがあって、派生クラスはテンプレート。
Boostのファンクタみたいな感じ。
５年以上前にしちゃイケてたかな。。。

0265デフォルトの名無しさん

NGNG

GoF 以外でどんなパターン使ってる？

0266デフォルトの名無しさん

NGNG

アンチパターン

0267デフォルトの名無しさん

NGNG

IoCってGoF？

0268デフォルトの名無しさん

NGNG

表面上ファクトリー使うから関係はあるけど
パターン自体は入ってない、よな。

0269デフォルトの名無しさん

NGNG

ぬるぽパターン

0270デフォルトの名無しさん

NGNG

DIって、spring出るまで知らなかったけど
割と最近の手法なのかな。

0271デフォルトの名無しさん

NGNG

>>269
ｶﾞｯ　パターン

0272デフォルトの名無しさん

NGNG

ttp://patterns-wg.fuka.info.waseda.ac.jp/study/8th.html
最近ググって見つけたんだけど、ひがやすを氏の説明がわかりやすかった

0273デフォルトの名無しさん

NGNG

Mediatorパターンと、Observerパターンの違いがよくわからないのですが、俺なりには、
同僚にイベントを通知されるのがMediatorパターン
非同僚にイベントを通知するのがObserverパターン
と解釈したのですが、他の方はどのような解釈をしているのでしょうか。

0274デフォルトの名無しさん

NGNG

>>273
解からないなら解かるようになるまで教典を読みましょう。

0275デフォルトの名無しさん

NGNG

>>273
Mediatorは通知先を個体識別している。
Observerはしていない。
Mediatorは、なんかのイベント発生時に、どの通知先に何をすべきか知っている。
Obserberは、しらない。イベントが発生したことを知らせるだけ。通知を受けて何をするかは、Observable が決める。

0276デフォルトの名無しさん

NGNG

>>273
ObserverとMediatorの比較ということなら，
Observerを適用した場合　通知相手のオブジェクトに関する情報が
各オブジェクトに分散して管理が難しくなることがある
Mediatorの場合はMediator役が通知の交通整理を一手に引き受けるので
Observerを適用した場合に比べ管理は簡単になる（が，クラス間の結合が若干強くなる）

どちらを使うかは状況次第
教典の適用可能性とか目的とかの項を読んで判断

…でいいのかな…自信ないけど

0277デフォルトの名無しさん

NGNG

>>270
昔から「コールバック」という名前で知られていたのでは

0278デフォルトの名無しさん

NGNG

>>277
コールバックとは違うようなが気がしないでもないが
勉強不足なのでよくわからない　だれか解説ｷﾎﾞﾝﾇ

パターンってのは熟練開発者の中に眠るノウハウに名前をつけて
明文化する手段だから「～は昔からあった」という指摘は多いね
逆にそういう知識でないとパターンになりえないんだけど

0279253

NGNG

>>278
『ノウハウ』というのは格好付け過ぎかと

よく見るクラス間の構造が『パターン』だと俺は認識してる
熟練とかそんなのは関係なかったり

一番最後の行には激しく同意
この行に疑問を持つ人は、一体どういう認識でデザパタを捉えているのか正直知りたい

0280デフォルトの名無しさん

NGNG

Strategyパターンと、Observerパターンと、Stateパターンの違いがよくわからないのですが、俺なりには、
入れ替える中身が戦略だとStrategyパターン
入れ替える中身が観察者だとObserverパターン
入れ替える中身が状態だとStateパターン
と解釈したのですが、他の方はどのような解釈をしているのでしょうか。

0281デフォルトの名無しさん

NGNG

もくてきぜんぜんちゃうやん。
同じどうさせアルゴリズム変わってるのがストラテジーで
状態による動作の変化を隠蔽したのがState
相手のことを知らず通知したいときがObserver

0282デフォルトの名無しさん

NGNG

>>279
278は，デザパタも含む，もっと広い意味でのパターンを
思い浮かべながら書いてた
デザパタスレだということをすっかり忘れてたorz　すまぬ

>一番最後の行には激しく同意
(･∀･)人(･∀･)

>>280
オブジェクトを互いに交換可能にして再利用しやすくする，
という目的なら共通している気がしないでもないけど，
それはデザインパターン全体で共通する目的でもある
教典の名前に入ってるくらいだし＞オブジェクト指向における再利用のための～

0283デフォルトの名無しさん

NGNG

>>280
形は似ているからね。特に Strategy と State は。
形が似ていても目的が違うときには、違う名前をつけるのが、
デザイン・パターン流みたいだね。>>281はそのことを言っている。

0284デフォルトの名無しさん

NGNG

クラス図同じだしな

0285デフォルトの名無しさん

NGNG

美しいソースコードを書いても給料は上がらないし会社は評価してくれない。
かなしいけどコレが現実。デザパタは知識としてはある程度有意義だけど
プログラムで一番重要なのは「ちゃんと動く」こと。次に手を抜くこと。
君たちは真面目すぎる。もういっぺん言おう
美しいソースコードを書いても

　会　社　は　評　価　し　て　く　れ　な　い

0286デフォルトの名無しさん

NGNG

デザパタってコーディング技術じゃなくて設計技術だろ

0287デフォルトの名無しさん

NGNG

そうすると「コーディング技術」とはなんだろう・・・。
キーボードを早く打てるぜ俺は、とかに
なっちゃうんだろうか・・・。

0288デフォルトの名無しさん

NGNG

イディオムとかそういう類じゃないかな。
ファイルアクセス時のtry～catchはこう書け、とか、文字列のNULLチェックはこうしろ、とか。

0289デフォルトの名無しさん

NGNG

なるほど。言語依存な所な訳ね。

0290デフォルトの名無しさん

NGNG

いや、そんなに言語依存でもないか。
リソースはちゃんと解放しようぜ、とかそういう話か。

そもそもデザインって設計って意味だよな。
そりゃ設計技術だよもちろん。

0291デフォルトの名無しさん

NGNG

>>290
俺は『クラス関係のデザイン』やとおもとった
……っていうか設計と同じ意味か

>>285 は、もう一度デザパタを勉強しなおすこと

0292デフォルトの名無しさん

NGNG

>291
そうそう、日本語カタカナでデザインていうと、
クリエーチブな業界のイメージだろうから
285みたいな意見が出るのだろうか。
考えすぎか。

とかいう俺もデザパタって言葉を知るまで
設計がデザインと訳されるとは知らなかったんだけどね。
おほほ。

0293デフォルトの名無しさん

NGNG

285は、「なるべく簡単にちゃんと動く」こととデザパタを相反する概念と考えているみたいだけど、なんでだろ
。デザパタは、「なるべく簡単にちゃんと動く」ための工夫に他ならないのに。惜しいね。

0294デフォルトの名無しさん

NGNG

>>285
自分が楽をするために学んでるだけだからね。
会社の評価なんてどうでもいいよ。
会社の評価のためにやってるんだったら無駄だから勉強しないほうがいいよ。

>>286
あれが設計技術か！？
思いっきりコーディング技術だと思うけど。

0295デフォルトの名無しさん

NGNG

>>294
御前はクラス間設計をコーティング時にやってるのか？

正直、なんで御前がそんな見切り発進で生きてられるのか不思議でたまらん
（ちなみに、罵っているわけじゃなくて純粋な疑問）

悪いことは言わない。その考えはすぐに改めた方が身の為だと思う
クラス間設計はコーティング時じゃなくて設計時にやっとけ

0296デフォルトの名無しさん

NGNG

デザインパターンだけど実装方法も定義してあるから
コーディング技術も含む設計技術なんじゃないですか？

0297295

NGNG

>>296
どの本だよ実装方法なんて定義してあるのは

0298デフォルトの名無しさん

NGNG

>>296
実装は例示されているだけです(教典だとSample Code)
一応Implementationに実装方法についての議論はあるけど，
あくまで付加情報だと思う

0299デフォルトの名無しさん

NGNG

コーディングは技術ではなく技能だ
とか言ってみる

0300296

NGNG

そうっすね定義っていう言い方は間違いでした。
ただ自分はプログラマーなので実装のために読んだ。
SEだと見方もかわるのではと思う。

本
ttp://www.amazon.co.jp/exec/obidos/ASIN/4797311126/qid=1103803514/ref=sr_8_xs_ap_i1_xgl/249-8017190-9045969
ttp://www.amazon.co.jp/exec/obidos/ASIN/0201633612/249-8017190-9045969

0301295

NGNG

>>300
とりあえず、一冊の本から何を学ぶかはその人の能力次第だから文句のつけようが無いが、
俺はデザパタは設計技術だと思った。

色々と偉そうな事言ってごめん。
俺、SE でも PG でも無いただの学生、しかも本は結城本 orz

0302デフォルトの名無しさん

NGNG

>>285みたいな化石人間ってさ、自分がマトモな実装技術を理解できずに
スパゲッティコードを量産して「仕事ってのは芸術じゃなくて作業なんだよ！」
とか言って、部下に自分のダメコードのデバッグを押し付けるダメSEの
典型的な発想だよね。

0303デフォルトの名無しさん

NGNG

ちなみに言うと、デザインパターンってのは、別に
「美しいソースコードを書いて自己陶酔や品評会をするための技術」じゃなくて
「実装やデバッグや仕様変更で可能な限り楽をするための技術」だから、
有能なプログラマであれば、GoF本を初めて読みながら
「これって俺が前に自分で考えた仕組みと同じじゃんｗ」って思えるもんだよ。

0304デフォルトの名無しさん

NGNG

>>303
同感

俺は決して有能なわけじゃないが、知らず知らずの内にパターンに嵌る事って意外と多いよな
……Visitor が自然と組めたのにはビビッたよ

0305デフォルトの名無しさん

NGNG

>303
>ちなみに言うと、デザインパターンってのは、別に
>「美しいソースコードを書いて自己陶酔や品評会をするための技術」じゃなくて
>「実装やデバッグや仕様変更で可能な限り楽をするための技術」だから、

ちなみに言うと、デザインパターンってのは、別に
「実装やデバッグや仕様変更で可能な限り楽をするための技術」じゃなくて
「既存の技術に覚え易い名前を付けてカタログ化した」だけのもの。

0306デフォルトの名無しさん

NGNG

>>305
別に「GoFが全く新規に提案した」なんて前置きをつけてないし。

有能プログラマがGoF本を読む
→身に覚えがあるのですんなり理解

無能プログラマがGoF本を読む
→全く想像すらした事の無い発想ばかりで全く理解不能
→そして強烈なアンチGoFになり、GoF本を読む部下に嫌味を言いまくりｗ
→設計会議で「パターン」なんて言葉が出ようものなら「俺たちは芸術家じゃねーんだよ！」

その典型が>>285ｗ

0307デフォルトの名無しさん

NGNG

だからさ･･･でざぱたはそれまでのプログラム経験の中で有効だと思えたものを選んで分類整理したものだろ？
それ考えればおのぞから答え出てくるかと･･･

0308デフォルトの名無しさん

NGNG

しかし Bridge と FactoryMethod は有効だと思えない
俺の理解が浅いだけで、本当はいたるところで使われているのかもしれないが

0309デフォルトの名無しさん

NGNG

>>308
その2つの用途が分からんってのは、
お前がマトモにプログラムを書いた経験がないってのが丸分かりだな。

恥ずかしすぎるｗｗ

0310308

NGNG

>>309
すまぬ。俺の理解が浅かっただけらしい。

本だけで感じがつかめなかったから先ほどぐぐった。
どうやら、サブクラス関連で引っかかってたみたい。
過大解釈すれば、両方とも死ぬほど使ってる罠 orz

恥ずかしいので引っ込んでます |λ...

0311デフォルトの名無しさん

NGNG

>>308
がんがれ

0312デフォルトの名無しさん

NGNG

実装と振る舞いが分離されてりゃ全部 Bridge に分類されるのか？　素朴な疑問。

0313デフォルトの名無しさん

NGNG

だから、べつにパターンに分類することないんだツーの。
そのパターンらしきもの使うことで分離の利点を得られるならそれでいいんじゃ。

0314294

NGNG

>>295
ごめん。考え方の路線が違う意味でいった。

例えばシステムの要件を満たすのにどの言語が適してるのかとか、
過去のデータを集計したり、ソートしたりしたいとか言う奴がいたら、
んじゃ、ＣＳＶでデータ吐くからExcelかなんかでソートでも集計でもなんでもしてくれとか、
そういう視点の意味で言ってみた。

デザパタはたしかに設計ではあるけど「コーディングの設計」だと思う。
コーディングをしない限り適用する場面はないわけだし。
そういう意味で、やっぱ「コーディング技術」なのではなかろか。

0315295

NGNG

>>314
む～考え方が違うのか

俺はコーティングするしないに関わらずデザパタ適用するけどな
コーティングするのはそっから後

0316294

NGNG

>>312
ストラテジーとかいうのも実装と振る舞いが分離されているパターンだと思った。

というか、分類なぞどうでもいいと思われ。
StrategyもBridgeも「実装が容易に入れ替えられる」という
利点が得られればよい訳なのだから。

>>313
おお。激しく同意。

0317295

NGNG

>>316 上段
たぶん　Strategy と Bridge は違うっしょ

オブジェクト指向の基本概念の1つに
・継承、委譲などでの差分プログラミング
ってのがあるけど、殆どのデザパタはそれを使うから……

0318295

NGNG

317 の理由から、Strategy と Bridge に似ている部分があるのは当たり前
けど、この2つはぜんぜん違うと思う

0319295

NGNG

>>317
基本概念を
・実装と振る舞いの分離
に訂正

……微妙に例が適切じゃなかった

0320294

NGNG

>>315
クラス間設計をコーディング前にしっかりやるというは激しく同意。
いきなりコーディングからはじめるとわけのわからんものが出来あがって後で後悔するし。

すまぬ。漏れ設計っていわれちゃうと基本設計書とかそんなのが浮かんでしまうので。

0321295

NGNG

>>320
＞漏れ設計っていわれちゃうと基本設計書とかそんなのが浮かんでしまうので。
ああ、確かにそれならコーティングの設計というのはよく分かるわ

0322デフォルトの名無しさん

NGNG

StrategyとBridgeなんてまったく違うだろ。

Strategyは
・実装種類にかかわらず呼び出し形式(=INパラメータおよび戻り値)は共通
・実装種類によって処理内容のみが異なる
・Strategyとしてまとめることで、実装種類を入れ替えられるようになる

Bridgeは
・実装種類にかかわらず処理内容は一緒
・実装種類によって呼び出し形式が異なる
・呼び出し形式を共通にしたBridgeを、実装種類ごとに用意する
・Bridgeを経由することで、実装種類を入れ替えられるようになる

0323デフォルトの名無しさん

NGNG

俺が大雑把なのかも知らんが両方ともたたいの一種としてしか認識してません･･･

0324デフォルトの名無しさん

NGNG

>>323
一言で多態でくくらずに、分類して名前をつけることに意味があるんだと思われ。

>>322
そうまとめられるとBridgeはadaptorに似てるな。
共通のIFを定義して、実装種類ごとに共通のIFに合うようにadaptorを用意すると。

ところでStrategyとTemplateって実現方法として委譲を使うか、継承をつかうか
しか違いが無いように思うんだけど、それ以外に違いってある？

0325デフォルトの名無しさん

NGNG

>>324
デザインパターンは、適用後の姿をすべて見てしまうと「おんなじじゃん」となってしまう。
適用前の時点で何が分かっているのかに注目してみたらいいよ。

Strategy
なにかサービスを受け取るクライアントを作っている。
　ServiceResult result = serviceExecutor.execute(serviceStrategy);
サービスの実処理はいろいろある(もしくは、今は分からない)
→Strategyにして判断を後回しにしよう。

Template
何かサービスを実行するサーバーをいろいろと作っている。
前処理とか後始末とかあったりして、こいつら似てるな。
→Templateにしてまとめてしまおう。

0326デフォルトの名無しさん

NGNG

パターンというからにはテンプレートとしていつでも使えるようにすべき。
素人にもパターンを使えるようにするには、
いちいちそのパターンを意識してコードを書く、という概念モデルの段階では無理。
素人はパターン実装に振り回されて終わる可能性がある。
リストボックスから選択するなりして目的に合致するパターンを、
テンプレートとして即座に使える様な配慮が必要。
よって今後はテンプレート化できないような概念モデルは淘汰されていくだろう。

0327デフォルトの名無しさん

NGNG

>>326
お前は一生VBでトイプログラムでも作ってろｗ
もちろん、いっちょまえにシェアレジを利用してｗｗ

0328デフォルトの名無しさん

NGNG

UMLツールでパターン名のステレオタイプを書けたりする訳だが

0329デフォルトの名無しさん

NGNG

>>326
マジレスすると，
パターンは(素人でも使えることを目的にした)テンプレートではない．
知識を共有するための枠組み．(ソフトウェア設計への適用がデザパタ)
素人が素人から脱却する助けにはなりうるが，
素人がパターンを使っても良質なソフトウェアを作ることが出来るわけではない．

すまん，俺学生でトイプログラムレベルのものしか書いたことない・・・

0330デフォルトの名無しさん

NGNG

>>329
なら偉そうな事を言うな。カス。

0331デフォルトの名無しさん

NGNG

>>330
あんたよりはマトモに理解しているぞ、329は。

0332デフォルトの名無しさん

NGNG

>>331
そうでもないよ。

0333デフォルトの名無しさん

NGNG

ではがんばってプログラムオブ女医トイつくってください

0334デフォルトの名無しさん

NGNG

>>333
寒すぎて忘年会の酔いもすっかり冷めた

0335デフォルトの名無しさん

NGNG

カスとか、トイプログラムでも作ってろｗとか
おまいらは小学生か。
反論するならもっとまともな発言しる。

0336デフォルトの名無しさん

NGNG

カスはカスでいいじゃん。

0337デフォルトの名無しさん

NGNG

そんなおまいらに
ttp://www.shos.info/develop/oo/dscsnptn.html

0338デフォルトの名無しさん

NGNG

>>337
おもしろい！

0339デフォルトの名無しさん

05/01/30 16:32:19

保守age

0340デフォルトの名無しさん

05/01/30 20:22:06

Visitorパターンで、木構造（DOMツリーに毛がはえたようなもの）をたどる処理を書いています。
ここで、木構造を「たどる」という処理を、Visitor側で行うべきか、Acceptorとなる木のほうで行うべきか悩んでます。
今はVisitor側で行っているんだけど、Acceptor側の構造が変わったときにいちいち整合性をとるのが面倒になってきました。
みなさん、どっちに書いてます？

0341デフォルトの名無しさん

05/01/30 20:28:42

>>340
たどる処理って iterator がやるんじゃないのか？

0342デフォルトの名無しさん

05/01/30 20:36:08

>>340
各家を辿るのは訪問者の役目だから Visitor
Acceptor 側で違いが吸収できないくらい構造が変わったら、さっさと Visitor パターンを使うのを止めれ

0343デフォルトの名無しさん

05/01/30 20:44:32

どう考えてもvisitor

0344デフォルトの名無しさん

05/01/30 20:51:04

辿る側が Visitor で辿られる側が Acceptor
辿るクラスが入れ替わったら、Visitor も↑を満たすように入れ替わる

というか、>>340 は考え方が逆のような気がする
どちらかを Visitor と決めて辿るクラスをそれに合わせるわけじゃないよ

0345340

05/01/31 08:16:02

>>341-344
「たどる側がVisitor」って、いわれてみればそのとおり。だからVisitorという名前なんだよな。
どうもありがとう。めんどうでもがんばる。

0346デフォルトの名無しさん

05/01/31 17:14:24

つーかデザインパターンはさー
正しいOOPをするためのイディオム群という側面も確かにあるが、
それよりも重要なのは、開発者の間でFactoryとかStrategyっていう概念を
共有できることにあるんだろんー？
UMLと同じ勘違いをされてる気がするな。UMLも、あれは設計を記述することそのものより、
クラス設計を開発者間で共有することが重要なんだろー。

・デザインパターンを知らないＡ君とＢ君の場合
Ａ「おいＢ、ここどうやって実装する？」
Ｂ「んー、のクラスのインスタンスは二つ以上あるとまずいから、コンストラクタをprivateにして外部からnew出来ないようにしよう。
んで唯一のインスタンスをstaticメソッドでgetするようにする。
こっちのクラスは、状況によって選択するアルゴリズムが変わると思うから、アルゴリズムごとに処理専用クラスを作って、それを所持するようにする。
処理はそのクラスに丸ごと委譲する。」
Ａ「・・・？」

・デザインパターンを知ってるＡ君とＢ君の場合
Ａ「おいＢ、ここどうやって実装する？」
Ｂ「んー、このクラスのインスタンスは二つ以上あるとまずいからSingletonを適用しよう。
こっちのクラスは、状況によって選択するアルゴリズムが変わると思うから、Strategyを使って柔軟に処理を選択できるようにしよう。」
Ａ「ＯＫ」

0347デフォルトの名無しさん

05/01/31 20:15:04

確かに、枠組みであるという点でパターンとUMLは似ているかもしれない。

>>346
だいたい同意。
パターン名がコミュニケーションの語彙となるということだな。
GoFの一人であるブリシデスが言ってるな。(「パターンハッチング」)

あと細かいけど、デザインパターン≠イディオム

0348デフォルトの名無しさん

05/01/31 22:44:57

ああ、確かにイディオムってのは違うな。
イディオムと言えるほど具体的なコードで表せるのはSingletonくらいか？ｽﾏｿ

0349デフォルトの名無しさん

05/02/03 01:17:35

お客さんが満足するのでデザパタを使っています

0350デフォルトの名無しさん

05/02/03 02:17:39

>>340
遅レスだがツリー構造を知る第３者がVisitorをAccepterに突っ込ませたほうがいいんじゃないのか?
自分ならそうするが。
なんでVisitorがAccepterのコンテナのデータ構造を知らなきゃいかんの?

0351デフォルトの名無しさん

05/02/03 16:39:55

>>350
ツリー構造を知る第３者 = >>341のいうiterator
かな？

>なんでVisitorがAccepterのコンテナのデータ構造を知らなきゃいかんの?
禿同。

>>348
イディオムは言語依存っていうイメージがあるなぁ。

0352デフォルトの名無しさん

05/02/03 17:15:45

>>351
＞ツリー構造を知る第３者 = >>341のいうiterator
＞かな？
”んーVisitorをAcceptorに突っ込ませる人”です。
南下のクラスかもしれないし、コマンド処理するところにじか書きかもしれないし。
Visitorが自分でAcceptorに入り込んでいくよりは誰かがVisitorを突っ込ませるイメージだったので

0353デフォルトの名無しさん

05/02/07 00:13:12

>>346
・デザインパターンを知らないＡ君とＢ君の場合
Ａ「おいＢ、ここどうやって実装する？」
Ｂ「んー、のクラスのインスタンスは二つ以上あるとまずいから、コンストラクタをprivateにして外部からnew出来ないようにしよう。
んで唯一のインスタンスをstaticメソッドでgetするようにする。
こっちのクラスは、状況によって選択するアルゴリズムが変わると思うから、アルゴリズムごとに処理専用クラスを作って、それを所持するようにする。
処理はそのクラスに丸ごと委譲する。」
Ａ「ＯＫ」

だと思うぞ。言いたいことは分かるが。

0354デフォルトの名無しさん

05/02/07 00:44:59

・デザインパターンを知ってるＡ君とＢ君の場合
Ａ「おいＢ、ここどうやって実装する？」
Ｂ「あ？これSingleton、こっちStrategy。」
Ａ「え～っと、これをSingletonに、こっちをStrategyにするのは何故？」
Ｂ「（ﾟДﾟ）ﾊｧ? 駄目だオマエ（ ´,_ゝ｀）ﾌﾟｯ」

デザインパターンはコミュニケーションを阻害します！ｗ

0355デフォルトの名無しさん

05/02/07 00:57:55

デザインパターンとアンチパターンの融合か
美しいな

0356デフォルトの名無しさん

05/02/07 07:32:19

>>354
コミュニケーションを阻害しているのはBの態度だろうｗ

0357デフォルトの名無しさん

05/02/07 07:39:57

(1) Aは本当に分かっていない
(2) AはBの判断(2行目)が適切ではないと考え説明を求めた
Bが(2)の可能性を無視してるのが元凶ですな

って真面目にレスした私は釣られたのか？まぁいいや

0358デフォルトの名無しさん

05/02/07 07:43:17

空気嫁てないだけ

0359デフォルトの名無しさん

05/02/07 12:03:51

・デザインパターンを知らないＡ君とＢ君の場合
Ａ「おいＢ、ここどうやって実装する？」
Ｂ「んー、のクラスのインスタンスは二つ以上あるとまずいから、コンストラクタをprivateにして外部からnew出来ないようにしよう。
んで唯一のインスタンスをstaticメソッドでgetするようにする。
こっちのクラスは、状況によって選択するアルゴリズムが変わると思うから、アルゴリズムごとに処理専用クラスを作って、それを所持するようにする。
処理はそのクラスに丸ごと委譲する。」
Ａ「え～っと、のクラスのインスタンスは二つ以上あるとまずいから、コンストラクタをprivateにして外部からnew出来ないようにして、
んで唯一のインスタンスをstaticメソッドでgetするようにする。
こっちのクラスは、状況によって選択するアルゴリズムが変わると思うから、アルゴリズムごとに処理専用クラスを作って、それを所持するようにする。
処理はそのクラスに丸ごと委譲するのはなぜ」
Ｂ「（ﾟДﾟ）ﾊｧ? 駄目だオマエ（ ´,_ゝ｀）ﾌﾟｯ」

問題はＢの態度と判明

0360デフォルトの名無しさん

05/02/07 12:13:15

こぶがひっこんじまったい

0361デフォルトの名無しさん

05/02/08 01:13:50

>>359
ﾜﾛﾀ

0362デフォルトの名無しさん

05/02/09 23:23:39

ファウラー氏のアナリシスパターンが意味分からん。

0363デフォルトの名無しさん

05/02/10 16:07:22

>>362
分析屋さん(?)が読むような本だからね…。
「責任関係」とか「観測」あたりは比較的分かりやすいと思われ
ｶﾞﾝｶﾞﾚ

0364デフォルトの名無しさん

05/02/11 21:59:29

>>362
だいじょうぶ、わからんのはおまえだけじゃない。みんなわかったふりしてるだけだ。

0365デフォルトの名無しさん

05/02/12 17:26:16

俺もわかんね

0366デフォルトの名無しさん

05/02/12 20:57:17

何でそういう風に分析する糧のを考えるのにはいいね。
覚えるもんじゃない。考え方を学ぶもの。

0367デフォルトの名無しさん

05/02/14 04:40:13

C#によるデザインパターン
http://www.dofactory.com/Patterns/Patterns.aspx

0368デフォルトの名無しさん

05/02/19 22:24:31

MedieterとObserverの違いを普通に教えてください。
集中管理という目的では同じに見えるんですが。

0369デフォルトの名無しさん

05/02/19 22:34:33

>>368
前者は伝達経路に対するパターン。
後者は伝達方法に対するパターン。
両者はそもそも目的が違う。

0370デフォルトの名無しさん

05/02/20 00:26:49

>>369
やはり目的の違いですか。
statとstrategyの違いみたいな感じ？

0371デフォルトの名無しさん

05/02/20 19:32:41

>>368
このスレくらい嫁
>>273-276

0372デフォルトの名無しさん

05/02/20 19:37:19

http://www.ogis-ri.co.jp/otc/hiroba/technical/JPLoP/DPforRDB.html
数少ない日本発デザインパターンのひとつ

0373デフォルトの名無しさん

05/02/21 14:21:06

デザインパターンF.A.Q.
http://www.hyuki.com/dp/dpfaq.html

天麩羅追加きぼん（次スレがあれば）

0374デフォルトの名無しさん

05/02/23 02:29:04

最近DQ8をやっていて思ったこと。
1.
「さまようよろい」は、戦闘中に「ホイミスライム」を呼びます。
「じごくのよろい」は、戦闘中に「ベホマスライム」を呼びます。

・・・あ、これってある意味"Abstract Factory"じゃね？

2.
新しい街にやってきた主人公達御一行。
まずは民家・店・井戸の中など、入れる建物に片っ端から訪れて、
中にあるツボやタルやタンスなどを物色します。

・・・あ、Visitorパターンじゃん！

デザインパターンを知ってると、こういう些細なことに対して
思わずにやっとなってしまいます。

0375デフォルトの名無しさん

05/02/23 17:45:56

>>374
真性ｦﾀ

0376デフォルトの名無しさん

05/02/23 19:50:20

可愛いあの子をObserve

0377デフォルトの名無しさん

05/02/23 20:55:47

キモい>>376を Two-Phase Termination

0378デフォルトの名無しさん

05/02/23 21:39:54

>>376 はストーカーパターン

0379デフォルトの名無しさん

05/02/23 23:00:01

>>378
アンチパターンだよね

0380デフォルトの名無しさん

05/02/23 23:48:06

>>377
だけど私はImmutable

0381デフォルトの名無しさん

05/02/24 15:32:14

そいつぁItrator。

0382デフォルトの名無しさん

05/02/25 02:15:53

>>381
×Itrator
○Iterator

0383デフォルトの名無しさん

05/03/02 23:33:07

短時間でデザインパターンの全貌をなんとなくつかむには何がオススメですか？
「まずはこの Web（本）を読め！」というものを1つだけ選んで教えてください。

0384デフォルトの名無しさん

05/03/02 23:51:47

全貌があるのか否かイマイチ疑問だが、結城のデザパタ入門に一通り
目を通した後でJakarta CommonsのコンポーネントをEclipseUMLへぶ
ち込んでクラス図を出力して眺めて読んで追って舐め回せ。

Jakarta Commonsのソースは超実践的にして超膨大なデザパタのサ
ンプル集だ。

0385デフォルトの名無しさん

05/03/03 00:17:49

>>383
GoF

0386デフォルトの名無しさん

05/03/03 00:31:45

>>383
「Eclipseプラグイン開発」 Erich Gamma, Kent Beck
Erich GammaがデザインパターンをEclipseアーキテクチャでどう利用
したか解説してくれる。実際にパターンが現場でどう使われているか
実感できる。ただ全貌がわかるわけではないけど。GoF読んで「ふ～ん、で、
それで?」とか思ったときに読むといいかも。

ちなみにKent Beckもなんか書いてるけど、
これは蛇足だからどうでもいい。

0387デフォルトの名無しさん

05/03/03 14:56:17

デザパタって何で賞賛されるんだ?

Templete MethodやFactory Methodのような
抽象クラスの作り方をアマのプログラマでも
やってきたんじゃないか？
煽りみたいな表現になってしまい、ｽﾏﾇ

0388デフォルトの名無しさん

05/03/03 15:22:50

手法に「名前を付けた」ことがデザパタの最大の功績。
手法自体はやってる人は昔からやっていること。

0389デフォルトの名無しさん

05/03/03 16:21:58

>>387
……馬鹿じゃないの？マジで。
一体どうしたらそんな発想が出てくるんだ？
デザパタをなんだと思ってるんだ。｢今まで誰も思いつかなかったオリジナリティあふれる設計｣か？

0390デフォルトの名無しさん

05/03/03 21:16:59

うぇあーお、やべーよ
おれはデザパタを読む前からテムプレートとかやてたーよ
おれってすげーよ

0391デフォルトの名無しさん

05/03/03 21:29:15

>387
セクハラって何で非難されるんだ?

女の尻触ったりシモネタ言ったり
女性に対するいたずらを一般人でも
やってきたんじゃないか？
煽りみたいな表現になってしまい、ｽﾏﾇ

0392デフォルトの名無しさん

05/03/03 23:15:23

>>390
貴方がやってきたテムプレートと、私がやってきたテンプレートは大なり小なりの違
いこそあれきっとどこかが違う。
だから、貴方が「ここはテムプレートな」と言い、私が「そうだな」と肯いても、出来上
がってみると思惑がズレてたりする。
そもそも、貴方がテムプレートと呼ぶやり方を、私は別の名で呼んでるかもしれない。
そうすると、前段の会話自体が成立しない事になる。

デザパタが何かを生み出したとしたら、それはcommonaltyなんじゃないかと俺は思う。

0393デフォルトの名無しさん

05/03/03 23:30:48

>>392
言う相手を間違えてない？
390は明らかに387に対する煽りか、きちがいだろ

0394デフォルトの名無しさん

05/03/04 00:17:00

>>393
そうか、そうかもな。

それじゃあ、public class 392 implements 390、て事にしとくｗ

0395デフォルトの名無しさん

05/03/04 12:40:44

暗黙知を形式知に変えることの重要性が分からない者には
何を言っても無駄。

0396デフォルトの名無しさん

05/03/04 14:30:51

>>390
>>373の17を嫁

0397デフォルトの名無しさん

05/03/04 14:56:13

>>388
そうですよね。
異様なまでに賛美されてるから
不思議に思ってしまって。

>>389
ひがみ根性ですね
もう少し国語の勉強しようね、僕

>>390
ばかでつね

>>391
ここはとってもつまらない
インターネッツですね

0398デフォルトの名無しさん

05/03/04 15:10:09

ANSIのC/C++のように規格化すればいいってか、くだらん。
案件にとりかかる前に仕様を統一しとけばｲｲだけだ。

0399デフォルトの名無しさん

05/03/04 15:14:47

言語の規格さえしっかりしていれば、それで十分。

0400デフォルトの名無しさん

05/03/04 15:31:48

シンタックス、イデォム、パターン

0401デフォルトの名無しさん

05/03/15 12:04:44

日経ソフトウエアでデザインパターンの連載が始まっていると聞いたのですが、
今までどんなパターンが解説されてきたのかを教えてください。

0402デフォルトの名無しさん

05/03/17 01:07:07

質問です。
interpreterパターンを使ってパーサを作っているのですが、
以下のような文法を扱う場合に、どのように構文解析すれば良いか分かりません。
構文<A>を読み込んだ時点では、その構文が<X>と<Y>のどちらに属するのか
分からないからです。
私が勉強した本(結城さんのデザインパターン入門)では、
「インタープリタパターンは、(E)BNF記法に忠実に従うべし」と書いてありましたが、
この場合、BNF記法に従って文法解析を行うことは可能なのでしょうか？

文法を <Root> ::= <A> <B> (<C> | <D>) と置き換えれば一応解析できるのですが、
この場合はBNF記法に忠実には従っていない気がします。

<Root> ::= <X> | <Y>
<X> ::= <A> <B> <C>
<Y> ::= <A> <B> <D>

0403デフォルトの名無しさん

05/03/17 01:55:47

RootNodeParse()で
SkipTokenを2回つかって、<A> <B> とすすんで、currentTokenで<C>または<D>をとってきて
XNodeParse()かYNodeParse()にとぶか（それともUnsupportでエラーにするか）をきめればいいのでは？

0404デフォルトの名無しさん

05/03/17 02:07:48

BNF は、文法の定義方法で、構文解析方法じゃないので、
「忠実に従う」といっても、プログラムの駆動が、
定義文をそのままトレースするという意味ではないんでは。

0405デフォルトの名無しさん

05/03/17 03:36:16

このへんはデザパタじゃなくて言語処理の話だな。

0406デフォルトの名無しさん

05/03/17 07:04:09

>>402
RootのBNF定義を変形するべしに1票。「BNFに忠実に」という意味は、BNFを変形してはいけないというわけではないと思う。

0407デフォルトの名無しさん

05/03/17 08:40:58

インタプリタパターンで普通にコードを書くと
最初ノードXのつもりで解析を始める
A B と順に解析を始める
C の解析に失敗する
Xの解析に失敗したと分かる
Rootの|が発動する
Yの解析が始まる
A B Dと解析が進む

ってなりそうだがなんないの？

0408デフォルトの名無しさん

05/03/17 10:24:23

BNFに忠実にってのは、「書いた文法定義をそれに対応するコードに
置き換えましょう」という意味であって、
「文法定義に拡張BNFを使ってはいけない」という意味ではないと思う。

0409デフォルトの名無しさん

05/03/17 12:40:10

>>402
俺、インタプリタパターン書いたとき
そういうBNFもちゃんと処理できたよ。
何で困ったのか教えてクリ

0410デフォルトの名無しさん

05/03/19 01:59:38

StrategyとかCommandとかそこらへんの「振る舞いをまるごと変更や持ち運び」
っていうパターンって、クロージャひとつあれば解決するよな

0411デフォルトの名無しさん

05/03/19 02:46:11

>>410
まぁ、クロージャは道具で、デザインパターンは工法だから、
問題なかろう。

0412デフォルトの名無しさん

05/03/19 04:00:19

ちょっとGoogってみたけど、「クロージャ」ってどうもよく意味がわからん。
「オブジェクト指向でない言語で、
　オブジェクトのように扱えるように作ったコードの集まり」
のような意味しか読み取れないが、それだと、
>>410 の言ってることとちょっとかみ合わない感じだし。

0413デフォルトの名無しさん

05/03/20 20:16:58

>>412
クロージャという言葉には色々な意味・用途がある。
構文解析が話題となっている時に出てくるクロージャといえば、
多分、"（その時点で考えうる）遷移状態全てからなる閉包"
を指しているんだろうな。

0414デフォルトの名無しさん

05/03/20 22:52:26

閉包とかいわれてもわけわからん。

ヘイホー、ヘイホー。

0415402

2005/03/21(月) 20:59:06

レス遅くなってすみません。
みなさんレスありがとうございます。
個人的に、>>407のロジックに興味を覚えました。シンプルですね。
論理式の評価の手順にそっくりです。

そんな>>407に質問なのですが、
「Xの解析に失敗したと分かる」ためには、どうすれば良いのでしょうか。
個人的に以下の案を考えたのですが、

　　1:Xの解析に失敗したことによって生じる例外をキャッチする
　　2:Expression#interpret() の返り値を論理値にして、
　　　解析に成功したら「真」、それ以外は「偽」を返すようにする

1は、別にこの処理はエラー処理ではないので、
例外の利用を前提とするのが大げさだと思います。
2は、既存のソースの大幅な改ざんが必要となる場合があります。

他に何か良い方法はありますでしょうか？

0416デフォルトの名無しさん

2005/03/21(月) 22:26:34

>>407じゃないけどScheme的解決法として、
そのままRootのYの直前の継続を呼び出すというのが簡単なんだけど、
Cとかの手続き型言語に言い換えればただのバックトラッキングということかな。
>>407の意見を聞いてみたいね。

0417407

2005/03/23(水) 00:24:45

色々説明しようかと思ったけど、面倒くさいので
http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/274.zip
こんなコードを書いてみた。勝手に使い回してかまわない。
つか、俺もデザインパターンは結城浩の本で勉強したよ。

SerialNode : BNFの、連続したノード
OrNode : BNFの、or( | )
EndNode : BNFの、末端のノード

これに繰り返しを表現するRepeatNodeや省略可能Nodeを追加すると
BNFのトレースが簡単になる。

解析されたBNF構文木全体にアクセスしたい時はVisitorかなんか、そういうので。

0418407

2005/03/23(水) 00:32:27

>>415
例外にすべきかエラーリターンにすべきかは俺には解らないが、
俺は、失敗したら、その旨を示す値を返すように設計したよ。
多分それが一番お手軽だと思う。
でも、例外にしても本質的に花にも変わらないと思う。

>>416
こういうの、バックトラックって言うのかな。
なんかよくわかんね。

まあ、俺はこのサンプルコードが俺の期待通りに動いたので、なんかちょっと嬉しい。

このサンプルコードは、
10進数か16進数とマッチするのを表現する、以下のBNFをコードに置き換えたもの。
num = d | h
d = ( "0" / "1" / ... / "9" ) "#"
h = ( "0" / "1" / ... / "9" / "a" / "b" / ... / "f" ) "%"

0419デフォルトの名無しさん

2005/03/23(水) 07:50:25

デザインパターンの前にオートマトンについて学習すべきでは?

0420407

2005/03/23(水) 08:34:20

オートマトンについて学んでいれば、417のコードは違ったものになっているってこと？
そうじゃなくて、字句解析にはオートマトンを使うべきだってこと？

0421デフォルトの名無しさん

2005/03/23(水) 14:29:59

1234#1234%
は
dに属するの？
dにもhにも属さないと判断するのが正しいのか

0422デフォルトの名無しさん

2005/03/24(木) 13:43:57

そもそもインタープリタパターンって構文解析が目的じゃないでしょ。
解析済みの結果に対してどう処理するかってもんじゃないの？

0423デフォルトの名無しさん

2005/04/10(日) 04:44:23

>>420
A　オートマトンって言ってみたかっただけ

あれ読んで、ためになったとかって奴、プログラマには向いてないよ。

0424デフォルトの名無しさん

2005/04/10(日) 19:00:51

オートマトン……ってか状態遷移は重要だと思うけど

0425デフォルトの名無しさん

2005/04/13(水) 12:38:22

>>423
低脳PGさんには、必要ない知識だな。

・Lex＆Yaccの字句解析＆文法解析
・制御系の開発
・ハードウェアの論理回路設計

なんかには必須だけどｗ

つか、釣り餌も、それに釣られてるのも、程度低いなぁ

0426デフォルトの名無しさん

2005/04/13(水) 12:54:51

ところで、「GoFのデザパタ本は入門書ではない。もっと詳しく知りたい人の本だ」
ってMartinFawlerさんが言ってるのを見つけたんだけど、皆さんはどう思いますか？

俺的には、経験積まないと共有知のありがたみなんて理解しようもないから、
GoF本だろうと結城本だろうと、ある程度進んでからやるべきだと考えてるけど。
(個人的学習経験としてそう思うし、また初心者に結城本教えるという無謀な試み(!)の経験で改めて実感したｗ

リファレンスはこのあたり
Swebok　http://www.martinfowler.com/bliki/Swebok.html

＞今月は IEEE による SWEBOK（ソフトウェアエンジニアリング知識体系）のレビュー月間である。
＞これは、我々の専門分野についての知識体系を定義しようという試みで、ライセンス化へ向けて
＞の土台となるものだ。
（中略）
＞さて、Swebok のどこがダメなのか？
（中略）
＞本の選出はひどくはなかった（GangOfFourを推薦図書にはリストアップしないよう私が警告したのだが）。
＞（GangOfFourはさらに理解を深めたい人用である。初心者用の「参考図書」ではない）

0427デフォルトの名無しさん

2005/04/13(水) 13:04:32

持っているの結城本だけど、初心者が丸暗記しそうなのが一番怖いと思う
そういう意味ではある程度経験積んだ人用の概念かもしんない

0428デフォルトの名無しさん

2005/04/13(水) 13:06:16

結城本はGoFパターンの雰囲気をわかりやすく伝えているのに対し
GoF本は個々のパターンの長所短所を分析しているような印象。

だから、デザパタ/OOP初心者に薦めるんだったら結城本。GoF本は薦めない。
>>426の初心者ってプログラミング初心者だよね？

0429デフォルトの名無しさん

2005/04/13(水) 13:46:19

初心者がGoF本を理解できるのなら、天才と呼んであげよう

0430デフォルトの名無しさん

2005/04/13(水) 15:47:54

>>429
天才と呼んでくれ。初心者だが、GoFの内容がスーッと頭に入ってきた。

0431デフォルトの名無しさん

2005/04/13(水) 15:49:57

>>429は早く天才と呼んであげるように

0432デフォルトの名無しさん

2005/04/13(水) 16:13:22

>>426
その訳文は、某所の超意訳だろｗ釣られたなｗ

ファウラーは、そのblogにはそんなこと書いてないよ。
http://www.martinfowler.com/bliki/Swebok.html
The choice of books it came up with wasn't awful - although I was alarmed that GangOfFour didn't make it to the recommended list.
(It's in the secondary 'further readings' but not in the primary 'Recommended References' section.)
「(Swebokに)載ってる本の選択はそんなに悪くなかった -- GoF本が推薦リストには載らなかったけど。
　(GoF本は、重要度が高い『お勧め参考文献』の章じゃなくて、重要度が一段低い『もっと詳しく知りたい人のための参考文献』の章にあったｗ)」

GoF本良いけど難解つうてんのはこっちだなｗ
http://www.martinfowler.com/bliki/GangOfFour.html

0433デフォルトの名無しさん

2005/04/13(水) 16:43:17

http://www.martinfowler.com/bliki/GangOfFour.html

＞漏れの汁限り、GoF本はこれまで出たOO設計本の中で最高っす。
＞つか、たぶんどんなタイプの設計の本と比べても、最高！！！
＞ソフトウェア業界にも、無茶苦茶影響与えてるし。まぁJava /.NETのライブラリなんて、
＞GoFが作ったプールの中でパチャパチャ泳いでるようなもんだｗ
＞
＞なーんて褒めてみたけど、決して読み易い本ではない罠。
＞OO設計の基本原則わかって、「OOえぇなぁ～♥」って感じるようになってから、初めて嫁。
＞そこらへん判ってからじゃないと、この本の真価を読み取るのは無理。つか無理して読んでも無駄。
＞つか、そこらへん判ってからなら、努力して読めば、努力に応じたごりやくの得られる良書っす。
＞
＞コード例はほとんどC＋＋だけど、C++判んないからって焦る必要はなっしんぐ。
＞コード例は、C++の判りにくい機能は使ってないから、C言語さえ理解できりゃ判るようになってるって。

0434デフォルトの名無しさん

2005/04/13(水) 16:45:43

>>428
プログラミング初心者、OO初心者、両方の意味っす。
結城本は、クリープを欠いたネスカフェって漢字。

0435デフォルトの名無しさん

2005/04/13(水) 17:41:17

>>433
それってファウラーの文章を翻訳したもの？
もしそうなら書いてる内容は２ちゃんねらと大してかわらないな。

何か言ってるようで何も言えてない。ていうか、要約すると３行
になるｗ

スゲー(・∀・)ｲｲ!!
でも、読み易くはない(´･ω･｀)ｼｮﾎﾞｰﾝ
コード例はC++だけどCが分かればダイジョウV

0436デフォルトの名無しさん

2005/04/13(水) 20:14:07

いや、ちゃねらー言葉にほんにゃくしただけだってばｗ

もうちょっとまともな訳でファウラー大先生のありがたい御託を読みたい方は、こちらへドゾー（他は多分に意訳が激しいけど、この項目はまとも）
　http://capsctrl.que.jp/kdmsnr/wiki/bliki/?GangOfFour

0437デフォルトの名無しさん

2005/04/13(水) 21:31:42

>>436
まともな翻訳でもやっぱり大したこと言ってない。
凄くいいけど読むには経験が要る。
サンプルはC++だけどCが読めれば大丈夫。
今度は２行で要約できちゃったよｗ

0438デフォルトの名無しさん

2005/04/13(水) 22:14:07

>>437
blogってふつー、そーゆーもんだろ。
もしかしておまいのblogは、受けを狙って書くのかｗ

つか、マーチンの追っかけやってるｱﾌｫもどうかと思うが、
脳みそが２ちゃんでいっぱいいっぱいの>>435-437みたいなのは論外の外だなｗ

0439デフォルトの名無しさん

2005/04/13(水) 22:16:52

つか、ここでレスしてる人って、マジ英語のblog読めないの？

それ、まずいよ。翻訳屋に騙されっぱなしじゃん。技術者としては、能力75%落ちって感じかｗ

0440429

2005/04/13(水) 22:33:36

遅くなってスマン
>>430
君は天才だ
馬鹿と紙一重だ

0441デフォルトの名無しさん

2005/04/13(水) 23:44:50

>>438
blog＝日記という意識ならそうかもね。
けれども、少しでも書評という意識があったとしたら、この人の
書評には読むべきところがないね。
まぁ、それだけのこと。俺が褒めなくても、他に褒めてくれる信
者を一杯持ってる人なんだから、どうでもいいんじゃね？

0442デフォルトの名無しさん

2005/04/14(木) 08:59:53

いやblogは日記だろ、リンク付きの
そこを否定は変だぞ

0443デフォルトの名無しさん

2005/04/14(木) 09:01:37

誰でも褒められりゃ少しはうれしいだろうけど、
blog ってかならずしも誰かに褒められるために書くわけじゃ無し。

0444デフォルトの名無しさん

2005/04/14(木) 10:30:00

まぁ、ﾌﾞﾛｶﾞｰは120％受け狙いで日記書くわけだがｗ

0445デフォルトの名無しさん

2005/04/14(木) 12:17:42

吉野家コピペとかって、多分最も受けた部類に入るんだろうけど、
書いた人間が狙ってたかどうかは・・・？

0446デフォルトの名無しさん

2005/04/14(木) 14:58:09

奈良のおばちゃんは、受け狙ってたわけではないが、
一部ではかなーり受けてる

0447デフォルトの名無しさん

2005/04/14(木) 17:01:21

ギャラリーを意識していない女の日記はギリギリ存在を許容できるが
ギャラリーを意識していないブログは存在自体が有害。
中身ないくせしてシャクレタ単語だけは入れたがるから、無駄に検索
に引っ掛かる。
読ませる気がないのなら、人目につかない場所でひっそりとやってほ
しいもんだ。

0448デフォルトの名無しさん

2005/04/14(木) 17:12:38

どうでもいいからデザパタについての話をしてほしい。

0449デフォルトの名無しさん

2005/04/14(木) 22:34:26

デザパタおんりーつうのはイマドキつらいもんがあるね。
ドメイン・パターンとか、いろいろ扱うべきテーマがあるでしょ

0450デフォルトの名無しさん

2005/04/15(金) 08:40:15

奈良のオバチャンは扱うべきテーマか？

0451デフォルトの名無しさん

2005/04/16(土) 18:10:43

Eriv Evansが Domain-Driven Design であげてる基本パターンは、
どうなんだろう？

頭が弱い人が見たら、あれ UMLとかOOの基本並べてるだけに見えちゃうんだろうなぁ。

0452デフォルトの名無しさん

2005/04/18(月) 06:44:06

今頃デザインパターン云々いってる奴　＝　今頃たまごっちに夢中になってる奴

0453デフォルトの名無しさん

2005/04/18(月) 08:39:08

バカはすぐ調子にのる

0454デフォルトの名無しさん

2005/04/19(火) 01:54:35

寒

0455402

2005/04/21(木) 01:22:25

以前、Interpreterパターンについて書き込みした人です。

本を書いた本人に聞いてみました。

>>402 のような場合では、BNFを変形するということで良いそうです。
文法どおりにコーディングすることが重要であって、
文法が変わらなければ、BNFを変形すること自体はオーケーだそうな。

0456デフォルトの名無しさん

2005/04/21(木) 11:44:53

良し悪しではなく、趣味の問題、最適化の問題じゃないか、と。
デザパタの話題とは丸きり関係ないじゃねぇか、と。

0457デフォルトの名無しさん

2005/04/25(月) 16:28:14

・再帰下降/LL文法でバックトラックするか、
・LR文法でトークン先読みして、当てはまるBNF式を選択
すりゃ解決・・・って言語処理系の教科書ネタだよな。

0458デフォルトの名無しさん

2005/04/27(水) 21:00:13

・状態がA、B、Cとあり、それぞれで振る舞いが変わる
・A、B、Cとも共通の変数を「たくさん」扱う
・振る舞いが変わると言っても、影響範囲は一つか二つの関数程度である

こんな時に、分かりやすくするための良い設計が有ったら教えて頂けないでしょうか

今やっているのは、stateパターンにして「たくさん」を一つの構造体にまとめ
各state->func()に引数として渡すやり方ですが、引数のためだけにまとめるのは、どうも妙な気がします。

0459デフォルトの名無しさん

2005/04/27(水) 21:14:54

こんな感じ？
派生クラスのdoProcessで状態別の違いを吸収。

class StateBase {
int val1, val2, val3, val4;
public:
virtual doProcess() = 0;
};

class StateA : public StateBase{ public: doProcess(){ 実装}:};
class StateB : public StateBase{ public: doProcess(){ 実装}:};
class StateC : public StateBase{ public: doProcess(){ 実装}: };

0460デフォルトの名無しさん

2005/04/27(水) 21:19:24

StateBaseが持ってる「たくさんの変数」はprotected:で。

0461デフォルトの名無しさん

2005/04/27(水) 21:20:15

あ、ごめん共通の変数ならstaticもつけなきゃだめだ。

0462458

2005/04/27(水) 21:24:36

>>459
申し訳ないです。そのやり方だと、val1～val4が
StateA、StateB、StateCでそれぞれ独立して存在してしまい
「共通の変数」では無くなってしまいまして。

val1～val4をStateBaseでstaticにするほどじゃないのが、悩みどころで困っています。

とはいえ例付きでのレス、ありがとうございます。

0463458

2005/04/27(水) 21:25:41

書いているうちに内容がかぶってしまいました、すいません。

0464デフォルトの名無しさん

2005/04/27(水) 23:14:07

>val1～val4をStateBaseでstaticにするほどじゃないのが、悩みどころで困っています。

Singletonでしか使えないな。ﾜﾗ

0465デフォルトの名無しさん

2005/04/27(水) 23:57:35

これ俺も良く似た状況に遭うけど難しいよな
クラスでの共通変数じゃなく、インスタンスのまとまり毎に扱いたい共通の変数な
464も言っているが、staticにしちゃうとSingletonでしか使えないし

0466デフォルトの名無しさん

2005/04/28(木) 00:38:49

その共通変数のまとまりを構造体なり、クラスなりにまとめて、
その「変数の塊クラス」のインスタンスを、それが必要なオブジェクトで共有させればいいんじゃないの？

0467デフォルトの名無しさん

2005/04/28(木) 00:41:20

> 引数のためだけにまとめるのは、どうも妙な気がします。

にループ

0468デフォルトの名無しさん

2005/04/28(木) 00:41:51

なんでメンバ変数がstaticだとシングルトン限定になるんだ？
普通に、インスタンスで共有できるんじゃないの？

0469デフォルトの名無しさん

2005/04/28(木) 00:55:25

>>468
Stateのクライアントとなるインスタンスが
2つ以上あるだけで破綻するから

0470デフォルトの名無しさん

2005/04/28(木) 01:52:12

>>466
俺も普通にそうしてる。
共有される変数を一つのオブジェクトとして扱うのは自然な事に
感じるんだが・・・・・・

0471デフォルトの名無しさん

2005/04/28(木) 02:05:39

でもそれって見事に実装の都合から設計しちゃってるよな

0472デフォルトの名無しさん

2005/04/28(木) 02:09:24

contextとかいう名前の変数にして引数で連れ回すか、
全体を統括するなんかクラスをもうけて連れ回さなくて済む
ようにするか。

0473デフォルトの名無しさん

2005/04/28(木) 07:43:17

stateパターンなら「共通の変数」は、
それを保持する為のクラスを作る。

で doProcess() の引数にする。

class Context {
public:
int val1, val2, val3, val4;
StateBase* currentState;
};
class StateBase {
public: virtual void doProcess( Context* ) const = 0;
};
class StateA : public StateBase {
public: void doProcess( Context* ) const;
};
class StateB : public StateBase {
public: void doProcess( Context* ) const;
};

staticなクラスメンバ( 本質的にグローバル変数 )なんて使うと、
「状態を持つもの」が2個3個と増えたときすげーこまる。

0474473

2005/04/28(木) 07:46:46

あれ？なんか、俺の周りだけ時空が遅れているようだ

0475デフォルトの名無しさん

2005/04/28(木) 09:49:08

stateオブジェクトの構築時にcontextを引数で渡してやれば
stateのメソッド呼び出しの時に渡してやる必要はないね。

0476デフォルトの名無しさん

2005/04/28(木) 12:31:29

stateオブジェクトやcontextオブジェクトの寿命管理が簡単で
コンテキスト毎にstateオブジェクトを生成・保持するコストが問題にならないなら
それもありだね。

0477デフォルトの名無しさん

2005/04/28(木) 13:17:10

>>473
pulicメンバ変数とか、無意味なgetter、setterの予感などの議論は置いておくとして、
メンバ変数を別クラスにまとめてしまうと、設計段階でのクラス分析が
希薄になったり、或いは元クラスが形骸化してしまう気がしちゃうねぇ…。

stateパターンは使いどころが多いだけに、まずいと思う。

やはり素直に構造体にするのがいい気がする。しかし確かに引数のためだけに
メンバ変数が構造体ひとつになるというのも、おかしな話ではあるなぁ。

0478デフォルトの名無しさん

2005/04/28(木) 13:17:31

Stateを、どっかのAPIの設計そのままにContextなどと呼ばずに、
一段抽象をかけるのが「パターン」というものだろうに。

ほんとに時間が止まってるスレだなｗ

0479デフォルトの名無しさん

2005/04/28(木) 13:20:19

>>477
・分析レベルのオブジェクトと
・設計レベルのオブジェクトを
区別して考えろ、と。

0480デフォルトの名無しさん

2005/04/28(木) 13:34:19

>>479
いやー俺はやはり、意味はなるべく残すべきだと思うよ。
特にこの場合、クラスに分ける意味が薄いし、その上分かりづらくなる。

0481デフォルトの名無しさん

2005/04/28(木) 13:40:36

分析レベルのオブジェクト：問題領域の概念を写像したもの
設計レベルのオブジェクト：上記問題を実装するためのオブジェクト

コーダーさんが悩む感覚はよく理解できるが、
瑣末な話だと感じる。

0482デフォルトの名無しさん

2005/04/28(木) 14:08:29

Stateパターン

┌────┐　　state　　　　　　　　　　　　1┌────┐
│Context. .│◇ ───────────┤State　　 │
├────┤　　　　　　　　　　　　　　　　　　├────┤
│Request()│　　　　　　　　　　　　　　　　　　│Handle() │
└────┘　　　　　　　　　　　　　　　　　　└──┬─┘
　(state.handle())　　　　　　　　　　　　　　　　　　　　 .△
　　　　　　　　　　　　┌────────────┼── …
　　　　　　　　　　　　│　　　　　　　　　　　　　　　　　 │
　　　　　　　　　┌─┴─────┐　　　┌───┴───┐
　　　　　　　　　│ConcreteStateA│　　　│ConcreteStateB│
　　　　　　　　　├───────┤　　　├───────┤
　　　　　　　　　│Handle()　　　 . . .│　　　│Handle()　　　 . . .│
　　　　　　　　　└───────┘　　　└───────┘

0483デフォルトの名無しさん

2005/04/28(木) 20:53:01

>>480
同意、分離前のクラスが無意味になるよな

0484デフォルトの名無しさん

2005/04/29(金) 03:57:18

AAでクラス図を表現した書き込みを初めて見た・・・

0485デフォルトの名無しさん

2005/04/29(金) 12:16:15

これからはッ
テキストォファイルの時代ィィィッ！

0486デフォルトの名無しさん

2005/04/29(金) 13:41:32

デザインパターン書いたときない

0487デフォルトの名無しさん

2005/04/29(金) 13:45:10

デザインパターンを語るとき
デザインパターン自体の継承関係も押さえておこう
そうすれば↑こいつらみたいにウンチク語ることができるよ
デザインパターン語る奴あんまカッコイイとおもわねー
おっちゃんが野球選手に対して「なにやってんだよ」と文句いっているのと一緒で

0488デフォルトの名無しさん

2005/04/29(金) 14:05:35

┌───┐
│ウンコ │
└───┘
　　　△
　　　│
┌─┴─┐
│>>487 │
└───┘

0489デフォルトの名無しさん

2005/04/29(金) 19:32:34

>>488
ﾜﾛｽ

0490デフォルトの名無しさん

2005/04/29(金) 21:07:15

デザインパターンって、結局クラス仕様の作り方のあんちょこなの？

0491デフォルトの名無しさん

2005/04/29(金) 22:46:48

結局ウンチクだろ、おやじ達の

おれは知っている・・・
人のソース見て
「なんだこれ　俺ならこうはしない」
といいつつ、いざ自分でやらせたら
同じことを人に言われているのを・・・

おまえらも、万人が必ず認めてくれる設計・パターンをもっと勉強してくれ
ホントにそんなもんが存在するのであればな

0492デフォルトの名無しさん

2005/04/30(土) 01:33:07

if(ソース != 自分のソース){
　cout << "なんだこれ　俺ならこうはしない";
}

0493デフォルトの名無しさん

2005/04/30(土) 02:14:32

>>492
ま、そういうことなんだな
みんながみんなお互いそう思っている

0494デフォルトの名無しさん

2005/04/30(土) 03:58:22

>490
そんな感じかな。
デザインパターンという考え方自体は、もっと広く定義されるものだけど。
例えば、カプセル化という考え方なんかも一種のデザインパターンと言えるな。
設計の仕方、プログラムの書き方に対する一般論。

割とみんなが知ってる事だけど、特定の呼び名が無いと話をするとき不便なわけ。
「この間のあのプログラムで使ったアレ、あんな感じで行こうか」みたいな言い方しか出来ない。
んで、教えるのにも手間がかかる。明文化されることの無い暗黙知だからね。
みんなが知ってる概念を明確な形で一般化して、呼び名をつけたわけだ。
共通言語として使えるように。

良くあるパターンに名をつける事が重要なのであって、優れてるかどうかは二の次。
パターンに名をつけ、明確にする事によって初めて、それが良いか悪いかの議論が可能になる。
デザインパターンを知らないと、デザインパターンを非難する事もできないわけ。

0495デフォルトの名無しさん

2005/04/30(土) 05:20:05

うちのプロジェクトメンバー間では「篠原パターン」が通用する

0496デフォルトの名無しさん

2005/04/30(土) 07:03:59

それならクラスの作り方だけじゃなくて普通のプログラムの記述のテクにだって
みんなが知っているパターンってあるじゃないそっちは分類したり名前付けたり
しなくてもやっていけてるんじゃないの？分類し名前を付けることに対して
価値を創出させたいがためとか？

0497デフォルトの名無しさん

2005/04/30(土) 07:07:53

>>495
ASURA に圧倒されるやつ？

0498デフォルトの名無しさん

2005/04/30(土) 08:11:59

あと、クラスのヒエラルキーに圧倒されるよりはデザインパターンの量は少ないけど
本にまとめられた以外にもこういうところがちょっと違うこういう風に役立つって
いくらでも増やしていけるからぐちゃぐちゃになる可能性もあるよね
デザインパターン自身はクラスのようなヒエラルキーが本質的にはないから
分類も恣意的になるしかないし

0499デフォルトの名無しさん

2005/04/30(土) 08:34:36

>>497
あれは規格外の部品をより集めてますから。

0500デフォルトの名無しさん

2005/04/30(土) 08:41:42

GWの午前3時～5時に暑く騙るキミ、最高！

0501デフォルトの名無しさん

2005/04/30(土) 08:52:25

>>497,499
「押井パターン」ってのもありそうだ

0502デフォルトの名無しさん

2005/04/30(土) 13:12:24

ASURAっつーのがわかんないが
家のメンバーではその「篠原」って言う奴が作ったパターンを使う事が多い
会議中に、煮詰まったら「じゃ、篠原パターンで・・・」というギャグも小岩井のたばこ臭い息と一緒に吐かれる

0503デフォルトの名無しさん

2005/04/30(土) 13:45:39

デザインパターンも言語仕様に取り入れるのはどうだろう
>>502さんのような場合

design pattern Shinohara (Koiwai, Tobacco) ;

とかで

0504デフォルトの名無しさん

2005/04/30(土) 13:47:21

必ず犬が出てくるワケね

0505デフォルトの名無しさん

2005/04/30(土) 13:53:12

>>503
タバコ臭くない日とかもあるので
design pattern Shinohara (Koiwai [, Tobacco]) ;
でどうだろう

0506デフォルトの名無しさん

2005/04/30(土) 13:55:55

単語が２つに分かれているのは気持ち悪いな

designpattern Shinohara(Koiwai [, Tobacco]);

0507デフォルトの名無しさん

2005/04/30(土) 20:46:37

うちのリーダーは「こないだのやつ」とか「あん時のやつ」とか平気で口にする。

俺はあんたの女房じゃねぇから、そんなんじゃわっかんねぇよ！！！ヽ(`Д´)ﾉｳﾜｧｧﾝ

0508デフォルトの名無しさん

2005/04/30(土) 21:08:19

>496
そういうのも広義では「デザインパターン」と呼ぶ。
GoFの提唱したあれらだけがデザインパターンと言うだけじゃない。
オブザーバーとかシングルトンとかも、GoF以前の名前が無い頃にも使ってただろ？
でも、名前がついた事でコミュニケーションが取りやすくなったわけ。

デザパにヒエラルキー的秩序が存在しないのは、数が足りないのがひとつ。
あと、秩序だてて分類する必要性が薄いってのがある。
クラス構造の補助として用いられる事を想定してるからね。
それと、言語によって構成が違うので、ガチガチの秩序を組んでしまうと相性の悪い言語が出てしまう。
増やしすぎると混沌とする、というのは同意。

>503
勿論、取り入れられる可能性はあると思う。
最近は言語自体に結構複雑なことまでさせる風潮があるしね。

>495
クラス名の命名と同じで、機能を表す名前を付けるべきだと思う。
みんなが理解できてるならまあ問題はないんだけど。

0509デフォルトの名無しさん

2005/04/30(土) 21:43:50

昔MVCってのがあったな

0510デフォルトの名無しさん

2005/04/30(土) 21:51:50

ここも珍パン自慰か

0511デフォルトの名無しさん

2005/04/30(土) 22:17:34

MVCは「機能」に着目したパターン

0512デフォルトの名無しさん

2005/04/30(土) 22:21:35

しょうがねぇなデタラメばっかで。マジレスしとくわ。

MVCはデザインパターンではなく、
フレームワークもしくはアーキテクチャ・パターンと認識されている。

0513デフォルトの名無しさん

2005/04/30(土) 22:31:17

>>512
パターンなんだから　どっちゃでもいいじゃん

0514デフォルトの名無しさん

2005/04/30(土) 22:34:26

Excelパターンの宣言をするだけでExcelと同機能のプログラムが作れたらいいなあ

0515デフォルトの名無しさん

2005/04/30(土) 22:35:49

それはフレームワークからだって無理。

0516デフォルトの名無しさん

2005/04/30(土) 22:36:00

つまり、「ああいうの作ってくれ」っていうと出来ちゃう奴か
いつまで経ってもやってこない、ドラえもんの21世紀じゃないとちょっと無理

0517デフォルトの名無しさん

2005/04/30(土) 22:37:44

社長になればできる！

0518デフォルトの名無しさん

2005/04/30(土) 22:38:38

>>514-515
おまえら、POIとかOLEとか文化オリエントの部品とか知らないとは痛いですよ

0519デフォルトの名無しさん

2005/04/30(土) 22:40:46

POIてJavaの？

0520デフォルトの名無しさん

2005/04/30(土) 22:41:09

OLEって
ttp://saizennsenn.hp.infoseek.co.jp/
これか

0521デフォルトの名無しさん

2005/04/30(土) 22:41:23

ツールだろそれ
おっちゃんは、もう２ｃｈ卒業した方がいいと思うんだけど

0522デフォルトの名無しさん

2005/04/30(土) 22:42:05

つーかなんでJavaの話になってんの？

0523デフォルトの名無しさん

2005/04/30(土) 22:42:04

ｶﾞﾝﾊﾞﾚチンパンジー

0524デフォルトの名無しさん

2005/04/30(土) 22:42:59

じゃ、POI
http://www.msec.ne.jp/poi/about/index.html

0525デフォルトの名無しさん

2005/04/30(土) 22:43:32

そんなのより
D言語やC言語　今知らない方がまずいと思う
POIなんて実務じゃつかわね-よなー
ばかじゃね？

0526デフォルトの名無しさん

2005/04/30(土) 22:44:03

珍パンジィ・ガ・ン・バ！！！

0527デフォルトの名無しさん

2005/04/30(土) 22:44:32

D言語は実務じゃ使わねーだろｗ

0528デフォルトの名無しさん

2005/04/30(土) 22:45:33

珍パンの好みの言語は CとD（w、と。

C++と書けないところにレガシー爺を感じるなｗ

0529デフォルトの名無しさん

2005/04/30(土) 22:46:19

文化オリエントでググルとちょっとヤバゲなページにでちゃった

0530デフォルトの名無しさん

2005/04/30(土) 22:47:35

珍パンは、OLEもOCXも知らないレガシーCOBOLer

0531デフォルトの名無しさん

2005/04/30(土) 22:50:50

Dを笑う奴は
もう気力の無くなったオヤジたちと思う

0532デフォルトの名無しさん

2005/04/30(土) 22:51:32

言うに事欠いて「Excel」出すとは、
事務やサンの下請けVBA厨房かｗ

普通使わねぇ～よ、Excelなんて。

0533デフォルトの名無しさん

2005/04/30(土) 22:51:53

AってないよねBときてCそしてDか

0534デフォルトの名無しさん

2005/04/30(土) 22:51:55

OLEもOCXも知らない？
そっちの方が今でこそレガシーだろが
COBOLは殿堂入りした

0535デフォルトの名無しさん

2005/04/30(土) 22:52:16

珍パンはDが大好き、と。

C++/C# と書けないところにレガシー爺を感じるなｗ

0536デフォルトの名無しさん

2005/04/30(土) 22:53:12

まあまあ
１００年後はみんなレガシーなんだからさ

0537デフォルトの名無しさん

2005/04/30(土) 22:53:19

>>珍パンは、OLEもOCXも知らないレガシーCOBOLer
あーもうすぐオヤジ領域に入ってる年齢だなぁ

0538デフォルトの名無しさん

2005/04/30(土) 22:53:34

-----------------------------------------------
　　チンパンジーが出没中です。。。

　　　※一般の方は生暖かい目で見守ってやって下さい。
　　　　　　　　　　　　　　　　　　　　　　　　　(霊長類研究所)
-----------------------------------------------

0539デフォルトの名無しさん

2005/04/30(土) 22:56:39

>珍パンはDが大好き、と。
>C++/C# と書けないところにレガシー爺を感じるなｗ

勘違いだな
明らかにGさんはあなた
C++/C#やるよりもJavaでしょ？
Cは必要

Dの熱さに心奪われない奴は年齢いってるんですね

0540デフォルトの名無しさん

2005/04/30(土) 22:58:26

まぁ、JREのバージョン切替方法すら知らない珍パンが、
ハッタリ打っても痛いだけだ

0541デフォルトの名無しさん

2005/04/30(土) 22:59:12

大漁ですね。

0542デフォルトの名無しさん

2005/04/30(土) 22:59:58

>>540
＞まぁ、JREのバージョン切替方法すら知らない
なんだよそれ
おまえが昨日知って得意になってるだけじゃないのか？

0543デフォルトの名無しさん

2005/04/30(土) 23:00:46

２ちゃん常駐がExcel遣いとはｗｗｗｗ
加齢臭とウンコ臭を感じるなｗ

0544デフォルトの名無しさん

2005/04/30(土) 23:02:27

Excel言ったのはそっちじゃないの？
それと　勘違いしているようだが
おじさんたちよりもわかいよね俺　多分

0545一般人

2005/04/30(土) 23:03:52

デザパタスレが盛り上がってるので開いたら、

>514 名前：デフォルトの名無しさん [sage] 投稿日： 2005/04/30(土) 22:34:26
>
>Excelパターンの宣言をするだけでExcelと同機能のプログラムが作れたらいいなあ

キモイ

0546デフォルトの名無しさん

2005/04/30(土) 23:04:38

Excelのような素晴らしいプログラムを作ってから言って欲しい

0547一般人

2005/04/30(土) 23:05:46

バカは放置しておくべきだと思う。
相手にするとスレつぶされるだけだから。

それより、そろそろ Domain-Driven Designのスレ立てないか？
みんな読み進んでるみたいだし。

0548デフォルトの名無しさん

2005/04/30(土) 23:07:20

>>547
立てて

0549デフォルトの名無しさん

2005/04/30(土) 23:15:53

>>547
このスレでそんなん書いたら潰れるの目に見えてるだろ？
こそっと立てとけばいいんだよ。
そうすりゃ分かる奴だけがこそっと寄ってくるんだから。

0550デフォルトの名無しさん

2005/04/30(土) 23:21:02

Domain-Driven Designのスレだろ？潰れないだろ

0551デフォルトの名無しさん

2005/05/01(日) 00:56:06

また来たよ

なんか書けよ

0552デフォルトの名無しさん

2005/05/01(日) 02:25:08

…えーと、PoEAAの日本語訳好評（？）発売中です。
全部読んでも禿あがることはないと思われるので買ってね。

0553デフォルトの名無しさん

2005/05/01(日) 02:27:45

ドメイン・モデル貧血症(不足症)　では Transaction Scriptをヤリダマに上げてるのに、
PoEAAでは、ドメイン・モデルと制御が分離したようなパターンを集めてるのね。
マーちんは二枚舌なのか？

0554デフォルトの名無しさん

2005/05/01(日) 08:47:31

著作権が

0555デフォルトの名無しさん

2005/05/01(日) 09:52:06

デザインパターンにしてもフレームワークにしてもドメインモデルにしても
どしてOOは蘊蓄の山になりやすいのですか？蘊蓄の階層構造がウザイ

0556デフォルトの名無しさん

2005/05/01(日) 11:01:33

Dおもしろいけど、実務で使うのはアグレッシブすぎ。
言語やライブラリの仕様まだ流動的だし、コンパイラも枯れてない。

趣味用に使うのにはかなりおもろいよね。

0557デフォルトの名無しさん

2005/05/01(日) 12:34:32

おまえ、エディタの背景「黒」にしてるだろ

0558デフォルトの名無しさん

2005/05/01(日) 12:38:35

エディタの背景は黒以外は使わない

0559デフォルトの名無しさん

2005/05/01(日) 12:54:08

あーやっぱそういう嗜好か・・・
否定はしないが

0560デフォルトの名無しさん

2005/05/01(日) 12:57:08

>>557-559
キモイ。よそでやれ

0561デフォルトの名無しさん

2005/05/01(日) 13:05:00

>>560
デザインパターンの話だと気付かないオバカサン発見

0562デフォルトの名無しさん

2005/05/01(日) 13:13:04

>>561
キモイ。よそでやれ

0563デフォルトの名無しさん

2005/05/01(日) 17:55:39

ちなみにエディタ上に表示される文字もとうぜん黒だ。

0564デフォルトの名無しさん

2005/05/01(日) 17:59:36

選択しね-と見えないのか

よっぽど後ろから見られるのがいやなんだなぁ・・・
自分のソースに自信持てよ

0565デフォルトの名無しさん

2005/05/01(日) 18:03:40

========================================================================
エクセル・クローンを作るのが究極の仕事だと思ってるチンパンジーが降臨中
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(霊長類研)
========================================================================

OpenOfficeかJustSystemかMicrosoftか逝けって。
OOだったらヒエラルキー・ブラウザ (iTunes インタフェースのアレ)とかの方が、
まだ食いつきがいいぞ。

0566デフォルトの名無しさん

2005/05/01(日) 18:06:10

>>565
それ笑えん。

ユーザ企業の情報システム部門員とか、Webサイト担当者レベルだと、
SI案件の打ち合わせ中に「Webブラウザで使えるAccessみたいな万能開発環境を、まず作れ」
とか言い出すｱﾌｫが、一時期居たんだよな

0567デフォルトの名無しさん

2005/05/01(日) 18:09:47

奴らは、COBOL流の静的なワイアード・ロジックを何千万行も書くのが仕事だと思ってるから、
MS Excel開発部隊と、己の能力が、月とスッポンほどにも離れてる事に気付いていないんだよ。

多分、COBOLで何億Stepも書いたらExcelが出来ると思ってるｗ

それがCOBOLerクオリティｗｗｗ

0568デフォルトの名無しさん

2005/05/01(日) 18:28:23

ExcelをObjectiveCOBOLでか！

0569デフォルトの名無しさん

2005/05/01(日) 18:31:58

COBOL 詳しく知らないんだけど、なんか越えられない壁でもあるの？

0570デフォルトの名無しさん

2005/05/01(日) 18:33:26

て言うかオマイら全員に言いたい。
書類はワープロで作れ。なんでオマイらときたら揃いも揃ってExcelで
書類を作るんだ？ちゃんとWordもインストールされてるだろ？

0571デフォルトの名無しさん

2005/05/01(日) 18:34:45

Excel遣いﾃﾗﾜﾛｽ

0572デフォルトの名無しさん

2005/05/01(日) 18:37:20

>>567
いやマジ、WinServer 何千万行だけど、
ウチのシステムは2000万行とかいう
わけのわからんプライド持ってる業界関係者は多いｗ

0573デフォルトの名無しさん

2005/05/01(日) 19:30:55

ObjectiveCOBOL
ttp://www.aboutlegacycoding.com/default.htm?AURL=%2FArticles%2FV%2FV60101%2Easp

0574デフォルトの名無しさん

2005/05/01(日) 19:58:54

学生さん乙。
業界人なら、OO Cobolとか Cobol 2003 という名前を
どっかで聞いた事があるだろう。誰も触りたがらないがｗ

0575デフォルトの名無しさん

2005/05/01(日) 20:02:07

スレ違い。cobolスレでやれ。
　http://www.cobol.gr.jp/knowledge/next_standard.html

0576デフォルトの名無しさん

2005/05/02(月) 03:34:43

ちょっとだけ、かじり中...

書いてあるとおりに、解釈するしかないのだろう、けど
"interface"というのをどう理解するか、というのが
ヤマなのかな、のような予感 > GoF本

0577デフォルトの名無しさん

2005/05/02(月) 19:27:04

仕様もない

0578デフォルトの名無しさん

2005/05/02(月) 22:42:09

読む前にインターフェースの有用性を知った方がいいかも

0579デフォルトの名無しさん

2005/05/03(火) 18:19:55

デザインパターンは、『よく見かける構造に名前を付けてみました』程度の認識で良いの？

0580デフォルトの名無しさん

2005/05/03(火) 19:30:54

>>579
基本的にはそうです
デザパタの発明と命名が同じタイミングで行われているものは稀
いままで存在していたやり方に名前付けただけ
それ以降（デザパタというものが認知されたあと）に出てきた奴は、発表と同時に命名されているものもある
誰が管理しているのかは不明
通常、命名に人の名前は付けないが
どこかの会社には「篠原パターン」で通用する

0581デフォルトの名無しさん

2005/05/03(火) 19:54:15

どうして、ここまでスラスラと
知ってるフリしちゃうのかｗ

0582デフォルトの名無しさん

2005/05/03(火) 19:57:22

>>580
＞それ以降（デザパタというものが認知されたあと）に出てきた奴は、発表と同時に命名されているものもある

このあたりに妙な電波を感じまする

0583デフォルトの名無しさん

2005/05/03(火) 20:10:15

>>581
なにがどうあれなのか書かないとハッタリと思われますよあんたも

0584デフォルトの名無しさん

2005/05/03(火) 20:12:32

あれだろ、言葉尻とらえてどーのこーのってやつじゃない？
ほっとけばいい

0585デフォルトの名無しさん

2005/05/03(火) 20:16:06

どうしてそこまで高飛車に
説明を要求するのやらｗ

下々のすることは、理解できないでおじゃるｗ

0586デフォルトの名無しさん

2005/05/03(火) 20:22:10

ID とかコテとかないと、誰が誰だか分からん

0587デフォルトの名無しさん

2005/05/03(火) 20:48:54

＞下々のすることは、
おめーがいちばん高飛車だ

0588デフォルトの名無しさん

2005/05/03(火) 21:12:57

蘊　蓄　厨　大　漁

0589デフォルトの名無しさん

2005/05/03(火) 21:28:28

釣られ気分でロケンロール

0590デフォルトの名無しさん

2005/05/03(火) 21:37:17

はやく、書けよなんか

0591デフォルトの名無しさん

2005/05/04(水) 19:45:28

スタブ・パターン

目的：
　場が白けた時に、次の発言をする前になにか緩衝材のようなものを入れておきたい。
解決方法：
　>>591参照
関連パターン：
　釣りパターン、Idiotパターン

0592デフォルトの名無しさん

2005/05/04(水) 20:20:59

みんな絡飯ィィ

0593デフォルトの名無しさん

2005/05/04(水) 20:35:09

Idiotパターン

目的：
　よくわからないけど、なにか言い返したい時に使う
解決方法：
　>>592
関連パターン：
　釣りパターン、スタブ・パターン

0594デフォルトの名無しさん

2005/05/06(金) 23:16:43

スルー・パターン

目的：
　スルー
解決方法：
　スルー
関連パターン：
　スルー

0595デフォルトの名無しさん

2005/05/07(土) 00:19:21

ageパターン

目的：
　「ぼくちんむかついた。もう相手してやんない。でも、無視されるとやだなぁ」
解決方法：
　>>594
関連パターン：
　荒しパターン、idiotパターン、潜水艦パターン

0596デフォルトの名無しさん

2005/05/07(土) 09:58:21

「ファンクタ」とか、「～ファクトリ」とか、「スケルトン」とか
そういうタームを聞くと生理的にムカツクんですが、俺だけでしょうか？
特に語尾に「ー」が入っていない日本語を見るとムカつきがダブルになります。
異常でしょうか？
あと、"Modern C++ Design"読んでいると、まるでそいつらのデザインパターン
が一般的かのように、身勝手なタームを既知のものとして使用しているのが
さらにムカつきます。

0597デフォルトの名無しさん

2005/05/07(土) 10:08:57

>>596
自分が能なしなのを人のせいにするな。

0598デフォルトの名無しさん

2005/05/07(土) 10:26:25

「スケルトンー」とか？

0599デフォルトの名無しさん

2005/05/07(土) 10:37:20

>>598
それ、もっとムカツク。

0600デフォルトの名無しさん

2005/05/07(土) 10:40:45

それにしても「～ファクトリ」はムカツクよ。なにがファクトリだよ。
なんかを生産するから「ファクトリ」ってそれ小学生がしそうな抽象だよ。
「工場」だよ工場。「ばかかおまえ」っていってやりたい。
あーーーーむかつく。せめて「ファクトリー」にしてくれまじむかつくから。

0601デフォルトの名無しさん

2005/05/07(土) 10:42:43

>>596
＞特に語尾に「ー」が入っていない日本語を見ると

「やだー、まじー、ちょームカつくー」

……女子高生の今の言葉使いわかんないや
とりあえず、どちらにしても、こんな言葉使いはもっとムカつく

0602デフォルトの名無しさん

2005/05/07(土) 10:44:05

って言うか、機械・電子・情報系の分野だと、語尾の「ー」は省略されて書かれる
それにしては、読むときにはばっちり「ー」が入るんだけどな

0603デフォルトの名無しさん

2005/05/07(土) 10:52:04

new → ニュ

0604デフォルトの名無しさん

2005/05/07(土) 10:58:35

>>600
そんな事言って、本当はデザパタがさっぱり理解できないだけだろ？
俺の周りでデザパタに文句言ってる香具師は、おしなべてデザパタが
さっぱり分からない香具師ばかりだぞ。

0605デフォルトの名無しさん

2005/05/07(土) 11:24:18

>>596
別に。コンピューターとかサーバーとかかかれているとちょっとむかつくけどね。
そんなに嫌なら、和訳されたものなんて読まなければいいのに。
俺は英語分からないから、翻訳者によって違う単語とかに翻訳されてようと、読むときに脳内変換してるから。

>そういうタームを聞くと生理的に

のそこの「ターム」とかいう英単語を、文章とか会話とかに無意味に織り交ぜたがるやつの方がもっとむかつくかな。

0606デフォルトの名無しさん

2005/05/07(土) 12:11:24

>>602
> それにしては、読むときにはばっちり「ー」が入るんだけどな
俺はそのまま「ー」省いて読むけどなぁ。つか伸ばして話してる人が周りにいない。

ところで、ここで聞くのが適切かどうか分かんないんだけど、
アーキテクチャ・パターンの話をしているスレはどっかない？

0607デフォルトの名無しさん

2005/05/07(土) 12:15:42

俺が訳書出すときがあったら、
ファンクタ→ファンクタァ
ファクトリ→ファクトリィ
コンパイラ→コンパイラァ
に訂正してやるから覚えてろ。

0608デフォルトの名無しさん

2005/05/07(土) 12:42:43

単語末の「ー」を省略するのは、
国内への影響力の大きい
電気通信学会の約束事と聞く。

つか英語で論文書けよｗ

0609デフォルトの名無しさん

2005/05/07(土) 13:13:54

今デザパタを勉強中ですが、ちょっと疑問に感じて来たことがあります。

言語設計者が意図をしていないトリッキーなテンプレートの使い方が多く
見受けられます。一般的には可読性や保守性の意味でよろしくないコードの
ように感じるんですが、その辺どう考えますか？

実際現場で、チームに所属してデザパタ流コーディングをしている方、
デザパタのトレーニングを積んでいない同僚の方がいると色々と問題
があると思うのですが、その辺どうでしょう？

0610デフォルトの名無しさん

2005/05/07(土) 13:42:11

> 言語設計者が意図をしていないトリッキーなテンプレートの使い方が多く
は？

0611デフォルトの名無しさん

2005/05/07(土) 18:17:53

＞デザパタ流コーディング

ははは。

0612デフォルトの名無しさん

2005/05/07(土) 18:49:02

ゴールデンウィーク、春真っ盛り。

0613デフォルトの名無しさん

2005/05/07(土) 19:31:17

デザパタって言葉を初めて知った方でしょうか

デザパタは、『自分のコードに適応するためにある』のではなく、
『自分のコードと各パターンのコードが偶然一致した事にあとから気付いて自己満悦する』為にあります

……パターンごとの設計方針は憶えておいて損はないですが
っていうか設計方針を飛ばしてクラス構造だけを憶える輩が多いような肝抹

0614デフォルトの名無しさん

2005/05/07(土) 19:43:10

ゴミ屑レスUzzzzzzzzzzeeeeeeeeeeeee

0615デフォルトの名無しさん

2005/05/07(土) 19:50:18

>>609
テンプレートメソッドの話じゃないよなあ。
もしかしてC++のやつ？

0616デフォルトの名無しさん

2005/05/08(日) 04:43:54

>>609
俺もGoF本読んだときそう感じた。
かなりトリッキーだよね。
これでオブジェクト指向とか再利用って言葉を聞くと「んん？」って思う。

0617デフォルトの名無しさん

2005/05/08(日) 06:10:23

609=616

0618デフォルトの名無しさん

2005/05/08(日) 09:30:46

そう思うのは表面をなめようとするだけだからだね。

オブジェクト指向とか再利用を考えていくとデザイン
パターンが見えてくるわけで、オブジェクト指向がま
ともに分かってないやつや汎用性のないゴミみた
いなプログラムしか組めないやつが本見てデザイ
ンパターンを使おうとしてもトリッキーと感じるだろうね。
ただの猿まねにすぎないから。

0619デフォルトの名無しさん

2005/05/08(日) 10:42:45

>>618
>オブジェクト指向とか再利用を考えていくとデザインパターンが見えてくるわけで
こないよ。
こんなトリッキーなコードが見えてくるわけないじゃん。
デザインパターンを使って組もうとすれば必ずGoF本の強制暗記を求められるよ。
もう、信者が聖書読ませようと必死過ぎなどっかの宗教とそっくりだよ。

ここのやつらもSTLのスレにいる奴等とダブルだろ？
～知らない＝レベル低い
って思考がそっくりだぜｗ
そもそもさ、デザパタって前提になる知識が多すぎて普及してねーだろｗ

デザパタにしてもテンプレートにしても、オブジェクト指向が理解できないことを
知識で隠すために必死で覚えてるとしか思えない。

0620デフォルトの名無しさん

2005/05/08(日) 10:51:01

カワイソウな人だな。

わかんなきゃ、来なきゃいいのにｗ

0621デフォルトの名無しさん

2005/05/08(日) 10:52:55

>>620
悪いけど、俺、転職多いほうだけど、
職場でデザパタ使ってるところなんてみたこと無いやｗ

0622デフォルトの名無しさん

2005/05/08(日) 10:57:40

レベルが低いのですね。かわいそうに。

0623デフォルトの名無しさん

2005/05/08(日) 10:59:14

>>622
いま、松○にいるけどそんな部署は無いと言いきれるぞ。

0624デフォルトの名無しさん

2005/05/08(日) 11:12:42

金融・通信系COBOL臭いな

0625デフォルトの名無しさん

2005/05/08(日) 11:14:33

>>624
COBOLはさすがにみたことない。

0626デフォルトの名無しさん

2005/05/08(日) 11:19:56

元金融・通信・流通系COBOLerが仕切ってる
ダメ現場の臭いがする

0627デフォルトの名無しさん

2005/05/08(日) 11:21:22

ここが笑い所ですよ

　　「悪いけど、俺、転職多いほうだけど、」

転職し過ぎ（・∀・）ﾖｸﾅｲ

0628デフォルトの名無しさん

2005/05/08(日) 11:21:40

後学のために聞きたいのだけど、
トリッキーなコードってどういうの？例をプリーズ。

0629デフォルトの名無しさん

2005/05/08(日) 11:27:00

GoFの何ページでしょうね

0630デフォルトの名無しさん

2005/05/08(日) 11:27:25

>>628
GoF本みればすぐでてくる。

0631デフォルトの名無しさん

2005/05/08(日) 11:29:30

>>630は、GoF本すら持ってない予感

0632デフォルトの名無しさん

2005/05/08(日) 11:29:31

>>629
そういうのはやだよ。
だって何ページかいうとデザパタを一つ一つ取り出して
どうアレなのか君と議論するんでしょ？

0633デフォルトの名無しさん

2005/05/08(日) 11:30:49

>>632は、街でいきなり他人に絡むタイプ

0634デフォルトの名無しさん

2005/05/08(日) 11:37:54

実装の仕方は言語や何をしたいかによって
変わってくると思うのだが。

0635デフォルトの名無しさん

2005/05/08(日) 11:42:46

GoF本が出たのはたったの10年前なんだから
まだ普及していないところがあっても別におかしくないよね。

0636デフォルトの名無しさん

2005/05/08(日) 11:46:03

何かというとコボルバカにするのなｗ
デザパタ？ﾌﾟとか言われてんのになw

0637デフォルトの名無しさん

2005/05/08(日) 11:50:29

＝＝＝＝＝＝＝＝＝＝＝＝＝下らない雑談はここまで＝＝＝＝＝＝＝＝＝＝＝＝＝

0638デフォルトの名無しさん

2005/05/08(日) 11:59:48

http://dhcp255-146.tamatele.ne.jp/
ｗｗｗｗｗｗｗｗｗｗｗｗうはっｗｗｗっｗｗｗｗｗｗｗｗｗｗｗｗ
うぇｗｗｗうはっｗｗｗｗｗｗうはっｗｗｗ
ｗｗｗｗｗｗうはっｗｗｗｗｗｗｗｗｗ
おｋｗｗｗ

0639デフォルトの名無しさん

2005/05/08(日) 12:04:11

￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣｣
―――――――――――――‐┬┘
　　　　　　　　　　　　　　　　　 |
　　　　＿＿＿＿.＿＿＿＿　　 |
　　　　　|　　　　 | 　　　　|　　 |
　　　　　|　　　　 | ∧＿∧　|　　 |
　　　　　|　　　　 |（　´∀｀）つミ |
　　　　　|　　　　 |/ ⊃　ﾉ　|　　 | 　GoF本
　　　　￣￣￣￣'￣￣￣￣　　 |
　　　　　　　　　　　　　　　　　|
　　　　　　　　　　　　　　　　　　いらねｗ

0640デフォルトの名無しさん

2005/05/08(日) 12:20:51

ものを否定するならある程度の根拠を示すべし。
根拠を示したら反論が来ることを覚悟すべし。
反論には議論で応じるべし。
議論が嫌なら沈黙するよろし。

0641デフォルトの名無しさん

2005/05/08(日) 12:23:04

>>640
デザパタが大して普及していない現状について

0642デフォルトの名無しさん

2005/05/08(日) 12:40:39

＝＝＝＝＝＝＝＝＝＝＝＝＝下らない雑談はここまで＝＝＝＝＝＝＝＝＝＝＝＝＝

0643618

2005/05/08(日) 16:33:39

>>619
>こんなトリッキーなコードが見えてくるわけないじゃん。

だれもコードの話してないけど。

>ここのやつらもSTLのスレにいる奴等とダブルだろ？

俺は違うけど。STLって何だ？

>そもそもさ、デザパタって前提になる知識が多すぎて普及してねーだろｗ

オブジェクト指向を理解しているかどうかだけ。

>デザパタにしてもテンプレートにしても、オブジェクト指向が理解できないことを
>知識で隠すために必死で覚えてるとしか思えない。

だからそういうのを、基本を理解せずに猿まねしているだけだって言ってるじゃん。
オブジェクト指向が理解できないことを知識で隠すために必死で覚えるんじゃなくて、
まずはオブジェクト指向を理解しろよ。
そうしないでデザインパターンの本だけ見たってお前の言うように理解できないだろ。

0644デフォルトの名無しさん

2005/05/08(日) 16:39:18

>>643
ハイハイｗ

0645デフォルトの名無しさん

2005/05/08(日) 17:01:50

そういうこと、
たぶんそんなもん暗記している奴なんていないと思うよ

619は経験少ないくせにあれこれいちゃもんつけているだけだと思う

0646デフォルトの名無しさん

2005/05/08(日) 17:08:26

>>645
もうプログラマ初めて10年になりますが、
デザインパターンなんて使ったことがないのですが
これから爆発的に普及する見込みはあるのでしょうか？

0647デフォルトの名無しさん

2005/05/08(日) 17:19:15

デザインパターンはソフトウェア業界が発見した銀の弾丸です。
これさえ覚えればどんな問題も解決可能です。
まだ覚えてない人は急いで覚えましょう。

0648デフォルトの名無しさん

2005/05/08(日) 17:36:09

BOOSTサイトのテストコードの引用だけど

typedef boost::make_recursive_variant<int,string,vector <boost::recursive_variant_> > var_t;
vector<var_t> va0;
va0.push_back("hoge");
va0.push_back(30);

vector<var_t> va1;
va1.push_back(123);
val.push_back("xxx");

va0.push_back(va1);
va0.push_back(va0);
val_t = va0;

apply_visitor(vector_printer(),v);

ビジター、リーフ構造はデザパタ、variantはタイプリスト使用、
世の中どんどん便利になるね。

0649デフォルトの名無しさん

2005/05/08(日) 17:44:49

>>648
>typedef boost::make_recursive_variant<int,string,vector <boost::recursive_variant_> > var_t;
こんなコードを書かなきゃならん時点で不安を覚える俺は優秀だと思う。

0650デフォルトの名無しさん

2005/05/08(日) 18:05:07

>>649
単なる慣れの問題。

0651デフォルトの名無しさん

2005/05/08(日) 18:11:55

>>650
可読性とはなんぞや？

0652デフォルトの名無しさん

2005/05/08(日) 18:16:58

>>651
単なる慣れの問題。

0653デフォルトの名無しさん

2005/05/08(日) 18:43:37

どうでも良いんだけどさ、

======

先生「では今から授業始めますよー」
生徒Ａ「はーい」
生徒Ｂ「はーい」
生徒Ｃ「はーい」

======

こんなありふれた事を、「Observer パターン」って言うと途端に拒絶反応しめす奴が居るんだが、何とかならんか？

0654デフォルトの名無しさん

2005/05/08(日) 18:47:13

ありふれたことにわざわざ名前つけるからだろ？名前を付けるというのは権威化だからね

0655デフォルトの名無しさん

2005/05/08(日) 19:00:33

>>653
そういう香具師は、どんな事にでも目くじら立てたがるだけの、中身が
空っぽの香具師だから、放置に限る。

0656デフォルトの名無しさん

2005/05/08(日) 19:05:39

｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
し　

0657デフォルトの名無しさん

2005/05/08(日) 19:06:23

＝＝＝＝＝＝＝＝＝＝＝＝＝ここまで、キチガイの脳内会話＝＝＝＝＝＝＝＝＝＝＝＝＝

0658デフォルトの名無しさん

2005/05/08(日) 19:12:53

キ○ガイって誰のことを指すの？

0659デフォルトの名無しさん

2005/05/08(日) 19:21:17

>>646
デザインパターンに「使う」と言う動詞は無い
10年もやっててその理解度は何だ！
おまえ、もっとしっかり勉強すれ

>>647の認識は間違っている
そんなに密にならなくてもいいと俺は思う

0660デフォルトの名無しさん

2005/05/08(日) 19:22:48

>>659
君も
～知らない＝レベル低い
とかいうのを展開するわけね。

0661デフォルトの名無しさん

2005/05/08(日) 19:26:09

>>660
そういうのを直感で判断するのは良くない
ただ、知っていたほうが人生が僅かに豊かになるだけだ

0662デフォルトの名無しさん

2005/05/08(日) 19:26:44

っていうかほんの僅かだけ。超微妙。毛穴くらいの大きさで

0663デフォルトの名無しさん

2005/05/08(日) 20:48:47

＝＝＝＝＝＝＝＝＝＝＝＝＝ここまで、キチガイの脳内会話＝＝＝＝＝＝＝＝＝＝＝＝＝

0664デフォルトの名無しさん

2005/05/08(日) 20:54:09

>>660
お前はどう思っているの？
オブジェクト指向分かんないのにデザインパターンの本読んで分けわかんねといっているお前はレベル高いわけ？

0665デフォルトの名無しさん

2005/05/08(日) 21:04:39

｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜　　　　>>664
し >>658-662

0666デフォルトの名無しさん

2005/05/08(日) 21:13:40

どうでも良いんだけどさ、

======

客「よく効く頭痛薬ください」
薬局の店員「ではこちらはいかがでしょうか」

======

こんなありふれた事を、「AbstractFactory パターン」って言うと途端に拒絶反応しめす奴が居るんだが、何とかならんか？

0667デフォルトの名無しさん

2005/05/08(日) 21:14:35

レベルの話はやめろ。荒れるだけだ。
建設的な話をしよう。
多分、そもそもの論点は
1. GoF本のサンプルコードがわかりにくいか否か
2. デザインパターンは浸透しているのか否か
3. 1 と 2 の議論の間には何か関連性があるのか否か
だと思うんだけど、どうだろう。

あと、「オブジェクト指向」って人によって認識が結構ずれると思うから
「お前はオブジェクト指向を理解していない云々」もやめてほしい。
荒れるだけ。

0668デフォルトの名無しさん

2005/05/08(日) 21:15:57

それはどっちかというと普通のFactoryで
Abstract～は、薬局を紹介してくれるって感じじゃない？

0669668

2005/05/08(日) 21:17:15

あー「よく効く薬」が実装されたFactory Classって事ならいいのか。
失敬。

0670デフォルトの名無しさん

2005/05/08(日) 21:18:51

>>654
この業界、やたら権威を求めるバカが多すぎるんだよな。
単なるアルゴリズムに「クイックソート」とか名前付ける必要あるかっつーの（笑）

0671666

2005/05/08(日) 21:22:11

>>668-669
わるい。例えがわるかったかも試練
『薬局の店員』を『製薬会社』に変えると……って、これじゃ無理があるか？それとも直球過ぎ？

0672デフォルトの名無しさん

2005/05/08(日) 21:22:15

パターン名：
　キチガイの脳内会話パターン

目的：
　GW最終日を迎え、孤独と焦燥感でパンク寸前。誰かとお話したい。

関連パターン：
　ギコ猫パターン、
　構って君パターン

0673デフォルトの名無しさん

2005/05/08(日) 21:24:12

＝＝＝＝＝＝＝＝＝＝＝＝＝ここまで、キチガイの脳内会話＝＝＝＝＝＝＝＝＝＝＝＝＝

0674デフォルトの名無しさん

2005/05/08(日) 21:25:46

＝＝＝＝＝＝＝＝＝＝＝＝＝以下、引き続きキチガイの脳内会話＝＝＝＝＝＝＝＝＝＝＝＝＝

0675デフォルトの名無しさん

2005/05/08(日) 21:29:16

独習本の方は具体的にパターン適用前のものと適用後のとが照応できるんでＰＧむけ、
Gof本は全然肌に合わなかった、パターン適用例がモンスターダンジョンだし
あんまし参考にできるようなものじゃなかった、使い道思い浮かばん実例出すなコラと。

0676デフォルトの名無しさん

2005/05/08(日) 21:30:25

>>675＝キチガイ

0677デフォルトの名無しさん

2005/05/08(日) 21:31:50

>>675
肌に合わないんじゃなくて、単にOOPの考え方に慣れていませんと、
正直に認めればまだ可愛いのに。

0678666

2005/05/08(日) 21:33:04

>>677
いや、簡単に OOP って言うけど、人によって随分と捉え方に差があるで

0679デフォルトの名無しさん

2005/05/08(日) 21:35:21

http://www.google.com/search?hl=ja&lr=lang_ja&ie=UTF-8&oe=UTF-8&q=GoF%E6%9C%AC+%E3%83%A2%E3%83%B3%E3%82%B9%E3%82%BF%E3%83%BC%E3%83%80%E3%83%B3%E3%82%B8%E3%83%A7%E3%83%B3
GoF本モンスターダンジョンに該当するページが見つかりませんでした。

検索のヒント
- キーワードに誤字・脱字がないか確かめてください。
- 違うキーワードを使ってみてください。
- より一般的な言葉を使ってみてください。
- キーワードの数を少なくしてみてください。

0680デフォルトの名無しさん

2005/05/08(日) 21:41:22

>>666
それだとコマンドパターンでもファサードパターンでも成立してしまう。

>>648
俺もこれは読み難いと思う。
ある意味GoF本と似てる、可読性が低いｗ

0681デフォルトの名無しさん

2005/05/08(日) 21:41:38

>>670
まあな。
圧倒的に名前がついてないアルゴリズムのが多いのに
何故にこれに限って？っていうのがあるのには同意。

>>667
１．デザインパターンに載ってる方法ってオブジェクト指向的に妥当なものなの？（トリッキーにみえるけど？）
２．デザインパターンって誰か使っているの？（職場でみたことないけど？）
３．１は誰が保障してくれるの？（狭い世界の話なんじゃないの？）
４．異常にたくさんありすぎて何があったのかすら覚え切れない（他の人もきっと覚えられないよ）

ってところが疑問点かな？
ちなみにデザインパターンがちょっとよくわからないって人は
↓のページをみるといいかも。少しはわかりいい。
http://www.01-tec.com/document/cpp_design_pattern.html

俺がデザインパターンをみたときの感想は「きたねぇ設計だな。おい。」だった。

0682デフォルトの名無しさん

2005/05/08(日) 21:42:57

>>681
＞圧倒的に名前がついてないアルゴリズムのが多い
そう？　どんなのがあるか言ってくれ……

……って、言えないよな。名前ないんだもん

0683デフォルトの名無しさん

2005/05/08(日) 22:01:35

>>682
そうだな、じゃあ、
ある文字列をトークン単位で分けるときに
ダブルコーテーションで囲まれた部分だけはデリミタ文字の影響をうけずに
そっくりと取ってくるようにした。

このアルゴリズムをなんていうの？（よくつかうけど名前ある？）

0684デフォルトの名無しさん

2005/05/08(日) 22:11:04

>>683
俺は無いと思うな
っていうかこのあたりで、汎化・特化の差が出てくるんじゃないか？

あれか。クラス・変数名スレに行って聞いてくる？

0685デフォルトの名無しさん

2005/05/08(日) 22:18:03

>>683
ここまでバカだとすげぇ笑える。

それはOOではなく、単なる文字列処理。
あえて関連する分野を挙げれば、
・言語処理系の字句解析

0686デフォルトの名無しさん

2005/05/08(日) 22:18:24

　　　　　　　　　　　　　　　　　　　　　　　　　　　キチガイスレ

0687デフォルトの名無しさん

2005/05/08(日) 22:22:02

>>685
いや、だから、それは>>670,682の答えであってな。
このスレとは関係無いわけよ。
話題はスレ違いだったけどさ。

0688デフォルトの名無しさん

2005/05/08(日) 22:25:51

さて、アンチの方に聞きたいが

お主らは、デザパタのどこに不満よ
とりあえず「当たり前のことにもったいぶって名前付けなくても」ってコトは理解した

0689デフォルトの名無しさん

2005/05/08(日) 22:27:57

>>688
せっかくおれが>>681にまとめたのに・・・

0690デフォルトの名無しさん

2005/05/08(日) 22:29:47

>>648,>>680
読みにくいか？
俺はCommonLispのマクロ使いまくってたから、
STLの表現はしっくり来る。

UNIX系でも、プリプロセッサ使って便利機能をつくると、
だいたいそんな感じになりやすい

0691デフォルトの名無しさん

2005/05/08(日) 22:32:30

>>689
わるいｗ上段を読んだ時点で 682 を書いたから完全に読み飛ばしてたｗ

0692デフォルトの名無しさん

2005/05/08(日) 22:40:57

っていうか、正直デザパタって「あれば便利。なくても良いけど。別に困らないし」っていうレベルだし
ただ、他者と情報を交換する時に、名前がついていたほうが便利かもしれないって話

あと、向上心を求めなければ成長できないって話でもある
デザパタに限らず、アイデア自体は盗んじゃえば自らの肥やしになるし

0693デフォルトの名無しさん

2005/05/08(日) 22:41:17

>>654
それ以外の、明確化という点の方がメリットとして強調されるべきだと思うが。

0694デフォルトの名無しさん

2005/05/08(日) 22:44:27

「オブジェクト指向」っていう単語でも思ったけど、
名前ついてるとなんか威厳があってスペシャルグレートなものだと思っちゃう人が多いみたいですね。

多分アンチの人にはそういうのが多いのだろうな、とそんなふうに考えていた時期が俺にもありました。

0695667

2005/05/08(日) 22:47:13

>>681
>１．デザインパターンに載ってる方法ってオブジェクト指向的に妥当なものなの？（トリッキーにみえるけど？）
文脈的に、トリッキーってのはコード例ではなく
クラス間の関係その他のことを言っていると思うので、そう仮定して答えます。
結論から言うと、デザインパターンというのは
オブジェクト指向を駆使した結果だと私は考えています。
もともと、smalltalk系の技術だということもありますし、
オブジェクト指向の成果である（と私が思う）
抽象化やカプセル化をフルに活用しているからです。
（オブジェクト指向とは何かという共通認識はおそらくないと思うので
非常に答えづらい質問ですが）

0696デフォルトの名無しさん

2005/05/08(日) 22:49:46

>>667
1. GoF本のサンプルコードがわかりにくいか否か

　サンプルコード以前に、
　GoF本に載っているパターンとその目的が、
　あまり現代的ではないと思う。
　・PLoPD本、・アーキテクチャ・パターン本、・アナパタ本、・PoEAA本等、
　いろいろ目を通して、使えるパターンを探してみる必要があると思う。

　また、J2EEパターンのように、
　既に多くのアプリサーバ/フレームワーク側に織り込み済みになっているものを
　適用する場合は、きちんとした判断力が必要だと思う。

2. デザインパターンは浸透しているのか否か

　理解すべきレベルの人間には、浸透している。
　問題は、そもそもデザパタの必要性に直面した経験のない人間の、扱い。

3. 1 と 2 の議論の間には何か関連性があるのか否か

　関係なっしんぐ

0697デフォルトの名無しさん

2005/05/08(日) 22:56:54

>>681
＞オブジェクト指向とは何かという共通認識はおそらくない

　OOできて30年。もう、いくつかの代表的な考え方に収束してると思いますが。

　ただ、主流となる考え方というのは、
　時代の変遷/技術革新とともにだんだん移動していくものなので、
　「古い考えに固執して自分が正しいと信じる」ようだと、
　上記が判らないかもしれませんね。
　

0698デフォルトの名無しさん

2005/05/08(日) 23:01:49

>>695
納得いかねーぞ！
責任者だせー！
しかもお前の考えかよ！ｗ

0699六百九十六＝六百九十七

2005/05/08(日) 23:03:34

激しく脳内会話っぽいスレだな

0700667

2005/05/08(日) 23:07:24

>>681
>２．デザインパターンって誰か使っているの？（職場でみたことないけど？）
少なくとも私の職場では使っています。
全体として実際どうなのかは私は知りませんし、
ここにいるみなさんにとってもまずわかり得ないと思います。

>３．１は誰が保障してくれるの？（狭い世界の話なんじゃないの？）
保障とは？デザインパターンのオブジェクト指向的な妥当性の保障？
すいません。ここはちょっと意味がわかりません。
アランケイに聞けとかそういう話？

>４．異常にたくさんありすぎて何があったのかすら覚え切れない（他の人もきっと覚えられないよ）
私の話をすると、確かにほとんど使う機会のないパターンの理解は浅いです。

0701デフォルトの名無しさん

2005/05/08(日) 23:10:14

>>700
とりあえずデザインパターン自体に信頼性が皆無なことはわかった。
まあ、自己責任でってのはいつものことか・・・

0702デフォルトの名無しさん

2005/05/08(日) 23:13:42

>>699
うん、構成作家が手で殴り書きした原稿を打ってる。アドリブはなし。

0703裕子

2005/05/08(日) 23:13:58

ｾｷｭﾘﾃｨについて誰か教えてくれませんか？先輩にいやがらせでインストールできんようになってしまいました・・・

0704デフォルトの名無しさん

2005/05/08(日) 23:14:59

>>701
＞デザインパターン自体に信頼性が皆無
同意。というか強制力がない。使える場面もあるけど、使えない場面もやっぱり多い。

0705デフォルトの名無しさん

2005/05/08(日) 23:15:24

板違い。ｾｷｭﾘﾃｨ板逝け
　http://pc8.2ch.net/sec/

0706デフォルトの名無しさん

2005/05/08(日) 23:18:42

>>703
裕子、何を思ってこのスレにきたんだ？ｗ

0707670

2005/05/08(日) 23:21:23

煽ったつもりが華麗にマジレスされたので非常に反応に苦しむがとりあえず謝っておきます。
あ、マジレスなんて権威主義的な言葉を使ってしまった。
煽ったつもりが華麗にこちらが皮肉でしたつもりの発言に対してそれを皮肉ではなく
そのままの表面的な意味と解釈した上でのレスポンスをされてしまった。
ああしまった煽ったなんて権威主義的な言葉を使ってしまった。
相手に対して皮肉などを用い（略

0708裕子

2005/05/08(日) 23:22:44

ときどき、レスを打つウィンド間違えて、レスが混線しちゃうんです・・・

0709デフォルトの名無しさん

2005/05/08(日) 23:22:57

>>707
百合青栗鼠宜

0710デフォルトの名無しさん

2005/05/08(日) 23:23:50

＝＝＝＝＝＝＝＝＝＝＝＝＝以上、今日の人格障害者の独り言でした＝＝＝＝＝＝＝＝＝＝＝＝＝

0711デフォルトの名無しさん

2005/05/08(日) 23:30:16

ものすごい勢いの（・∀・）ｼﾞｻｸｼﾞｴﾝだったなｗ

0712デフォルトの名無しさん

2005/05/08(日) 23:33:04

「考え方」を「実体化」するために名前を付けるって思考法自体がオブジェクト指向的だな。

0713デフォルトの名無しさん

2005/05/08(日) 23:33:35

>>707
http://sylphys.ddo.jp/upld2nd/niji7/src/1115562626437.jpg

0714デフォルトの名無しさん

2005/05/08(日) 23:35:53

>>713 デブ専乙。お前のレスの削除依頼出しとけよ。

0715デフォルトの名無しさん

2005/05/08(日) 23:36:39

>>714
アンカー間違えてない？

0716デフォルトの名無しさん

2005/05/08(日) 23:38:20

>>712
それはオントロジー的意味論

0717デフォルトの名無しさん

2005/05/09(月) 00:39:35

GoFのデザインパターンの「本」の信奉者の一人ですが、
初心者には読んどいて損はないかなぁ　程度の本かと思います。

理由はこんな爺くさい理由です。

３０年くらい前に
　ソシュール（100年？くらい前の言語学の祖）の、言葉にはシニファ（表面）とシニフェ（内面）の考えに触れて、
　プログラムも言語だよなぁとおもい、オブジェクト指向に同感。
　でも、当時はスモールトークしかなくって重くて使い物にならず

２０年くらい前に
　アレクサンダー（３０年？くらい前の建築家）が、建築設計技術のノウハウを共有するために、
「パターンランゲージ」を提唱。
　ちなみに我が家は、お家の設計を初めてしたおいらが、この本を読んで設計したです。
　先人の知見を、言葉にすることで、共有しより高めることができるノウハウとして感銘。

１０年位前に
　GoFのデザインパターンがでて、やっとプログラミングが、オブジェクト指向で、ノウハウを単語で表現できる時代になったんだなぁ
　と感銘

　まあ、中身は、ＯＯＰを自称する人には、当たり前のことと、目的に特化しすぎることが混ざっていて、鵜呑みにするのはいかがかと思いますが・・・
　良いプログラマになるには、優れたソースを沢山読むべきときの、入り口程度に

0718デフォルトの名無しさん

2005/05/09(月) 00:49:06

>>717
まず、人に勧めるならデザパタがすぐれたソースor設計（？）だっていう証明をしてくれよ。
また、デザパタがオブジェクト指向的に妥当かどうかも確証を得てくれ。

それ等が難しいなら、否定意見も多々ありそれの証明はなされていないことを
キチンと明記した上で初心者に勧めてくれよ。
なんか欠点を隠してやれやれっていうのは不具合が出ることがわかってる
家電を不具合を隠して売っている企業と変わらないぞ。
いくら教える側だからって信頼性の無いものを初心者に教えていいわけじゃない。

俺にはデザパタはどうもトリッキーなコードにしかみえない。

0719デフォルトの名無しさん

2005/05/09(月) 00:50:15

お疲れさまでした

0720デフォルトの名無しさん

2005/05/09(月) 00:52:14

>>718
どのへんがトリッキーなのか例をきぼんぬ。

0721デフォルトの名無しさん

2005/05/09(月) 00:55:27

>>720
全体的に。
（また、説明すんのかよ面倒臭ぇなぁ。
１週間以内には書いとくわー。）

0722デフォルトの名無しさん

2005/05/09(月) 01:00:34

目的の実現手段が別にあれば、GoFのＯＯモデルやサンプルソースを使うことないので
トリッキーに見える（＝自分がやりたいことはもっと別の良いやり方があると感じている）
のなら、十分卒業ですね。

アブストラクトファクトリを使わなくても、スプリングフレームワークを使えば十分とか

717を書いた人より

0723デフォルトの名無しさん

2005/05/09(月) 01:01:06

> 全体的に。
（・３・）エェー

0724デフォルトの名無しさん

2005/05/09(月) 01:01:12

既に広く使われているものに名前を付け
意思の疎通を計りやすくしたのがデザインパターン

なのに、普及だのトリッキーだの片腹痛いな

0725デフォルトの名無しさん

2005/05/09(月) 01:05:26

>>717
　　ソシュールとOO→パターン・ランゲージ→デザパタ
とは気合っすね。

>>716
　そしてオントロジーの裏には、
　　・カテゴリー文法
　　・タイプ理論
　が控えてて、結局、
　数理論理学～論理に収束するような（てきとう
　

0726デフォルトの名無しさん

2005/05/09(月) 01:05:32

>>724
その選別方法・選別者が妥当かどうかの検証をキボン

0727デフォルトの名無しさん

2005/05/09(月) 01:10:59

>>723
もし、なんだったら、デザパタがオブジェクト指向的に妥当かどうかをそっちで証明してくれれば
トリッキーなのかどうなのかはすぐにわかるのかも。

0728デフォルトの名無しさん

2005/05/09(月) 01:17:09

>>724
GoF本＋C++の世界ではデザパタと実装を密に見る人が多いらしい。
それがGoF本故かC++故かは分からない。
デザパタと実装を密に考えてるという前提の下でレスを読むと、アン
チ側の言い分(トリッキーという言葉はパターンではなくソースコード
を指してる)が見えてくる。
JAVAモードの俺はそれに気付くまで十数レスを要したｗ
て言うか、それってスレ違いなんじゃ・・・・・・C++スレの範疇違うん？

0729723

2005/05/09(月) 01:21:00

>>727
「オブジェクト指向的に妥当」ってことがどうなのかよくわからんし俺には証明できんよ。
それよりそっちがトリッキーの実例出したほうが速いと思うんだが……
たとえばCompositパターンはどのへんがトリッキーでオブジェクト指向的に妥当じゃないの？

0730723

2005/05/09(月) 01:22:20

compositeだった。

0731デフォルトの名無しさん

2005/05/09(月) 01:24:23

>>724

> まず、人に勧めるならデザパタがすぐれたソースor設計（？）だっていう証明をしてくれよ。
> また、デザパタがオブジェクト指向的に妥当かどうかも確証を得てくれ。

当時はJavaなんてなかったからねぇ、Java版GoFのソースもC++ベースかな
>728
は初耳ですが、その意味でも納得。

設計やＯＯとしては、継承、隠蔽、多様性（だっけ？）だけを使った、目的の実現方法をまとめたものと理解
（そんな純粋な言語はないので実言語からすると、異論はあるかも
　C++だって、C的にポインタ使いまわせば大概のことはできるし）

ちなみに
> 717
を書いたときにちょっと迷って、以下の一文を削りました。
当時のGoFのノウハウを、GoFが想定する初心者にわかるようにまとめたもの程度に

0732デフォルトの名無しさん

2005/05/09(月) 01:24:42

CompoSIT!＜トリッキー
とか突っ込もうと思ったのに、修正早いよ。
このボケ殺しがぁ！！！

0733デフォルトの名無しさん

2005/05/09(月) 01:25:19

>>728
GoF本自体に実装が載ってるんだから、よくも悪くもそれ意外の選択はゆるさねぇじゃん。
実装を蜜に見るも糞もねぇじゃん。
何言ってるのかわからないよ。

0734デフォルトの名無しさん

2005/05/09(月) 01:27:45

http://dhcp3037.orihime.ne.jp/
ｗｗｗっおｋｗｗｗｗうぇｗｗｗっ
うぇｗｗｗっうぇ
っｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
おｋｗｗｗｗｗｗｗｗｗおｋｗｗｗうはっｗｗｗっ

0735デフォルトの名無しさん

2005/05/09(月) 01:36:18

>>726
http://citeseer.ist.psu.edu/cis?q=Erich+gamma&submit=Search+Documents&cs=1
適当なの選べ。

0736デフォルトの名無しさん

2005/05/09(月) 01:41:26

>>735
何？この人が言ったからそれが正しいって？
それじゃ狂信者と変わらないし、何の説明にもなってないよ。

0737デフォルトの名無しさん

2005/05/09(月) 01:42:36

>>735
どうせなら君がこの人のどういう言葉に共感を得て
どの辺に信頼性の高さを感じたのか君の言葉で聞きたいな。

0738デフォルトの名無しさん

2005/05/09(月) 01:42:39

>>733
あ～、やっぱりか・・・・・・
そういう宗派の人には、「そうですね。僕が思い違いをしてました。」
と答える事にしてるｗ

俺の宗派ではアダプターの実装法なんて山ほどあり得る。
それは継承を使ったパターンと委譲を使ったパターンなんていう固い
ものではなく、もっと柔らかく緩やかな意味でね。
俺はね、そうする事の正誤は大切なものだと考えてる。でも、○×パ
ターンであるか否かはあまり大切だとは思ってないんだよ。

それではコミュニケーションが･･･とか言い出す人が出そうだけど、「
○×パターンでよろしく」などという途方もない抽象度で詳細を要求
したりされたりする事はないから、必要な粒度に応じて言葉は使い分
ける。俺は寧ろそちらの方が自然だと考えてるけどね。
あっ！あくまで俺の宗派の話ね。他所の話は知らないｗ

0739デフォルトの名無しさん

2005/05/09(月) 01:43:00

>>736
なんだciteseerの使い方しらないのか。そうじゃなくてこの人が
言ったことを引用している文献がさらに出てくるんだよ。それ読めば
妥当性云々の話はぞろぞろ出てくる。

0740デフォルトの名無しさん

2005/05/09(月) 01:44:46

>>735
明らかな逃げだよな。
自分の言葉を持たないなら無理に発言する必要はないんじゃない？

0741デフォルトの名無しさん

2005/05/09(月) 02:04:48

>>726
妥当とはなんだ、既にあるものに名前をつけるのに正しいとはなんだ？

もう一度言うが、「良くある」クラス設計を「汎化」し「モデル化」して、名前を付けただけだ
デザインパターンを否定する人ほど、デザインパターン(いやGoFそのもの)を金科玉条とでも思っているのが参るな

0742デフォルトの名無しさん

2005/05/09(月) 02:08:12

詳細に寄りすぎる否定派と、徹底的に詳細には触れたがらない
肯定派という図式は、ある意味非常に面白い。てか、滑稽ｗ

0743デフォルトの名無しさん

2005/05/09(月) 02:10:00

詳細といいつつどこがトリッキーか全然示さないわけだが。

0744デフォルトの名無しさん

2005/05/09(月) 02:16:05

詳細に拘りながら決して詳細には触れない否定派と、デザパタに
詳細など無いのだと説得する肯定派という図式は・・・・・・
やっぱりある意味面白くて滑稽じゃないか！｡･ﾟ･(ﾉД`)･ﾟ･｡

0745デフォルトの名無しさん

2005/05/09(月) 02:26:00

デザパタ肯定派は、Smalltalk実装系→C++応用　みたいな所で実証済みと考えてるような気がする。
デザパタ否定派は、ＳＴＬでデザパタ活用、みたいな所で不満を感じてると思う。

ＳＴＬ（笑　あれは、
・型のないＬｉｓｐマクロと、
・ＯＯ以降の新しい多相型システムの、
アマルガムだからな。

GoFデザパタ本の想定範囲外だ。
なんかいい本なかったっけ？なんとかかんとかＣ＋＋本で

0746デフォルトの名無しさん

2005/05/09(月) 06:06:07

>>743
だからそれは、デザパタがオブジェクト指向的に妥当なものか証明すればいい話じゃないの？

0747デフォルトの名無しさん

2005/05/09(月) 06:29:33

>>741
そのよくあるクラス設計のよくある基準ってのは誰か統計でもとったの？
また、誰のソースコードからとったよくあるクラス設計なの？
って部分は俺もわからない。

0748デフォルトの名無しさん

2005/05/09(月) 07:24:30

なぜGoFが世界中の統計取ってまで命名しなきゃなんだｗ

もしGoF本が適当に書かれていた本なら人知れず埋もれただろう？ただそれだけの話
実際はおまいですら知っているわけだ

0749デフォルトの名無しさん

2005/05/09(月) 07:29:39

>>748
別に世界中の統計をとれとはいわないけど
なんのプログラムの統計をとったのかは必要な情報だよね？
だって限りなく糞なプログラムの統計をとられてもしょうがないわけだし。

0750デフォルトの名無しさん

2005/05/09(月) 07:49:12

>>749
馬鹿にしているようで悪いが例えを挙げるぞ

ある人が偶然深海魚を釣り上げました、ある人はそれを「サウマティクティウス」と名付けました。
ところがそんな魚は二度と現れなかったので、「サウマティクティウス」という名はあまり使われなくなりました。

ある人が、頭の上で輝く物体を「太陽」と名付けました。
その輝く物体は"たまたま"毎日現れるので「太陽」という名は便利だと、皆が使い始めました。
「太陽」の一言だけで、皆は頭の上で輝く物体を互いに認識できるようになったのです。

糞なプログラムに「ｵｯﾍﾟｹﾍﾟｰﾊﾟﾀｰﾝ」と命名した本は、メジャーになれず埋もれました。

0751デフォルトの名無しさん

2005/05/09(月) 07:51:19

すでにあるものに勝手に命名するから傲慢といわれるんじゃないの？

0752デフォルトの名無しさん

2005/05/09(月) 07:52:01

しかも「すでにあるもの」の選択が恣意的だったりしてさ

0753デフォルトの名無しさん

2005/05/09(月) 07:53:45

>>750
意味がわからない。
単純に今のデザパタがなんのプログラムから統計とったのかはわからないけど
俺（もしくは俺と同じタイプのプログラマ）が組んだプログラムから統計とったら
トリッキーなパターンは生まれなかったといいたいんだけどね。

0754デフォルトの名無しさん

2005/05/09(月) 08:16:31

http://YahooBB219180178006.bbtec.net/
うぇｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗおｋｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗっｗｗｗｗっうぇｗｗｗｗｗｗｗｗｗｗｗｗ

0755デフォルトの名無しさん

2005/05/09(月) 08:16:56

>>753
糞でトリッキーなプログラムを恣意的に選択し傲慢に命名した様な本が
日本に住む君が知るほどメジャーになるのかい？

君が組んだプログラムから取った素直なパターンが本当に未出（！）で広く使われているなら、
君も本を出したらどうだい。売れるよ。

でもこう言われると思うよ「なんだ、あのパターンか」

0756デフォルトの名無しさん

2005/05/09(月) 09:06:18

>>746
悪魔の証明って知ってる?

0757デフォルトの名無しさん

2005/05/09(月) 11:39:30

>>742
このスレの場合、否定派が詳細に触れていないのだが。
「オブジェクト指向の妥当性」「コードがトリッキー」など
言葉だけで例も説明も何もない。

0758デフォルトの名無しさん

2005/05/09(月) 14:07:17

「オブジェクト指向的に妥当か」「コードがトリッキー」といった美学的な議論をしても、
「オントロジー」がどうとかいった哲学的な話をしてもきりがない。

むしろ、ある場面でなんらかの「デザインパターン」を適用することによって「関心の分離」「変更の局所化」が
できるのか、といった実践的な視点で適否を考えていった方が良いと思われ。

結局、One Thing in One Place とか、 Don't Repeat Yourself を実現するための
手段として、デザインパターンがマッチしているかどうか、といった問題じゃないの？

0759デフォルトの名無しさん

2005/05/09(月) 15:03:28

トリッキー、トリッキー
デザインパターンの秘密はね
トリッキー、トリッキー
教えてあげないよ

0760デフォルトの名無しさん

2005/05/09(月) 17:04:54

8 名前：仕様書無しさん [sage] 投稿日： 2005/05/09(月) 05:23:28
今後、凝集度を議論するときには、
Separation of Concernsの考慮が必要になるだろう

0761デフォルトの名無しさん

2005/05/09(月) 20:38:38

どうでも良いんだけどさ、

======

客「○○駅から近くて、トイレとバスが付いている所。で、出来るだけ家賃が安いところを」
不動産屋「ではこちらの物件などいかがでしょうか」

======

こんなありふれた事を、「Builder」「Facade」「FlyWeight」って言うと途端に (ry

……っていうか、もしかしたら殆どの書籍は方向性を間違っているのかもしれないな
載っている構造も、あくまで一例だし、サンプルコードにいたっては紛れもなく『サンプル』だし……

特定の構造とかコードに重点をおくのではなく、その構造に至った過程・意味を前面に押し出すべきのような肝
１つの問題を実現する為に、それこそ無限の実装方法があるわけだし

0762デフォルトの名無しさん

2005/05/09(月) 20:46:13

なんかこのスレ読んでると
修行修行修行
って励みがちな人々を
思い出しがち

0763デフォルトの名無しさん

2005/05/09(月) 21:20:56

分かった分かった。
おまいら、これからプログラム作るときはクラスが１つでmainが１つで３００００行ぐらいだらだらと書くんだ。

0764デフォルトの名無しさん

2005/05/09(月) 21:43:48

>>762
そーゆーお前は、
雑談の最中に相手の話を必死にこき下ろして最後に涙目になるような、
熱苦しい勘違い野郎のオーラが漂ってる

0765デフォルトの名無しさん

2005/05/09(月) 22:35:48

>>761
「アジャイルソフトウェア開発の奥義」の
パターンの記述は結構そんな感じでいいよ。

全部のパターンが網羅されてる訳じゃないけど、
ケーススタディに沿った形だから
実践で使いやすいものが選ばれてる。

0766デフォルトの名無しさん

2005/05/09(月) 23:28:05

>>761
それだよな。
パターンやコードがどうとかじゃなくて、
その構造に至った過程を前面に押し出すべきだよな。
確かにその通りだと思う。

0767デフォルトの名無しさん

2005/05/09(月) 23:37:07

>>766
激しく同意。
あと、GoF本に書いてあるような
「パターンを適用した結果」も重要だと思う。
闇雲に適用するんじゃなく、長所短所を理解した上で使わなきゃ。

0768デフォルトの名無しさん

2005/05/09(月) 23:40:54

>>767
それはいらんｗ
過程に比べればゴミみたいな情報だと思う。
別に無くてもいいと思う。

0769デフォルトの名無しさん

2005/05/10(火) 03:56:23

>>653,>>655,>>761
どうでも良いんだけどさ、

ギコ猫パターン並みにセンスの悪い意味不明な比喩で、
パターンを語るのカコワルイ。コードで語れよバカ、って感じ。

あと、ゾッキ本基準にオリジナル本語るの止めろよバカ

>>768
　>>762 乙ｗ

0770デフォルトの名無しさん

2005/05/10(火) 05:44:33

>>769
>コードで語れよバカ、って感じ。
詳しく

0771デフォルトの名無しさん

2005/05/10(火) 06:08:04

コードで語れよ、バカ

0772デフォルトの名無しさん

2005/05/10(火) 06:15:12

>>769
信者ですか？

0773デフォルトの名無しさん

2005/05/10(火) 06:27:25

朝から暑苦しいな

0774デフォルトの名無しさん

2005/05/10(火) 06:46:11

http://60-56-144-98.eonet.ne.jp/
うぇｗｗｗｗｗｗｗおｋｗｗｗっうはっｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
うはっｗｗｗｗｗｗ
ｗｗｗｗｗｗｗ
ｗｗｗおｋｗｗｗっうぇｗｗｗｗｗｗｗｗｗｗｗｗ

0775デフォルトの名無しさん

2005/05/10(火) 06:55:22

http://YahooBB219215164084.bbtec.net/
うぇｗｗｗおｋｗｗｗおｋｗｗｗ

ｗｗｗｗｗｗｗｗｗｗｗｗ

ｗｗｗｗｗｗうはっｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
うぇｗｗｗっおｋｗｗｗっｗうぇｗｗｗうはっｗｗｗ

0776デフォルトの名無しさん

2005/05/10(火) 08:22:51

なるほどこれが世に聞く
ﾈﾀﾆﾏｼﾞﾚｽｶｺﾜﾙｲって奴か

0777デフォルトの名無しさん

2005/05/10(火) 08:35:57

>>776
みいらとりのみいら

0778デフォルトの名無しさん

2005/05/10(火) 08:52:31

オマエのﾈﾀって池沼臭ぇ

0779デフォルトの名無しさん

2005/05/10(火) 09:12:51

>>778
すっぱいむのう

0780デフォルトの名無しさん

2005/05/10(火) 12:17:09

頭悪いのが常駐してるな

0781デフォルトの名無しさん

2005/05/10(火) 12:35:05

>>769
抽象物をその具象物によって語る無意味さになぜ気付かない？
コードで語るのなら始めから捨象する必要なんか微塵もないだろ？
何の為の抽象化だよ？
GoF本読んで手に入れたのがサンプルコードの丸暗記では、あま
りにも切ないな。

0782デフォルトの名無しさん

2005/05/10(火) 12:58:14

なるほどこれが世に聞く
ﾈﾀﾆﾏｼﾞﾚｽｶｺﾜﾙｲって奴か

このタイミングでいいのか？>777

0783デフォルトの名無しさん

2005/05/10(火) 13:10:32

>>780 どうしようもないバカ発見

0784デフォルトの名無しさん

2005/05/10(火) 13:11:20

きっと、デザパタ通じて変な分析設計哲学を語りたい人なんだよ

ほっとけって

0785デフォルトの名無しさん

2005/05/10(火) 13:26:58

役に立つ分析哲学、設計哲学ならいいけどね。

知識を咀嚼する力の無い幼児に、
デザパタ・ベビー・フードを無理やり流し込むようなのは
頂けないな。自己満足のための幼児虐待（・∀・）イクナイ

0786デフォルトの名無しさん

2005/05/10(火) 14:55:22

デザインパターンについて勉強しようとこのスレに来ましたが、
馬鹿ばかりで話になりませんね。

0787デフォルトの名無しさん

2005/05/10(火) 14:58:52

勉強しようと思ってこんなところにくるなんて

0788デフォルトの名無しさん

2005/05/10(火) 16:53:27

今ではこんなスレですが、昔はもう少しマシでした。
そんな風に思うのは、私が年をとったからでしょうか？

0789デフォルトの名無しさん

2005/05/10(火) 17:10:16

>>788
違います。あなたが馬鹿であるという自覚が持てて来たからです。

0790デフォルトの名無しさん

2005/05/10(火) 18:03:16

サンプルコード数 0 のデザパタ本、誰か書いてくれ……

0791デフォルトの名無しさん

2005/05/10(火) 18:04:43

あ～そうそう
個人的に、設計時に行き詰まってデザパタ本を開くのは、根本的に間違ってると思う

0792デフォルトの名無しさん

2005/05/10(火) 18:52:31

うーん、でも逆引きみたいなの、欲しいけどなー。
WEB+DBプレスの逆引き記事はよかった。

0793part1住人

2005/05/10(火) 19:46:55

>>786
ここ数年、例の粘着が板を荒らしまくってるからなあ。
いい加減、ID制導入しないとダメだろうな

>>792
サル引きデザパタ

0794デフォルトの名無しさん

2005/05/10(火) 21:57:39

>>793
このスレや過去スレ読んだけど
今と雰囲気あまり変わってないね
指摘されている問題点も反論も
２００１年から同じみたい

0795デフォルトの名無しさん

2005/05/10(火) 22:43:05

荒しが立てたスレだからな

0796デフォルトの名無しさん

2005/05/11(水) 05:09:51

Modern C++ Design って本どれくらいで読破しました？俺ダメかも。本の解説読みながらでさえソースコードの読解に小一時間かかる。
デザパタの存在すら知らない人が、何も知らずにこんなソースコード読んで理解できるのか？
偏執的デザパタだらけのフレームワークを使っている会社に間違って就職したら（そんな会社があったら）、
三日で辞めます。
templete< templete< class > class factory< templete< bool F, templete< T<true, class S > class singleton >
class SaitamaFactory >, templete <> class DeallocatorShanghaiStyle > class AssosiativeFactory : public factory, public DeallocatorShanghaiStyle
（↑適当）とかやられたらもう気が狂うし。

0797デフォルトの名無しさん

2005/05/11(水) 05:26:57

いい加減なコード例を引き合いに出す、アンタの負け。

0798デフォルトの名無しさん

2005/05/11(水) 08:17:49

モダンC++デザイン、さっぱりわからん。

0799デフォルトの名無しさん

2005/05/11(水) 08:36:11

デザパタはコストパフォーマンス極めて悪しでホロン部

0800デフォルトの名無しさん

2005/05/11(水) 10:13:53

C++の話は別のところでやれよ

0801デフォルトの名無しさん

2005/05/12(木) 01:08:06

>>794
初心者は常に存在するからね。

0802デフォルトの名無しさん

2005/05/12(木) 01:15:08

前スレどうだったっけ？と思って読み返してみたら、デザパタは
囲碁の定石みたいなものだってところで切れてた。
みたいじゃねぇよ！なんて終わり方だ⊂⌒~⊃｡Д｡）⊃

0803デフォルトの名無しさん

2005/05/12(木) 03:47:37

「囲碁の定石」か。

囲碁は、ゲーム展開の状態数が極めて多いんで、
チェスのように機械で力づくで先読みをして、
人間のチャンピオンと対等に戦うようには、当分ならないそうだ。
(今後DNAコンピュータや量子コンピュータが実用になったら、ワカランけどｗ)

で、人間がそのような状態数の多いゲームをうまく扱うのは、
ヒューリスティックにパターン化をして、扱う状態数を圧縮してるのではないか、と。

そのあたりが、ソフトウェアのパターン＝囲碁の定石　って話

0804デフォルトの名無しさん

2005/05/12(木) 06:10:52

http://p6095-ipad515marunouchi.tokyo.ocn.ne.jp/
ｗｗｗっおｋｗｗｗｗ
ｗｗｗｗｗｗうはっｗｗｗｗｗｗｗｗｗｗ
うぇｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗうはっｗｗｗ
うぇｗｗｗｗｗｗうぇｗｗｗっっうぇｗｗｗ

0805デフォルトの名無しさん

2005/05/12(木) 07:48:32

そもそもオブジェクト指向とデザパタがどう考えても合わないからな。
絶対に荒れる。
デザパタを考えた奴は正直オブジェクト指向を知らないと思う。

俺がこう考えるわけは、デザパタがオブジェクト指向がもつ便利な側面とまったく逆のことをしているから。
オブジェクト指向が便利なのはオブジェクト指向という考え方だけを軸にして色んな状況に対応できるから。
（現実にあるものをシミュレートすることで矛盾が少なくなり、誰がみてもわかりやすい設計になる。）
なのにデザパタは色んなパターンを覚えなければいけないという
オブジェクト指向の便利な面とまったく逆の色を見せている。
つまり、オブジェクト指向を覚えればオブジェクト指向１つでいいのに対して、
デザパタは色んなパターンを覚えなければならないということ。

オブジェクト指向を覚えた人間がこんなことをするというのが到底考え難い。

0806デフォルトの名無しさん

2005/05/12(木) 08:47:50

人生を生きる意味について知りたい

0807デフォルトの名無しさん

2005/05/12(木) 09:29:38

そもそも囲碁と定石がどう考えても合わないからな。
絶対に荒れる。
定石を考えた奴は正直、囲碁を知らないと思う。

俺がこう考えるわけは、定石が囲碁がもつ便利な側面とまったく逆のことをしているから。
囲碁が便利なのは囲碁という考え方だけを軸にして色んな状況に対応できるから。
（現実にあるものをシミュレートすることで矛盾が少なくなり、誰がみてもわかりやすい設計になる。）
なのに定石は色んなパターンを覚えなければいけないという
囲碁の便利な面とまったく逆の色を見せている。
つまり、囲碁を覚えれば囲碁１つでいいのに対して、
定石は色んなパターンを覚えなければならないということ。

囲碁を覚えた人間がこんなことをするというのが到底考え難い。

0808木を見て森を見ず

2005/05/12(木) 09:34:32

そもそも「木」と「森」がどう考えても合わないからな。
絶対に荒れる。
「森」を考えた奴は正直、「木」を知らないと思う。

俺がこう考えるわけは、「森」が「木」がもつ便利な側面とまったく逆のことをしているから。
「木」が便利なのは「木」という考え方だけを軸にして色んな状況に対応できるから。
（現実にあるものをシミュレートすることで矛盾が少なくなり、誰がみてもわかりやすい設計になる。）
なのに「森」は色んなパターンを覚えなければいけないという
「木」の便利な面とまったく逆の色を見せている。
つまり、「木」を覚えれば「木」１つでいいのに対して、
「森」は色んなパターンを覚えなければならないということ。

「木」を覚えた人間がこんなことをするというのが到底考え難い。

0809デフォルトの名無しさん

2005/05/12(木) 09:40:11

そもそも個人主義と社会貢献がどう考えても合わないからな。
絶対に荒れる。
社会貢献を考えた奴は正直、個人主義を知らないと思う。

俺がこう考えるわけは、社会貢献が個人主義がもつ便利な側面とまったく逆のことをしているから。
個人主義が便利なのは個人主義という考え方だけを軸にして色んな状況に対応できるから。
（現実にあるものをシミュレートすることで矛盾が少なくなり、誰がみてもわかりやすい設計になる。）
なのに社会貢献は色んなパターンを覚えなければいけないという
個人主義の便利な面とまったく逆の色を見せている。
つまり、個人主義を覚えれば個人主義１つでいいのに対して、
社会貢献は色んなパターンを覚えなければならないということ。

個人主義を覚えた人間がこんなことをするというのが到底考え難い。

0810デフォルトの名無しさん

2005/05/12(木) 10:17:12

そもそも「個別概念」と「知識体系」がどう考えても合わないからな。
絶対に荒れる。
「知識体系」を考えた奴は正直、「個別概念」を知らないと思う。

俺がこう考えるわけは、「知識体系」が「個別概念」がもつ便利な側面とまったく逆のことをしているから。
「個別概念」が便利なのは「個別概念」という考え方だけを軸にして色んな状況に対応できるから。
（現実にあるものをシミュレートすることで矛盾が少なくなり、誰がみてもわかりやすい設計になる。）
なのに「知識体系」は色んなパターンを覚えなければいけないという
「個別概念」の便利な面とまったく逆の色を見せている。
つまり、「個別概念」を覚えれば「個別概念」１つでいいのに対して、
「知識体系」は色んなパターンを覚えなければならないということ。

「個別概念」を覚えた人間がこんなことをするというのが到底考え難い。

0811ｗ

2005/05/12(木) 10:20:10

そもそも俺と社会がどう考えても合わないからな。
絶対に荒れる。
社会を考えた奴は正直、俺を知らないと思う。

俺がこう考えるわけは、社会が俺がもつ便利な側面とまったく逆のことをしているから。
俺が便利なのは俺という考え方だけを軸にして色んな状況に対応できるから。
（現実にあるものをシミュレートすることで矛盾が少なくなり、誰がみてもわかりやすい設計になる。）
なのに社会は色んなパターンを覚えなければいけないという
俺の便利な面とまったく逆の色を見せている。
つまり、俺を覚えれば俺１つでいいのに対して、
社会は色んなパターンを覚えなければならないということ。

俺を覚えた人間がこんなことをするというのが到底考え難い。

0812デフォルトの名無しさん

2005/05/12(木) 10:44:35

>>805
こういう「動物が鳴く、犬がワンワン、猫がニャンニャン」で理解が止まっている人には
デザインパターンは理解しづらいかもな。「なんでそんな面倒なことをする必要があるんだ？」って。
そういう人にはアナリシスパターンがお薦め。

0813デフォルトの名無しさん

2005/05/12(木) 11:22:57

>>812
OOD と OOP を混同してないか？

0814813

2005/05/12(木) 11:24:00

アンカミス
>>805 だった orz

0815デフォルトの名無しさん

2005/05/12(木) 12:25:14

805の元ねたは何ですか？

0816デフォルトの名無しさん

2005/05/12(木) 12:39:52

>>805
こういう「ワンワンスタイルで、ニャンニャンして哭きまくり」で理解が止まっている人には
SMプレーは理解しづらいかもな。「なんでそんな面倒なことをする必要があるんだ？」って。
そういう人にはアナルプレーがお薦め。

0817デフォルトの名無しさん

2005/05/12(木) 13:10:33

デザインパターンは有用だがこのスレは有用でない事にいまさら気が付いた

0818デフォルトの名無しさん

2005/05/12(木) 13:20:15

Horizontal-Vertical-Metadata パターン
　再利用可能なコンポーネントで業務アプリを作れ
　というリクエストに対する、１次近似の回答。
　Vertical部は、業務共通部品
　Horizontal部は、業務固有部品
　Metadata部は、コンポーネント間の結びつきを容易に変更可能にするための層。(いまならDIとか)

出典：COBRA Design Pattern

問題点：Horizontalの業務固有部品を作り出す方法論は、まだまだ・・・

0819げ。訂正訂正

2005/05/12(木) 13:21:19

Horizontal-Vertical-Metadata パターン
　再利用可能なコンポーネントで業務アプリを作れ
　というリクエストに対する、１次近似の回答。
　Horizontal部は、業務共通部品、
　Vertical部は、業務固有部品、
　Metadata部は、コンポーネント間の結びつきを容易に変更可能にするための層。(いまならDIとか)

出典：COBRA Design Pattern

問題点：Verticalの業務固有部品を作り出す方法論は、まだまだ・・・

0820デフォルトの名無しさん

2005/05/12(木) 13:27:23

コブラって・・・

0821デフォルトの名無しさん

2005/05/12(木) 13:36:07

デザインパターンは覚えなくていいよ。
誰かがその内言語ごとにライブラリにまとめてくれるから。

0822デフォルトの名無しさん

2005/05/12(木) 13:42:06

>>805
オブジェクト指向は、現実の模倣による抽象化とどまるべきで
再利用性のことはそれほど深く考えるべきじゃないってこと？

0823デフォルトの名無しさん

2005/05/12(木) 13:45:27

抽象議論厨房を排除しないと、このｽﾚおしまいだな

0824デフォルトの名無しさん

2005/05/12(木) 13:46:20

低能のﾈﾀをﾈﾀと見抜けないと（ry

0825>>820 満足かいｗ？

2005/05/12(木) 13:47:16

Horizontal-Vertical-Metadata パターン
　再利用可能なコンポーネントで業務アプリを作れ
　というリクエストに対する、１次近似の回答。
　Horizontal部は、業務共通部品、
　Vertical部は、業務固有部品、
　Metadata部は、コンポーネント間の結びつきを容易に変更可能にするための層。(いまならDIとか)

出典：CORBA Design Pattern

問題点：Verticalの業務固有部品を作り出す方法論は、まだまだ・・・

0826デフォルトの名無しさん

2005/05/12(木) 20:29:31

>>822
>>763

0827デフォルトの名無しさん

2005/05/12(木) 21:10:39

>>825
詰まらん訂正の山を築く虞

0828デフォルトの名無しさん

2005/05/12(木) 21:29:43

いわゆるリファクタリングっすね

リファクタリングからデザインパターンへ (洋書)読みてぇー

0829デフォルトの名無しさん

2005/05/12(木) 22:28:17

>>822
逆なんだよ。
オブジェクト指向で組んでたら再利用可能なクラスがたくさんあったってだけの話で
未知の物を作るのにはじめっから再利用することに重点をおくようでは設計は腐ってしまう。

0830デフォルトの名無しさん

2005/05/12(木) 22:34:26

>>822
俺が一番いいたいのはここ↓

>オブジェクト指向が便利なのはオブジェクト指向という考え方だけを軸にして色んな状況に対応できるから。

これが一番重要なのにパターンを覚えるなんてまったく意味が無い。

0831デフォルトの名無しさん

2005/05/12(木) 22:41:39

>>830
大事だと思うよ。その考え方。それがあるなら柔軟にシステムに合った
設計ができるってことだから。
それで、その設計を誰かに説明する時にパターンっていうものがあると
便利な時があるんじゃないかな？同じ定義をお互いにわかりあえるよね。

0832デフォルトの名無しさん

2005/05/12(木) 23:17:36

デザパタを単に覚えるのは数学の公式を丸暗記するようなもんだろ。
できない受験生がやってることと本質的に同じなんだよ。
パターン名を口にして通ぶる前にデータ抽象や手続き抽象の勉強を
して基礎体力をつけるべき。

0833デフォルトの名無しさん

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

>>831
世の中にそのパターンの数しかパターンが無いならそのパターン数分を覚えちゃうのもいいけどね。

例えば、電車の路線探索。
Ａ駅からＢ駅までの色んな径路をだしてくれるがパターンとしては数が多すぎてもてない。

これはオブジェクト指向とデザインパターンの関係に似てないだろうか？
世の中にあるプログラムの問題は、解決方法をパターンとしてもてるほど少ない数であるかどうか？

0834デフォルトの名無しさん

2005/05/12(木) 23:24:46

>>833
ごめん。ちょっと日本語分からない
電車の路線探索を何に例えているんだ？

0835デフォルトの名無しさん

2005/05/12(木) 23:26:20

>>834
自分で考えた方がいいと思う。

0836デフォルトの名無しさん

2005/05/12(木) 23:26:42

>>833
そうそう。全くその通り。
周囲によく知られているパターン（例えばGoFのパターン）
と全く同一にならないことはたくさんあると思うんだ。

ただ、コミュニケーションを取る上で、
「○○パターンのような手法でやるとどうかなぁ？」
っていう話し合いの道具（ようするに語彙）として
使えるのでは？というのが自分の主張。どう思う？

0837デフォルトの名無しさん

2005/05/12(木) 23:28:44

>>834
ヒント：有限個数と無限個数の径路探索の解法

0838デフォルトの名無しさん

2005/05/12(木) 23:29:25

>>834
多分、世の中にはパターンとしてくくれない設計の方法が無数にあるよ
ということと
AからBまでの経路が無数にあるよ
ということを並べているのだと思う。
間違っていたら指摘しておくれ>>833

0839デフォルトの名無しさん

2005/05/12(木) 23:36:31

>例えば、電車の路線探索。
>Ａ駅からＢ駅までの色んな径路をだしてくれるがパターンとしては数が多すぎてもてない。

こういうのはデザイン(空間軸の設計)ではなくてアルゴリズム(時間軸の設計)の問題だろ。

0840デフォルトの名無しさん

2005/05/12(木) 23:41:12

>>836
１．パターンにあてはめる手間がいる（パターンが多いほど）
２．１で当てはめたパターンが妥当であるかどうかの検証が必要になる。
３．コミュニケーションをはかる上で効果があるのは両者がそのパターンを熟知しているときのみ。
　　（大して普及していない。また、覚えるのも楽ではないデザパタではおそらく困難）

>>838
あってるあってる

>>839
こういうのを同じ問題だと認識できないかなぁ・・・
プログラム組んでてもさ、パターン数分もてない場面ってあるじゃん？
まさにそれがあてはまると思うんだけど。

0841834

2005/05/12(木) 23:41:17

>>835-383 みんなサンクス
意味分かったよ

まぁ「パターン」というぐらいだから
デザパタはよく出る型であり(某プロジェクトにおいて)当てはめられる確率が高い
という意味で覚えておいて損は無いと思うなぁ

よく言うじゃん。8020運動って

0842デフォルトの名無しさん

2005/05/12(木) 23:41:33

頭がおかしくなりそうなレスばっかだな。

0843デフォルトの名無しさん

2005/05/13(金) 00:01:30

AからBまでの経路が無数にあっても、実際使うのはせいぜい数個で、しかもそれらはみんなが良く使う経路。
だったらよく使う道（パターン）として整理してあったほうが初めて来る人にも便利だし、説明するのも楽。
そうじゃない場合（例えば未知の地点Cへの経路を開拓する場合）でも、
何度も使われる経路ならそのうちパターンになるだろう。

0844デフォルトの名無しさん

2005/05/13(金) 00:02:37

>>840
１．「当てはめる」というとちょっと印象が違うのだけど、
その部分の設計の目的がしっかりしていれば該当するものは限られてしまうから、
目的が違うパターンは思考から外せばいいと思うんだけど、そうではないかな？

Q．パターンは他人と意識を共有するための語彙であるってことと、
よくある設計のカタログというような感覚で受け止めても、完全否定されてしまう？
主張が外れて受け止められるのが怖いので書きました。
２．に関しては１の決着いかんで決まる話かな？

３．パターンを使ってコミュニケーションする必要があるのはかなり上位の設計を
している人間のはずなんで、同じ人種で話すなら問題無いと考えています。
プログラマ全員が理解するものではないよって感覚。

もし、アプリを設計する上でコミュニケーションが全く存在しないという仮定ならば、
デザインパターンなんてあんまり価値が無いということならほぼ同意なんだけど。

0845デフォルトの名無しさん

2005/05/13(金) 00:11:46

>>844
>３．パターンを使ってコミュニケーションする必要があるのはかなり上位の設計をしている人間のはずなんで
そんなわけない。以上。

0846デフォルトの名無しさん

2005/05/13(金) 00:13:25

>>845
ほかのことには答えないんだね。
まぁいいや。面白い話じゃなくなったんで消える。

0847デフォルトの名無しさん

2005/05/13(金) 00:49:58

>>844
径路探索の話題には触れてくれもしないのに？
こっちに答える義務があるのかな？

0848ﾈﾀ神降臨か？

2005/05/13(金) 01:53:28

最近オブジェクト指向やデザインパターンを乱用した「良くない設計」や「良くない実装」を多く見かけるのです。
私は業務システムの世界で働いています。
業務システムにおいてはフレームワーク部のようなミドルウェア的な部位を除き
デザインパターンなんてほとんど登場しないはずです。
それどころかオブジェクト指向ですら、そもそもクラスの導出の場面すら無いです。
多くの業務はクラス導出できるほど単純ではありません。

「良くない設計」や「良くない実装」をしてしまわないための一番の近道は、
「構造化分析手法」の適用だと考えています。
基本的に規模が大きければ大きいほど、携わる人間が多ければ多いほど、
そして仕様変更が入る確率が高ければ高いほど、構造化分析および構造化プログラミングが
なされていないと手詰まりになります。

そしてもう一つ重要なポイントなのですが、
オブジェクト指向やデザインパターンのなかの多くの技は「構造化」という観点からは
リレーショナルデータベースにおける「逆正規化」に相当しているのだという点です。
残念なことに、多くの人に、この点もあまり理解されていません。
オブジェクト指向はほんとうに注意深く導入しない限り、プログラムの理解を妨げ、
試験をしづらくし、生産性を下げ、保守性を下げます。
オブジェクト指向は間違いなく「逆正規化」に相当します。
そもそもオブジェクト指向やデザインパターン適用について、
これらが生産性や保守性に与える効果についての統計的な情報にほとんど出会わないことについても、
これは悲しい現実であると受け止めています。

0849デフォルトの名無しさん

2005/05/13(金) 02:36:59

>>833
最後の段落についてだけど、複数の具象はそれより少ない数の抽象によって
表現する事ができる。この時問題になるのは具象の数ではなく具象との距離。

例えば、車種がどれほど膨大に増え続けても、車という抽象によってそれらを
表現する事ができる。でも、それだけでは意味を持たない場面もある。その場
合には、セダンやワゴンといった具合に具象と抽象の距離を変える。
距離が遠いと適応範囲が広がり、距離が近いと詳細度が上がる。
抽象化の肝になるのは必要に応じて如何に適切な距離をとれるかという事。

話を開発現場に戻すと、解決方法として最も具象と距離が近い抽象は既存コ
ードだろう。ただし、その距離故に適応範囲は狭い。
それより一歩引いた距離の抽象として、デザインパターンは存在してる。
俺はそういう風に理解してる。

0850デフォルトの名無しさん

2005/05/13(金) 06:24:17

mainの中でゆるゆる作業せず、「関数」や「手続き」に作業を任せる、というのも広い意味ではオブジェクト指向と言えましょう。
何か意味のあるプログラムを構築する際に、その動作を検討し細かく分けていって「何らかの動作の単位」の集まりに抽象化することができるはずです。
その際にプログラマの考える方針のパターンとして何か例題的なものがあるならば、次第にこのような思考法に慣れていくことでしょう。
そのような例題のうちいくらかはプログラマの血肉になり定番の思考法になるかもしれません。

0851デフォルトの名無しさん

2005/05/13(金) 09:53:48

>>848
他のレスに馴染んじまってて、全然違和感ないのが怖いなｗ

>>850
説得力のない意見を、いくら丁寧な言葉で語ってもダメだろ。
アンタの言葉を乱暴に要約すれば、

「(スキル不足や試行不足で)オブジェクト指向設計がうまくいかないような場面なら、
　ためらうことなく構造化設計に戻れ。
　構造化設計とは、手続きのみに着目して、手続きを分割詳細化する方法だ。
　構造化設計すら知らずにオブジェクト指向設計やろうとするなんて、笑止（ぷ」

・・・ところで、データベースを活用したり、伝票(transaction)が飛び回るような事務システムなら、
　　データ指向分析/設計 (DOA, DOD)
　　メッセージング・ベースのソリューション(Relaxerの人は伝票指向アーキテクチャと言っているｗ)
ってあたりを無視できないと思うけど。

貴方が構造化設計に執着するのは、ビジネスロジック専門のCOBOL屋とお付き合いがあるからかなｗ

0852デフォルトの名無しさん

2005/05/13(金) 16:52:09

> 「関数」や「手続き」に作業を任せる、というのも広い意味ではオブジェクト指向と言えましょう。
No.
そりゃ構造化プログラミングじゃん。

0853デフォルトの名無しさん

2005/05/13(金) 18:06:43

・・・たぶんこの人は、

　構造化プログラミング ⊂ オブジェクト指向プログラミング

なんだとおもふ。あと、上のほうの人は、

　データ中心設計 ⊂ 構造化プログラミング　＝　レガシー手法

と一括りにしちゃってるとおもふ。

0854デフォルトの名無しさん

2005/05/13(金) 18:32:52

頭が悪い奴は大変だな。現実世界でも叩かれ、2ch でも叩かれ。

0855デフォルトの名無しさん

2005/05/13(金) 19:06:01

マジ可哀想。

でも著作を匿名で書いて知らん振りするのより、
blogで実名晒して恥かいてるいがぴょんの方が、
社交的と言えるかもなｗ

0856デフォルトの名無しさん

2005/05/13(金) 19:22:34

間違った時、それを指摘されるのを恥ずかしいと感じる奴は
大概何やっても伸びないよなｗ

0857デフォルトの名無しさん

2005/05/13(金) 19:46:21

それ俺どっかに書いたー

0858デフォルトの名無しさん

2005/05/13(金) 19:52:20

自分が書いたレスが、回りまわって自分に戻ってくる天唾掲示板だな（藁

0859デフォルトの名無しさん

2005/05/13(金) 21:25:12

構造化プログラミングって違うと思うよ

0860デフォルトの名無しさん

2005/05/13(金) 21:25:35

>>849
>複数の具象はそれより少ない数の抽象によって表現する事ができる。
それの最小単位はオブジェクト指向だけで十分だと思うんだけど？
デザインパターンが全て・または大部分を覆うものでは無い以上あってもしょうがない気がする。
やっぱり小さい世界の話だよ。
（しかも、俺にはデザインパターンがうまい設計とは思えない。（と、いうよりアプローチがそもそも悪い））

オブジェクト指向での設計に磨きをかけた方が絶対伸びると思う。

0861デフォルトの名無しさん

2005/05/13(金) 21:28:29

白猫黒猫いい猫はどっち？

0862デフォルトの名無しさん

2005/05/13(金) 21:38:48

>>861
選択の際のいい猫の基準プリーズ

0863デフォルトの名無しさん

2005/05/13(金) 21:50:56

むかーしむかしは処理単位に分析設計し、実装していた。（COBOLとかDOS時代のアプリ）
ちょっと昔はデータ単位に分析設計し、実装していた。（DOA)
今（これから）はオブジェクト単位に分析設計し、実装するのが主流になる。

0864857

2005/05/13(金) 22:03:07

>>856
遅レスだが、

・誤りを恥と感じないのは、単なるキチガイ

・誤りを恥じて、合理化行動をする(他のせいにする/誤魔化す)のは、成長しないから迷惑

ってこったｗ

0865デフォルトの名無しさん

2005/05/13(金) 22:05:23

cout << "Hello, World!"

も

printf("Hello, World!")

も同じだからオブジェクト指向ってのもその程度よ

0866デフォルトの名無しさん

2005/05/13(金) 22:05:57

大人なら、
誤りを指摘した人に真意を尋ね、
・もし可能なら納得できる説明をしてもらうか、
・自分で真偽を確認して、
最終的に自分の誤りに気付いたなら、
感謝の意を込めながら訂正するってもんですよ

0867デフォルトの名無しさん

2005/05/13(金) 22:06:02

>>862
ネズミを捕る猫

0868デフォルトの名無しさん

2005/05/13(金) 22:11:34

ここで話していて誤りを訂正した人をほとんど見たこと無い。
あげあし取りみたいな話をして論点ずらして逃げたりする人なら見たことある。

0869デフォルトの名無しさん

2005/05/13(金) 22:15:02

デザインパターンを勉強しようとこのスレに来たのですが
Java/C++ のコードが見あたらないですね。

すれ違い？誰か誘導キボンス

0870デフォルトの名無しさん

2005/05/13(金) 22:24:30

>>869
ここは2流3流のプログラマがデザパタについて見当外れの薀蓄をたれるスレッドです。
2chではなくてパターンコミュニティで勉強しましょう。

0871デフォルトの名無しさん

2005/05/13(金) 22:26:15

>>870
正解

0872デフォルトの名無しさん

2005/05/13(金) 22:28:26

Domain-Driven Designのスレもよろしくね（はぁーと

0873デフォルトの名無しさん

2005/05/13(金) 22:33:11

そうだね、使ってみればいいんだよな
NeXTのAppKitはOSXのCocoaになったんだから今でも使えるし

0874デフォルトの名無しさん

2005/05/13(金) 22:36:36

>>867
判断基準が白か黒かしかないなら、
夜行性のネズミを捕まえるのに視覚的にみえにくいと思われる黒のがいい猫さんですかね？
（ネズミの目が色を認識できるのかどうかは知らんが）

0875デフォルトの名無しさん

2005/05/13(金) 22:42:01

cout << "Hello, World!" << " : " << count << endl;
と
printf("Hello, World!").printf(" : ").printf("%d",count),printf("\n");

も同じだからオブジェクト指向ってのもその程度よ

0876デフォルトの名無しさん

2005/05/13(金) 22:44:28

>>875
いや、おもしろくないから・・・

0877デフォルトの名無しさん

2005/05/13(金) 22:55:43

http://homepage2.nifty.com/igat/igapyon/diary/2005/ig050509.html
デザパタをむやみに使いたがるやつはへたくそ。

0878デフォルトの名無しさん

2005/05/13(金) 23:00:38

http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview03.html
パターンは邪魔

0879デフォルトの名無しさん

2005/05/13(金) 23:02:31

>>877
　>>848

0880デフォルトの名無しさん

2005/05/13(金) 23:02:54

>>877
言ってる事は大体わかるのだが、
最後の「オブジェクト指向だけでは解決できないものにデザインパターンを使う」ってのは変だ。
そんな局面でデザパタが使えるとは思えん。

0881デフォルトの名無しさん

2005/05/13(金) 23:07:47

>>877
こういうのってオブジェクト指向がはやり始めた大昔から言われている誤解と同根だよな。
「オブジェクト指向は大規模開発でないと意味がない」とか。

0882デフォルトの名無しさん

2005/05/13(金) 23:09:59

蓄積されたノウハウってのは、
ステロタイプな仕事をする奴には役立つが、
オリジナルな仕事をする奴にとっては、オリジナリティを阻害する、って話だろ。

ノウハウの蓄積をうざがる厨房は、
ノウハウに嵌るの厨房と同じ穴の狢。

陳腐化してウザイなら、新しい仕事をして、
その中から新しいパターンを熟成なさいってこった。

0883デフォルトの名無しさん

2005/05/13(金) 23:20:30

一部のプログラマ以外はオリジナリティーなんていらないんじゃない?

いかにたくさん引き出しをもってるか、必要におうじて引き出しをひけるかが重要だと思う。

0884デフォルトの名無しさん

2005/05/13(金) 23:21:53

オリジナリティのあるプログラミングしたいなら、
boostの追加機能でも考えればいいんでない？

0885ヽ(´ー`)ノ ◆.ogCuANUcE

2005/05/13(金) 23:23:32

「オリジナリティのある仕事をする = オリジナリティなコードを書く」
だと俺は思うがね。

0886ヽ(´ー`)ノ ◆.ogCuANUcE

2005/05/13(金) 23:23:56

オリジナリティのあるコードを書く、だな。失礼。

0887デフォルトの名無しさん

2005/05/13(金) 23:25:23

それは多分違う。

0888デフォルトの名無しさん

2005/05/13(金) 23:28:08

「仕事をなんでもかんでもパターンに当てはめようとするのではなく、
　必要に応じて新しい設計/新しいコードを書き、新しいパターンを熟成なさい。」
これが Mr.AOKI ＆ Alexanderの真意ということだ。

0889デフォルトの名無しさん

2005/05/13(金) 23:39:06

>>878
っていうかこの人大丈夫かいな。
キングファイルにできないと、生産性があがらないとか。
http://homepage2.nifty.com/igat/igapyon/diary/2005/ig050512.html

0890デフォルトの名無しさん

2005/05/13(金) 23:40:57

きっとなんかの超比喩なんだろう。

いや、リンク先がリアル・キングファイルとゆーことは、
きっと帳票システムの事を言っているとか(妄想120％

0891ヽ(´ー`)ノ ◆.ogCuANUcE

2005/05/13(金) 23:52:02

>>885-887
いやああああああ(;ﾟДﾟ)

「オリジナリティのある仕事をする != オリジナリティのあるコードを書く」
という事が言いたかったのに、等号と不等号間違えた(;´Д`)

>>889
キングファイルねぇ。

俺なんか紙や紙に出力するのが前提のデータ(しおり打ってないPDFとか)なんか
持ってこられたらブチ切れるよ(笑)。

0892デフォルトの名無しさん

2005/05/13(金) 23:53:29

キングファイルのリンクﾜﾛﾀ

0893デフォルトの名無しさん

2005/05/14(土) 00:02:08

クイーンファイルは、キングファイルよりパンチ穴が一個多いという噂だ

0894デフォルトの名無しさん

2005/05/14(土) 00:20:04

いがぴょんは、浅海さんと仲良くできそうな気がする・・・

0895な

2005/05/14(土) 02:03:12

質問です。
libpngを使って、png画像の縮小をすることは可能でしょうか？
知っている方がいたら教えてください。
よろしくお願いします。

0896デフォルトの名無しさん

2005/05/14(土) 02:14:01

↑誤爆

0897デフォルトの名無しさん

2005/05/14(土) 02:46:45

>>895
えーと、誤爆にマジレスすると
縮小も縮小のアルゴリズムがあるわけだから、
（フォトショップだとニアレストネイバーとかバイリニアとかバイキュービックだかそんなん）
libpngなんてpng圧縮かけるだけのもんに縮小まで期待しない方が吉。

0898デフォルトの名無しさん

2005/05/14(土) 02:51:40

>>895
libpng は PNG 形式のデータの読み書きをするだけで、
画像の中身に対する操作はしない。
ImageMagick でも使えば。

>>897
圧縮には zlib 使ってるよ。

0899デフォルトの名無しさん

2005/05/14(土) 03:03:03

>>898
いや、どうでもいいんだけどさｗ
libpngはビットマップ画像にpng形式の圧縮をかけてるもの
って意味でpng圧縮って書いたわけよ。

0900デフォルトの名無しさん

2005/05/14(土) 03:04:35

圧縮つーか、圧縮解凍？なんて表現すりゃいいんだろか？

0901デフォルトの名無しさん

2005/05/14(土) 03:09:52

png -> dib -縮小-> dib -> png って話ではないのか

0902デフォルトの名無しさん

2005/05/14(土) 07:41:21

libpngもデザパタで何とかなるよ

0903デフォルトの名無しさん

2005/05/14(土) 08:42:00

？

＞png形式の圧縮
＞png形式の圧縮
＞png形式の圧縮
＞png形式の圧縮

0904デフォルトの名無しさん

2005/05/14(土) 12:34:59

>>903
pngは圧縮方法の名前だぞ。

0905デフォルトの名無しさん

2005/05/14(土) 14:50:34

なんだろうな

『自分が使いたく無ければ使わなければいいのに』
『デザパタが問題あるんじゃなくて、それを使う側に問題がある』

とか

0906デフォルトの名無しさん

2005/05/14(土) 15:04:38

典型的な信者

0907デフォルトの名無しさん

2005/05/14(土) 15:08:55

そして叩きたいだけのアンチ

0908デフォルトの名無しさん

2005/05/14(土) 15:19:19

>>904=899
LZ77って知ってる？

0909デフォルトの名無しさん

2005/05/14(土) 15:27:51

んじゃ『デザパタにも、それを使う側にも同様に問題がある』にしてみる

デザパタじゃなくて『○○』にして色々当てはめてみてもいいけど

0910デフォルトの名無しさん

2005/05/14(土) 15:44:34

>>908
そんなこまかい話だったのか・・・

0911デフォルトの名無しさん

2005/05/14(土) 15:46:05

ogg と vorbis と ogg-vorbis の違いとか

0912デフォルトの名無しさん

2005/05/14(土) 17:59:12

>>904
普通は画像フォーマットの名前。

0913デフォルトの名無しさん

2005/05/14(土) 18:57:38

>>912
でも
「png圧縮かかってるよ」
とか使わない？
pngデータっぽくなってる自作画像フォーマットの説明をするときはそう呼ぶけど。

0914デフォルトの名無しさん

2005/05/14(土) 19:37:51

こんな奴がデザパタがどうのとか言ってるのか……
あきれた

0915デフォルトの名無しさん

2005/05/14(土) 19:40:18

枝葉に引っ掛かって大きく脱線するのは、ある意味このスレらしいと言えるｗ
そして、そんな時にしか伸びないのも、このスレらすぃいorz

0916デフォルトの名無しさん

2005/05/14(土) 19:42:26

と、png圧縮君が申しております

0917デフォルトの名無しさん

2005/05/14(土) 19:47:47

で、けっきょく使ってるヤツはどのくらいいるんだ？

0918デフォルトの名無しさん

2005/05/14(土) 19:49:10

>>917
png圧縮を？

0919デフォルトの名無しさん

2005/05/14(土) 19:55:39

言わないよなぁ

0920デフォルトの名無しさん

2005/05/14(土) 19:56:01

918 ﾜﾛｽww

で、結局デザパタは『使う』モノじゃないよん

0921デフォルトの名無しさん

2005/05/14(土) 20:01:35

png圧縮も使わないよな

0922デフォルトの名無しさん

2005/05/14(土) 20:21:31

LZH圧縮とかも使わないよな

0923デフォルトの名無しさん

2005/05/14(土) 20:22:41

あんまり虐めるなよ
発狂されても困るしそのへんにしとけ

0924デフォルトの名無しさん

2005/05/14(土) 20:40:32

そうだな、ping圧縮の中の人がかわいそうだ。

0925デフォルトの名無しさん

2005/05/14(土) 20:57:05

えぇっつ、使わないの～～～？？

0926デフォルトの名無しさん

2005/05/14(土) 21:31:47

いわゆる「PNG 圧縮」と呼ばれるものは、PNG 形式のラスタグラフィックスに
LZ77 で圧縮をかけたももじゃないの？

少なくとも、俗称であって技術的な用語ではないな。

0927デフォルトの名無しさん

2005/05/14(土) 22:07:45

この板の厨房って、スレ違いの話題振ってスレ荒すのな（ｐｕｐｕｐｕ

　　　　　　　　　　　　　　　　　　　頭悪過ぎ（ｷﾞｶﾞﾜﾛｽ

お客さんほとんど来ないっしょ、ここ数年

0928デフォルトの名無しさん

2005/05/14(土) 22:09:04

頭のおかしい人が、自宅療養中です。。。

　　　　　　　　　　　　　　　　（中央病院精神科）

0929デフォルトの名無しさん

2005/05/14(土) 22:10:03

>>927
だって話題ねーんだもん。
デザパタなんてパターン増えてくのかと思ったら、更新止まってるし。
もう、何年更新止まってるんだ？
新しいパターンはでたの？

0930デフォルトの名無しさん

2005/05/14(土) 22:32:09

これに目を通しておけ

Enterprise Integration Patterns
Pattern of Enterprise Application Architecture
Refactoring to Pattern
Domain-Driven Design

0931デフォルトの名無しさん

2005/05/14(土) 22:35:17

もちろんこっちは当然だよな？

デザインパターンと契約
ケント・ベックのSmalltalkベストプラクティス・パターン―シンプル・デザインへの宝石集
ソフトウェアアーキテクチャ -- ソフトウェア開発のためのパターン体系
Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects
プログラムデザインのためのパターン言語―Pattern Languages of Program Design選集
Pattern Languages of Program Design (Pattern Languages of Program Design)
Pattern Languages of Program Design 2 (Pattern Languages of Program Design)
Pattern Languages of Program Design 3 (Software Patterns Series)
Pattern Languages of Program Design 4 (Software Patterns Series)
アナリシスパターン―再利用可能なオブジェクトモデル

0932デフォルトの名無しさん

2005/05/14(土) 22:35:42

>>929
正直、もう研究ネタとして新しいパターンを抽出しました
ってだけじゃ評価されないから誰もやらない。
GoFもそれぞれ自分の実務が忙しいみたいだし。

ところで、GammaたんがIBMでEclipseのAPIにパターンを
ちりばめたのをどうにかしてほしい。
extension objectパターンなんて多用するもんじゃないと
思うんだけど。

0933デフォルトの名無しさん

2005/05/14(土) 23:25:14

検索してると、学部の卒研にデザパタってのが多いな。

0934デフォルトの名無しさん

2005/05/14(土) 23:54:34

つまりそーいうネタ提供にちまちま役立っていると

0935デフォルトの名無しさん

2005/05/15(日) 00:05:12

>>932
なんだよ。
じゃあ、終了のゴングがなってんのかよ。
デザパタ使えるとか言ってた奴でてこいよ。
誰も更新してないし、終わってるようなもんなんで人に薦めてんだよ。
死ねよ。作った人間ですら放置してるってのに・・・
もう、アホかと、バカかと。

0936デフォルトの名無しさん

2005/05/15(日) 00:08:29

もちつけ。
>>930-931くらい目を通して、
お前がもし仕事してんなら、仕事で役立つパターン探せって。

・・・ったく中身のない煽りばっかで（ぺっ

0937１０００

2005/05/15(日) 00:11:42

このスレッドに頭のおかしい人が住み着いたようです。。。
もうこのスレッドは役立たないので、新しいスレッドを立ててくださいです。。。

0938デフォルトの名無しさん

2005/05/15(日) 00:11:48

>>936
デザパタについては終了なんだｗ

0939932

2005/05/15(日) 00:13:32

なんか書き方悪かったかな。放置されているわけじゃなくて、
すでに研究畑で議論するような段階じゃないから論文が出てこない。
学問ってそういうもんだろ?

Eclipseのライブラリのぞいてごらん。がんがん使われているから...
orz...

0940デフォルトの名無しさん

2005/05/15(日) 00:22:21

>>938
おまえがバカなのは良く判ったらから、もうやめとけって。

デザパタというのは、別にGammaの専売特許ではなくて、
「設計のパターン」って意味だよ。
だから、>>931のソフトウェアアーキテクチャにもデザパタの章があるし、
Pattern Language of Program Designなんてほとんどデザパタだ。

あと最近は、>>930にあるような「企業規模のシステム/アプリで使うパターン」
での需要が非常に重視されていて、そっち方面のデザインパターンが色々出ている。
おまえでも聞いた事あると思うけど「J2EEデザイン・パターン」つうのが、その端緒となった。

0941デフォルトの名無しさん

2005/05/15(日) 00:24:59

もちろん、イマドキ Sun J2EE Blueprintの J2EEパターンが、
そのままのカタチで通用するようなヘタレな環境は少ないけどな。

あと、マイクロソフトもエンタープライズ・パターンの書籍と記事を出している。
MSDNくらい、タマには覗いてみたらどうだい・・・あ、業界外のキチガイだからMSDNなんて読めないかｗ

0942デフォルトの名無しさん

2005/05/15(日) 00:30:03

>>940
つか、デザパタとは関係無い本まで出されて解説されてもね。
デザパタはもう時代遅れだって認めろよ。

まあ、いいやコレをみろ↓
http://sylphys.ddo.jp/upld2nd/news/img-box/img20050512171558.jpg

自分の常識が世間の常識とずれてないかよく考えたほうがいいよ。

0943デフォルトの名無しさん

2005/05/15(日) 00:39:33

キチガイｶﾞﾝﾊﾞﾚ

0944１００００

2005/05/15(日) 00:40:22

このスレッドに頭のおかしい人が住み着いたようです。。。
もうこのスレッドは役立たないので、新しいスレッドを立ててくださいです。。。

0945通りすがり

2005/05/15(日) 00:41:17

>>942
日本語も読めないのか？

0946デフォルトの名無しさん

2005/05/15(日) 00:49:18

>>942
　　　_, ._
　（　ﾟ Дﾟ）　　ｶﾞｼｬ
　　( つ　O. __
　　と＿)_) （__(）､;.o：。
　　　　　　　　　　ﾟ*･:.｡
ﾊﾞｶﾅ・・・ｱﾘｴﾝ・・・ｺﾚﾃﾞｼｮｳｶﾞｸｺﾞﾈﾝｾｲﾀﾞﾄ・・・

　　　　 _ _　 ξ
　　　 (´ 　｀ヽ、　　　 __
　　⊂,_と（　　）⊃　（__(）､;.o：。
　　　　　　　　　　　　　　　ﾟ*･:.｡
ｺﾚｶﾞ・・・ｼｮｳｶﾞｸｾｲﾉｸｵﾘﾃｨﾀﾞﾄｲｳﾉｶ・・・

0947デフォルトの名無しさん

2005/05/15(日) 00:52:13

放置汁

0948デフォルトの名無しさん

2005/05/15(日) 01:00:28

　　　　　　　　　　　　なんかこう、精神が不自由な人が粘着してる気配がする。

　　　　　　　　　　　　癲癇症とか、ヒステリーとか、極度のストレスでおかしくなった人の臭い

0949デフォルトの名無しさん

2005/05/15(日) 01:07:37

>>946
大きさで品質を評価する時代はとっくに過ぎてるんだよ。ボケがぁ！
上部は鋭く、下部はたおやかに湾曲した優美な曲線と自己主張し
つつも下品に揺れ動く事のない適度な大きさ。これを極上と呼ぶ。
大きさなどは形状を評価する上での１関数に過ぎないのだよ。

0950デフォルトの名無しさん

2005/05/15(日) 01:08:40

>>949
>>942のリンク先のウェストは細そうだ。

0951次スレ案内

2005/05/15(日) 10:59:27

【GoF】デザインパターン 4
http://pc8.2ch.net/test/read.cgi/tech/1116122102/l50

0952デフォルトの名無しさん

2005/05/15(日) 11:06:45

建てるの早すぎだろ

0953デフォルトの名無しさん

2005/05/15(日) 11:19:57

そうでもないだろ
と、取得ログ数62を見ながら

なんでこんなに盛り上がってるんだ

0954デフォルトの名無しさん

2005/05/15(日) 11:30:25

喚くだけの粘着が粘着しているから

0955デフォルトの名無しさん

2005/05/15(日) 11:31:14

>>953
png圧縮と小学５年生のデカパイ
デザインパターンはこれに負けた（失笑

0956デフォルトの名無しさん

2005/05/15(日) 11:33:34

　　　　　　　　　　　　精神が不自由な人が粘着してる気配がする。

　　　　　　　　　　　　癲癇症とか、ヒステリーとか、極度のストレスでおかしくなった人の臭い

0957デフォルトの名無しさん

2005/05/15(日) 11:36:57

学習障害　Learning Disabilities

学習障害とは、基本的には全般的な知的発達に遅れはないが、聞く、話す、読む、書く、計算する又は推論する能力のうち
特定のものの習得と使用に著しい困難を示す様々な状態を指すものである。学習障害は、その原因として、中枢神経系に
何らかの機能障害があると推定されるが、視覚障害、聴覚障害、知的障害、情緒障害などの障害や、環境的な要因が直接
の原因となるものではない。

学習障害の特徴

●話すことの難しさ

話を聞いて理解することが困難です。
「いつ・だれが・どこで・なにを・どうした」などの文脈構成上の基本的な要素が欠落し、人が聞いてわかりやすいように話をすることが困難です。
（事柄や順序を整理して話すことが苦手です。自分の経験を説明することが苦手です。）
聞きもらしが多く、会話も一方的で話題がとびやすいことがあります。

●読むことの難しさ

文字や文章を正確に（意味をとらえて）読むことが困難なことがあります。
本を読んでいるときに、どこを読んでいるのかわからなくなる。
問題なく話せるのに、似た文字の弁別にとまどったり、行をとばして読んだり重複読みをしたりします。（勝手に語尾を読み替える）。

●聞くことの難しさ

集団の中での指示が理解できません。（指示を忘れて何度も聞き返します。）
２つ以上の指示は困難です。
話を聞く時の「注意の集中」が持続しません。（話言葉中心の一斉授業の内容が聞き取れません）。
（因果関係など）複雑な会話は理解困難です。

0958デフォルトの名無しさん

2005/05/15(日) 11:37:25

>>956
おそらく「火病」。
デザインパターンが役に立たないことを指摘された信者が
話題をそらそうと必死なんだよ。

0959デフォルトの名無しさん

2005/05/15(日) 11:37:57

●計算や推論の難しさ

数の概念が身につかず、数系列の規則性などが困難です。
学童期では、足し算や引き算、くり上がりの計算などが苦手です。（短期記憶の障害のため、くり上がった数を忘れるために起こります）。
筆算の桁がずれる間違いも多いです。
文章問題も苦手です。（問題を理解して論理的に解決する力が乏しいために起こります）。
図形の特徴や概念がつかめない。（地図の見方が理解できない）
時計や単位が理解しにくい。
移動教室や、ロッカーの場所が、なかなか覚えられない。

●行動の自己調整の難しさ

学童期には、授業中に立ち歩く、ぼんやりする、私語が多く、話が聞けない...ことがあります。
順番を待つこともが苦手です。
気に入らないことがあると我慢できず、乱暴な行動をとることがあります。
一つの話題にこだわり、同じ質問、同じ話題を繰り返します。
表情が乏しく、人見知りしてその場の環境になかなかなじめません。

●対人関係の難しさ

相手の思いや感情を考えて、行動することが困難です。（人の嫌がることを言ったり、わがままを言ったりするため、自分勝手だと思われがちです）。状況判断が苦手です。
人と関わる時の基本的な挨拶や礼儀が身についていないことがあります。（これは、場面理解困難のために起こります）

0960デフォルトの名無しさん

2005/05/15(日) 11:42:22

なんだ、ここでデザパタと無関係な荒しやってる奴は、
「学習障害」っぽいな(藁

・気に入らないことがあると我慢できず、乱暴な行動をとることがあります

・一つの話題にこだわり、同じ質問、同じ話題を繰り返します。

・聞きもらしが多く、会話も一方的で話題がとびやすい

・文字や文章を正確に（意味をとらえて）読むことが困難

・（因果関係など）複雑な会話は理解困難

・問題を理解して論理的に解決する力が乏しい

・相手の思いや感情を考えて、行動することが困難です。
　（人の嫌がることを言ったり、わがままを言ったりするため、
　自分勝手だと思われがちです）。
　状況判断が苦手です。

0961デフォルトの名無しさん

2005/05/15(日) 11:45:03

>>960
ええ、もう、デザパタが使えないことを指摘されると
とたんに話題をそらそうと必死ですからｗ

0962デフォルトの名無しさん

2005/05/15(日) 11:45:28

>>960
　それ、小中学生に多い症状だよ

0963デフォルトの名無しさん

2005/05/15(日) 11:46:53

つまり、ここでデザパタ関係なしに荒らしてるのは、小中学生レベルの香具師か。

納得。>>930-931も読めない低能な餓鬼かよ！

0964デフォルトの名無しさん

2005/05/15(日) 12:02:28

そもそも増えていくはずのデザインパターンの更新が１０年も前から止まってしまっているからな。
GoF本の冒頭に書いてある、「競合より協調である」も
デザインパターンを知らなければ低脳、知らなければ無知という
信者の煽りによってあっさりと崩されてしまっているからな。

挙句の果てには本を何冊も読まなければ、反論も受け付けない始末。
自分の言葉をもたず他人の言葉をかりないと議論もできない信者。
著者の「競合より協調」精神は信者には伝わらなかったと考えて間違いない。
もう終わってると考えていいだろう。

デザインパターンは定理にはなりえない。
必要なときにはじめから順をおって説明する必要がある。
そして、その手間を惜しんでは知識の共有など不可能である。
これが理解できない信者によってデザインパターンの桃源郷はもろくも崩れ去った。

0965デフォルトの名無しさん

2005/05/15(日) 12:05:37

>>964
おまえがバカなのは良く判ったらから、もうやめとけって。

デザパタというのは、別にGammaの専売特許ではなくて、
「設計のパターン」って意味だよ。
だから、>>931のソフトウェアアーキテクチャにもデザパタの章があるし、
Pattern Language of Program Designなんてほとんどデザパタだ。

あと最近は、>>930にあるような「企業規模のシステム/アプリで使うパターン」
での需要が非常に重視されていて、そっち方面のデザインパターンが色々出ている。
おまえでも聞いた事あると思うけど「J2EEデザイン・パターン」つうのが、その端緒となった。

もちろん、イマドキ Sun J2EE Blueprintの J2EEパターンが、
そのままのカタチで通用するようなヘタレな環境は少ないけどな。

あと、マイクロソフトもエンタープライズ・パターンの書籍と記事を出している。
MSDNくらい、タマには覗いてみたらどうだい・・・あ、業界外のキチガイだからMSDNなんて読めないかｗ

09661001

2005/05/15(日) 12:17:59

このスレッドに頭のおかしい人が住み着いたようです。。。
もうこのスレッドは役立たないので、新しいスレッドを立ててくださいです。。。

0967デフォルトの名無しさん

2005/05/15(日) 12:19:52

>>965
>おまえがバカなのは良く判った
>おまえでも聞いた事あると思うけど
>あ、業界外のキチガイだからMSDNなんて読めないかｗ

まあ、この↑ありさまだからなｗ

0968デフォルトの名無しさん

2005/05/15(日) 12:20:50

↑だからオマエは頭が悪いんだよ。
　どーでもいい煽りにはすぐ食いつくが、
　議論の本筋は理解できない。

　学習障害だろ、おまえ。

0969デフォルトの名無しさん

2005/05/15(日) 12:23:07

楽しく議論をなさっている所、大変申し訳ないのですが、

次スレを立てたのはどなたですか？
あれ、「ソフトウェア・パターン４」で立てる予定でいたんですけど。

0970デフォルトの名無しさん

2005/05/15(日) 12:25:26

>>969
次スレを立てたのは、pngだエロ写真だと荒しまくってる、
いつものキチガイだと思う。
先頭にある関連スレリンク一覧がこのスレと一緒で、
全然更新情報が入っていないからわかるだろ、荒しスレだって。

0971デフォルトの名無しさん

2005/05/15(日) 12:26:23

>>970
　そもそもこのスレ立てた奴が荒し

0972デフォルトの名無しさん

2005/05/15(日) 12:27:17

確かに >10とか、バカっぽいな。

0973デフォルトの名無しさん

2005/05/15(日) 12:28:29

>>970
じゃぁ、さっき誰かが立てたスレは「荒しスレ」って事で放置したらいいんじゃねぇの？
　【GoF】デザインパターン 4
　http://pc8.2ch.net/test/read.cgi/tech/1116122102/

0974デフォルトの名無しさん

2005/05/15(日) 12:37:00

デザインパターン以前にオブジェクト指向が破綻してるから。

0975デフォルトの名無しさん

2005/05/15(日) 12:37:07

>>968
とことん、人を馬鹿にするのがあなたの開発手法なのですね？

0976デフォルトの名無しさん

2005/05/15(日) 12:40:59

ここの板一般に感じるんだけど
有益な議論が発展していくんじゃ無しに
バカにしてこき下ろすようなレスの応酬に
成りがちなようなキガス

0977デフォルトの名無しさん

2005/05/15(日) 12:41:41

　　　　　　　　　　　　このスレには、あたまのおかしい人が住み着いています

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(清掃局)

0978デフォルトの名無しさん

2005/05/15(日) 12:44:52

２ちゃんで「バカにしてこき下ろす」のが気になるのなら、
２ちゃんはやめておいたほうが良い。

この板の問題は、「バカにしてこき下ろす」だけで、
意味のある情報が全然出てこない事だ。

0979デフォルトの名無しさん

2005/05/15(日) 12:50:32

>>976はバカにしてこき下ろすだけで有益な議論にならないってことだよ

0980デフォルトの名無しさん

2005/05/15(日) 12:52:19

２ちゃんも翳り始めてないかな
昔からの運営はそう言ってるし
参加者もだんだんそう感じてきて
mixiなんかが栄えてきたし

0981デフォルトの名無しさん

2005/05/15(日) 12:52:35

>>978
またでたよー。
「２ちゃんだから～」発言。
あのさあ、君が人を馬鹿にする発言しなきゃそれで解決する問題なんじゃないの？
結局、自分が答えられなくなると他のサイトへのリンク貼ったり、
「本紹介しますから、読んで勉強してくださいね？ｗ
このままじゃあなたみたいな馬鹿と話なんてできないですよｗ」
的な発言するから荒れちゃうんだろ。

自分の言葉をもってないのがディスプレイ越しにわかるんだよ。
どう頑張ってもこういうの誤魔化すの無理だから。
同じような職場で似たような仕事してんじゃん。俺等。
思考回路も似たようなもんなのわかるんだよ。

0982デフォルトの名無しさん

2005/05/15(日) 12:54:27

このままじゃあなたみたいな馬鹿と話なんてできないですよ

0983デフォルトの名無しさん

2005/05/15(日) 13:01:59

＞同じような職場で似たような仕事してんじゃん。俺等。

ほう、それはなかなか優秀な方ですな。
じゃぁ、なんでこんな低能な会話をするの？

0984デフォルトの名無しさん

2005/05/15(日) 13:07:45

>>983
>じゃぁ、なんでこんな低能な会話をするの？
２ちゃんなんて煽ってなんぼダロ？とか考えてないか？

0985デフォルトの名無しさん

2005/05/15(日) 13:12:11

>>981
オマエが自分の言葉で語れよ

デザインパターンというと、
かつては
・クラス図テンプレートやコンポーネント設計への応用
・クラス間の相互作用に基づく自己組織化(w
といった理学・工学的な視点から語られる事があったが、

最近は
・教育カリキュラムとしてのデザパタ
・企業アプリ構築ノウハウとしてのパターン
に力点が移動してきているな。

そういったわけで、このスレも工学的テーマが減って
「教育としてのデザインパターン」「デザインパターン学習法」
みたいなお子ちゃま向け内容に偏るのは、しようがない。

ただし企業システムパターンのような
現場起源で今現場で使われているパターンの本流を
丸っきり無視しているあたりが、とてっつもなく嘘っぽい。

0986デフォルトの名無しさん

2005/05/15(日) 13:13:35

企業システムパターンは、実はノウハウ蓄積、ナレッジマネージメントとも関連すると思う。
・・・あ、零細人売り企業には関係ないけどｗ

0987デフォルトの名無しさん

2005/05/15(日) 13:26:01

上の方に出てきた「伝票指向アーキテクチャ」｢帳票指向｣アーキテクチャ」が
スルーされてる所を見ると、ソフトウェア工学どころかレガシー厨すらいないみたい。

単なる素人スレだろ、ここ。

0988デフォルトの名無しさん

2005/05/15(日) 13:28:04

>>985
と、勝手に>>985がGoF本の範囲をはみ出して語ってるけど
コレはスレ的にアリなの？

>ただし企業システムパターンのような
>現場起源で今現場で使われているパターンの本流
どこの御伽話なの？
少なくとも松下には無いと言っておく。

0989デフォルトの名無しさん

2005/05/15(日) 13:33:36

ああ、あいつか。九州松下でPDMの下請けに入ってる香具師。

なんで末端が全体を語るのか謎。

0990デフォルトの名無しさん

2005/05/15(日) 13:35:31

>>989
PDMやERPの下っ端は、オブジェクト指向と無縁だからなぁ(ｶﾜｳｿ

0991デフォルトの名無しさん

2005/05/15(日) 13:38:40

松下自体、家電用組込ソフトは実績あるけど、
企業システムは社内用しかやってないだろ。

ユーザー企業を騙って何をしたいのか、
このスレ的に意味不明だな

0992デフォルトの名無しさん

2005/05/15(日) 13:40:07

>>988
＞勝手に>>985がGoF本の範囲をはみ出して語ってるけど

バカかこいつ

0993デフォルトの名無しさん

2005/05/15(日) 13:41:35

>>991
じゃあ、どこで作ってるのかと。

0994デフォルトの名無しさん

2005/05/15(日) 13:42:56

>>992
>バカかこいつ
人を馬鹿にするのが好きな人が多いスレですね。

0995デフォルトの名無しさん

2005/05/15(日) 13:45:35

J2EEデザインパターン
William Crawford (著), Jonathan Kaplan (著), 福龍興業 (翻訳), 佐藤直生 (翻訳), 木下哲也 (翻訳)

木下哲也
1967年、川崎市生まれ。早稲田大学理工学部卒業。1991年、松下電器産業株式会社に入社。

0996988

2005/05/15(日) 13:47:52

>>995
ぶははははははは！
全然浸透してねぇよｗ＞デザパタ

0997デフォルトの名無しさん

2005/05/15(日) 13:49:58

下請派遣社員は何を言いたいのか、さっぱり意味不明でごじゃる

0998デフォルトの名無しさん

2005/05/15(日) 13:52:27

O b j e c t D a y 2 0 0 1 プログラム

携帯用オーディオ機器へのオブジェクト指向適用ケーススタディ　- 組込みシステムへのＯＯ導入の実際 -
松下電器産業(株)　古山寿樹氏

0999デフォルトの名無しさん

2005/05/15(日) 13:53:35

↓1000おめ

1000デフォルトの名無しさん

2005/05/15(日) 13:53:34

片山先生が、松下のソフトウェアエンジニアリング研究所長やってるから、大丈夫っしょ

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

レス数が1000を超えています。これ以上書き込みはできません。