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

ところで、「GoFのデザパタ本は入門書ではない。もっと詳しく知りたい人の本だ」
ってMartinFawlerさんが言ってるのを見つけたんだけど、皆さんはどう思いますか？

俺的には、経験積まないと共有知のありがたみなんて理解しようもないから、
GoF本だろうと結城本だろうと、ある程度進んでからやるべきだと考えてるけど。
(個人的学習経験としてそう思うし、また初心者に結城本教えるという無謀な試み(!)の経験で改めて実感したｗ

リファレンスはこのあたり
Swebok　http://www.martinfowler.com/bliki/Swebok.html

＞今月は IEEE による SWEBOK（ソフトウェアエンジニアリング知識体系） のレビュー月間である。
＞これは、我々の専門分野についての知識体系を定義しようという試みで、ライセンス化へ向けて
＞の土台となるものだ。
（中略）
＞さて、Swebok のどこがダメなのか？
（中略）
＞本の選出はひどくはなかった（GangOfFourを推薦図書にはリストアップしないよう私が警告したのだが）。
＞（GangOfFourはさらに理解を深めたい人用である。初心者用の「参考図書」ではない）

持っているの結城本だけど、初心者が丸暗記しそうなのが一番怖いと思う
そういう意味ではある程度経験積んだ人用の概念かもしんない

結城本はGoFパターンの雰囲気をわかりやすく伝えているのに対し
GoF本は個々のパターンの長所短所を分析しているような印象。

だから、デザパタ/OOP初心者に薦めるんだったら結城本。GoF本は薦めない。
>>426の初心者ってプログラミング初心者だよね？

初心者がGoF本を理解できるのなら、天才と呼んであげよう

>>429
天才と呼んでくれ。初心者だが、GoFの内容がスーッと頭に入ってきた。

>>429は早く天才と呼んであげるように

>>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

http://www.martinfowler.com/bliki/GangOfFour.html

＞漏れの汁限り、GoF本はこれまで出たOO設計本の中で最高っす。
＞つか、たぶんどんなタイプの設計の本と比べても、最高！！！
＞ソフトウェア業界にも、無茶苦茶影響与えてるし。まぁJava /.NETのライブラリなんて、
＞GoFが作ったプールの中でパチャパチャ泳いでるようなもんだｗ
＞
＞なーんて褒めてみたけど、決して読み易い本ではない罠。
＞OO設計の基本原則わかって、「OOえぇなぁ〜♥」って感じるようになってから、初めて嫁。
＞そこらへん判ってからじゃないと、この本の真価を読み取るのは無理。つか無理して読んでも無駄。
＞つか、そこらへん判ってからなら、努力して読めば、努力に応じたごりやくの得られる良書っす。
＞
＞コード例はほとんどC＋＋だけど、C++判んないからって焦る必要はなっしんぐ。
＞コード例は、C++の判りにくい機能は使ってないから、C言語さえ理解できりゃ判るようになってるって。

>>428
プログラミング初心者、OO初心者、両方の意味っす。
結城本は、クリープを欠いたネスカフェって漢字。

>>433
それってファウラーの文章を翻訳したもの？
もしそうなら書いてる内容は２ちゃんねらと大してかわらないな。

何か言ってるようで何も言えてない。ていうか、要約すると３行
になるｗ

スゲー(・∀・)ｲｲ!!
でも、読み易くはない(´･ω･｀)ｼｮﾎﾞｰﾝ
コード例はC++だけどCが分かればダイジョウV

いや、ちゃねらー言葉にほんにゃくしただけだってばｗ

もうちょっとまともな訳でファウラー大先生のありがたい御託を読みたい方は、こちらへドゾー（他は多分に意訳が激しいけど、この項目はまとも）
　http://capsctrl.que.jp/kdmsnr/wiki/bliki/?GangOfFour

>>436
まともな翻訳でもやっぱり大したこと言ってない。
凄くいいけど読むには経験が要る。
サンプルはC++だけどCが読めれば大丈夫。
今度は２行で要約できちゃったよｗ

>>437
blogってふつー、そーゆーもんだろ。
もしかしておまいのblogは、受けを狙って書くのかｗ

つか、マーチンの追っかけやってるｱﾌｫもどうかと思うが、
脳みそが２ちゃんでいっぱいいっぱいの>>435-437みたいなのは論外の外だなｗ

つか、ここでレスしてる人って、マジ英語のblog読めないの？

それ、まずいよ。翻訳屋に騙されっぱなしじゃん。技術者としては、能力75%落ちって感じかｗ

遅くなってスマン
>>430
君は天才だ
馬鹿と紙一重だ

>>438
blog＝日記という意識ならそうかもね。
けれども、少しでも書評という意識があったとしたら、この人の
書評には読むべきところがないね。
まぁ、それだけのこと。俺が褒めなくても、他に褒めてくれる信
者を一杯持ってる人なんだから、どうでもいいんじゃね？

いやblogは日記だろ、リンク付きの
そこを否定は変だぞ

誰でも褒められりゃ少しはうれしいだろうけど、
blog ってかならずしも誰かに褒められるために書くわけじゃ無し。

まぁ、ﾌﾞﾛｶﾞｰは120％受け狙いで日記書くわけだがｗ

吉野家コピペとかって、多分最も受けた部類に入るんだろうけど、
書いた人間が狙ってたかどうかは・・・？

奈良のおばちゃんは、受け狙ってたわけではないが、
一部ではかなーり受けてる

ギャラリーを意識していない女の日記はギリギリ存在を許容できるが
ギャラリーを意識していないブログは存在自体が有害。
中身ないくせしてシャクレタ単語だけは入れたがるから、無駄に検索
に引っ掛かる。
読ませる気がないのなら、人目につかない場所でひっそりとやってほ
しいもんだ。

どうでもいいからデザパタについての話をしてほしい。

デザパタおんりーつうのはイマドキつらいもんがあるね。
ドメイン・パターンとか、いろいろ扱うべきテーマがあるでしょ

奈良のオバチャンは扱うべきテーマか？

Eriv Evansが Domain-Driven Design であげてる基本パターンは、
どうなんだろう？

頭が弱い人が見たら、あれ UMLとかOOの基本並べてるだけに見えちゃうんだろうなぁ。

今頃デザインパターン云々いってる奴　＝　今頃たまごっちに夢中になってる奴

バカはすぐ調子にのる

寒

以前、Interpreterパターンについて書き込みした人です。

本を書いた本人に聞いてみました。

>>402 のような場合では、BNFを変形するということで良いそうです。
文法どおりにコーディングすることが重要であって、
文法が変わらなければ、BNFを変形すること自体はオーケーだそうな。

良し悪しではなく、趣味の問題、最適化の問題じゃないか、と。
デザパタの話題とは丸きり関係ないじゃねぇか、と。

・再帰下降/LL文法でバックトラックするか、
・LR文法でトークン先読みして、当てはまるBNF式を選択
すりゃ解決・・・って言語処理系の教科書ネタだよな。

・状態がA、B、Cとあり、それぞれで振る舞いが変わる
・A、B、Cとも共通の変数を「たくさん」扱う
・振る舞いが変わると言っても、影響範囲は一つか二つの関数程度である

こんな時に、分かりやすくするための良い設計が有ったら教えて頂けないでしょうか

今やっているのは、stateパターンにして「たくさん」を一つの構造体にまとめ
各state->func()に引数として渡すやり方ですが、引数のためだけにまとめるのは、どうも妙な気がします。

こんな感じ？
派生クラスの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(){ 実装}: };

