タグ

デザインパターンに関するm_pixyのブックマーク (4)

  • 2008-11-12_06-30 - 生きてま2 改 - Trac

    いままで実践したことある人いるのかな?もちろんソフトウェア開発の現場での話。 実はパターンランゲージは持ってはいたが、ざっと眺めただけで、その中身は精読していなかった。 なぜなら、こので知りたかったのは、どういう形でパターンをまとめ、分類しているかのサンプルとしてしか 見ていなかったからだ。 しかし、ふと最近このをもう一度パラパラ眺めていて驚いた。 このの内容はそのままでも自分達の役に立つ と。 このに収められているパターンは、町のような都市計画レベルのマクロから、「253.自分を語る小物」のようなミクロレベルまで様々な 粒度のパターンが紹介されている。このなかには、もちろんコミュニティの形成に関わるもの、それにオフィスについてのパターンも 紹介されている。 そして、それぞれのパターンの中には 人に注目した視点 が予想以上に多く含まれていることに気づいた。 例えば 83.師匠と弟子

  • 『ソースコードリーディング本としての『Implementation Patterns』』

    Kent Beckの待望の新刊『Implementation Patterns』が先月ついに出版された。一通り目を通したので、この書籍について書いてみたい。 『Implementation Patterns』はタイトル通りに読めば「実装(implementation)」=「プログラミング」についてのパターンなのだが、私はむしろもう1つのソースコードリーディングとして読みたいと思う。 Kent Beck, Implementation Patterns (Addison-Wesley Signature) 実装パターンとは、Kent Beckによれば「Java言語仕様とデザインパターンとの間」に位置するパターンだ。デザインパターンが主にクラス間の関係を扱うのに対し、実装パターンは1つのクラスを書くためのノウハウを扱う。 1クラスレベルでのプログラミングノウハウとはどんなものか。それは、「

  • ひがやすを blog - [etc]トランザクションスクリプトとドメインモデル

    このネタについては、ループしやすく結論が出ないので、あまり書きたくはないのですが、私の考えを誤解している人が多いようなので、書いておきます。 トランザクションスクリプト、ドメインモデルなんてのは、所詮実装の話で、どっちもどっち。トランザクションスクリプトが良いわけでもないし、ドメインモデルが良いわけでもない。私はどっちも好きではない。 重要なのは、ユースケース(ユーザ要件)と実装の対応関係が明確になっていることです。それさえ満たされていれば、実装はどうなっていてもかまわない。 ユースケースと実装の対応関係を明確にする方法の一つとして、ユーザ機能レベルのユースケースは、Teedaでいうサブアプリケーション(関連する複数の画面を束ねたもの)にマッピングする。サブアプリケーションは、関連する各画面の親クラスに相当する。各画面は、サブ機能レベルのユースケースに相当し、サブ機能レベルのユースケースは

    ひがやすを blog - [etc]トランザクションスクリプトとドメインモデル
  • dpinfo.html

    目次 はじめに Abstract Classパターン Abstract ClassパターンRuby版 (by 助田雅紀さん) Balkingパターン Before/Afterパターン Futureパターン FutureパターンRuby版 (by 助田雅紀さん) Generation Gapパターン Hook Operationパターン Hook OperationパターンRuby版 (by 助田雅紀さん) Immutableパターン Marker Interfaceパターン Monostateパターン MonostateパターンRuby版 (by 助田雅紀さん) MonostateパターンPerl版 (by 宮川さん) Null Objectパターン Null ObjectパターンとSingletonパターン Producer-Consumerパターン Sharableパターン Singl

  • 1