http://martinfowler.com/bliki/SpecificationByExample.html XP/Agile Universe 2002のワークショップで「Specification By Example（実例による仕様書、SbE）」という言葉に心を奪われた。これは、XPにおけるテストのあり方のひとつではないか。 （このところ、テスト駆動開発(TDD)のテスト部分を語るのは流行遅れなのだそうだ。ひどい話だ。Jonと同じく、私も、そんな副次的なものなんかよりも包括的な自動テストにこそTDDの真髄があると考えている。 例えば、誰かに「100万ドルあげるから山にハイキングしておいで」と言われたとしよう。私は胸を張ってこう言うね。「今回のハイキングの目的は、自然の美を堪能するためである」と。いや、まあ、もちろん、懐もあたたかくなるけど……ね。 ） 仕様書について議論する際、

1999/07/07 更新 石井 勝 はじめに ここでは，オブジェクト指向に出てくる法則・原則をまとめました．パターンに比べてほとんど知られていないのが現状ですが，優れたオブジェクト指向開発者を目指すならデザインパターンよりまずこっちを理解し覚えてしまいましょう． これらの法則は，絶対守らなければならないというものではありません．開発中に法則が守られているか意識することが重要です．つまり 今行っている設計はその法則が守られているだろうか その法則を破っている場合，破るべき正当な理由があるだろうか と絶えず考えるようにしましょう．そうするとそれは自然に優れたオブジェクト指向設計になるのです．つまりこれらの法則は，優れたオブジェクト指向開発のための指針なのです． Robert C. Martin の Principles of OOD Robert C. Martinは，オブジ

Chose Vacation RentalsTips for renting your Vacation Rentals Whether you are a tenant or a landlord, here are some practical tips to help you prepare your vacation. Booking a vacation rental The reservation of your holiday rental is made directly with the landlord. It is recommended to confirm your reservation by sending a rental contract and a deposit or deposit. The balance of the stay will be p

http://martinfowler.com/bliki/LocalDTO.html （最後の部分を更新） ThoughtBloggersをよく見ているんでしたら、 fowlbotのひとりが怒っているのをご存じかもしれません。 オーストラリアの太陽がスウェーデンのモデルをジリジリと焦がしています。 JonはData Transfer Objects（邦訳）にムカついているようですが、 これはDTOが悪者ということではありません。 他のパターンと同様、ある文脈内でのみ有用というだけのことです。 パターンは常に2つの部分に分けられます。 「どのように使うか（How）」と「いつ使うか（When）」です。 実装の仕方を知るだけでなく、 いつ使う（使わない）べきかも知っておく必要があるのです。 彼はポイントを突いています。 私はリモートインターフェースという文脈でDTOを語っていますが、 パターン

http://martinfowler.com/bliki/HarvestedFramework.html 使えるフレームワークを作るには、フレームワークの構築から始めるのではなく、アプリケーションを作ることから始めよう。アプリケーションを作る時でも、汎用的なコードを開発しようとしないで、うまく分割され設計されたアプリケーションを作るのだ。 あるアプリケーションを作ったあとで、同じような要求をもつほかのアプリケーションを作ることがある。こんな時は、一番目と二番目のアプリケーションの間にある重複に気を配ってみる。重複を見つけたら共通領域に入れてやる。この共通領域がフレームワークの前段階（プロト・フレームワーク）になる。 さらにいくつかのアプリケーションの開発を続けていくと、そのフレームワークは徐々に洗練されていく。 最初の二つのアプリケーションのコードは、すべてを単一のコードベースに留めてお

これは、即座に存在に気付いてリアクションすべきだった機能です。他のどのような機能強化よりも、私にとっては重要です。 いろいろ時間を取られて目が行き届いていないのがバレバレ (汗。 問題・単体テストとinternal §　プログラムの複雑度を低減するという観点から言えば、あらゆる箇所から参照できる"public"の利用は、全く好ましいことではありません。 これは、インテリセンスで表示される候補が不必要に増えるという意味でも生産性を低下させる要因となります。 C#において、これを解決するための手段は十分にあるとは言えません。 強いて言えば、"public"ではなく、"internal"が解決策となります。これを使うことで、特定アセンブリ内からのみアクセスを許可することを明示できます。 ところが、"internal"は、単体テスト(テスト駆動開発)との併用で決定的な問題を引きおこします。テストメ

http://www.martinfowler.com/bliki/UmlAsSketch.html この使用方法では、 開発者はUMLをシステムのある側面を伝えるのに使います。 設計図と同じように、スケッチをフォワードエンジニアリングやリバースエンジニアリングの方針として使うことが出来ます。 フォワードエンジニアリングでは、 コードを書く前にUMLを描きます。 リバースエンジニアリングでは、 既存のコードからUMLを作成し、 コードを理解しやすくします。 スケッチの肝は取捨選択が可能なところです。 フォワードスケッチングを行えば、 今から書こうとするコードのだいたいの項目を挙げて、 チーム内で話し合うことが出来ます。 スケッチを描くと、これからやろうとしていることについてのアイデアや選択肢を話し合うのに役立ちます。 すべてのコードについて話さなくてよいのです。 最初に同僚に説明したいと思

http://www.martinfowler.com/bliki/FluentInterface.html 2005/12/20 数ヶ月前、Eric Evansと一緒にあるワークショップに参加した。 そこで彼がとあるインターフェースのスタイルについて語ったのだが、 我々はそれを「流れるようなインターフェース（fluent interface）」と名づけることにした。 一般的なスタイルではないが、もっと評価されるべき代物だ。 おそらく例を示したほうがいいだろうから、そうしてみることにする。 一番簡単な例は、EricのtimeAndMoneyライブラリだろう。 時間の間隔を作るには、通常は、以下のようにする。 TimePoint fiveOClock, sixOClock; ... TimeInterval meetingTime = new TimeInterval(fiveOClock,

http://martinfowler.com/bliki/CommandQuerySeparation.html 「コマンド・問い合わせの分離」という言葉は、Bertrand Meyer氏が『オブジェクト指向入門』で最初に述べたものである。これは、オブジェクト指向黎明期における最も影響力のある書籍である。 （1版がその影響力を持っていた。 2版も優れているが、これを持ち運ぶにはスポーツジムに数ヶ月は通う必要があるだろう） 基本的な考えは、オブジェクトのメソッドを明確に2つのカテゴリに分類するというものである。 問い合わせ：結果を返し、システムの状態を変更しない（副作用がない） コマンド：システムの状態を変更し、値を返さない 「コマンド」という用語は他の文脈でも広く用いられるため、 私は「モディファイア(modifiers)」という言葉を好んで使っている。 あるいは「ミュテータ(mutat