StateBaseが持ってる「たくさんの変数」はprotected:で。

あ、ごめん共通の変数ならstaticもつけなきゃだめだ。

>>459
申し訳ないです。そのやり方だと、val1〜val4が
StateA、StateB、StateCでそれぞれ独立して存在してしまい
「共通の変数」では無くなってしまいまして。

val1〜val4をStateBaseでstaticにするほどじゃないのが、悩みどころで困っています。

とはいえ例付きでのレス、ありがとうございます。

書いているうちに内容がかぶってしまいました、すいません。

>val1〜val4をStateBaseでstaticにするほどじゃないのが、悩みどころで困っています。

Singletonでしか使えないな。ﾜﾗ

これ俺も良く似た状況に遭うけど難しいよな
クラスでの共通変数じゃなく、インスタンスのまとまり毎に扱いたい共通の変数な
464も言っているが、staticにしちゃうとSingletonでしか使えないし

その共通変数のまとまりを構造体なり、クラスなりにまとめて、
その「変数の塊クラス」のインスタンスを、それが必要なオブジェクトで共有させればいいんじゃないの？

> 引数のためだけにまとめるのは、どうも妙な気がします。

にループ

なんでメンバ変数がstaticだとシングルトン限定になるんだ？
普通に、インスタンスで共有できるんじゃないの？

>>468
Stateのクライアントとなるインスタンスが
2つ以上あるだけで破綻するから

>>466
俺も普通にそうしてる。
共有される変数を一つのオブジェクトとして扱うのは自然な事に
感じるんだが・・・・・・

でもそれって見事に実装の都合から設計しちゃってるよな

contextとかいう名前の変数にして引数で連れ回すか、
全体を統括するなんかクラスをもうけて連れ回さなくて済む
ようにするか。

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個と増えたときすげーこまる。

あれ？なんか、俺の周りだけ時空が遅れているようだ

stateオブジェクトの構築時にcontextを引数で渡してやれば
stateのメソッド呼び出しの時に渡してやる必要はないね。