はてなブックマーク

アプリケーション開発で、古典的だが必ずといっていいほど登場するのが、CSV（Comma Separated Values）ファイルの読み書きだ。単にデータ列をカンマ（,）で区切っただけの単純なデータ形式なのだが、RFCなどの正式な仕様がないせいか、CSVを扱う標準的なライブラリというものが存在しない（少なくともJavaでは）。 （8/4追記: とおりすがりさんからコメント欄でご指摘いただいたが、CSVのRFCはあるそうだ。→ http://www.kasai.fm/wiki/rfc4180jp ） そのため、CSVを扱う要件が出てくるたびに独自のライブラリを作るという、車輪の再発明が至るところで行なわれている。しかし、このCSVは一見単純なのだが、データの中にカンマが入っている場合とか、データをダブルクォート（"）で囲ってきた場合とか、データの中にダブルクォートがあってそれがエスケープされ

WebアプリケーションフレームワークのStruts が、次のバージョン1.3からリクエスト処理の設計を大幅にリファクタリングし、Chain of Responsibility（CoR）パターンを採用するという。実際には、リクエスト処理部分の実装にJakarta CommonsのChain を使う。これまで一枚岩だったリクエスト処理部分を、コマンドの連鎖に書き換えることで、ユーザによるリクエスト処理のカスタマイズを容易にするのが目的らしい。 ここまではいいのだが、Commons Chainを触ってみると、これを本当にGoFのCoRパターンと見てしまっていいのか疑問に思ってしまう。より的確には、むしろPOSAのPipes and Filtersパターンなのではないだろうか。 GoFによれば、CoRパターンは次のようなものだ。 1つ以上のオブジェクトに要求を処理する機会を与えることにより、要求を

EclipseでJUnit4を使ってみると、けっこう面倒だと思ってしまう。それは、Eclipseの非常に便利なimport自動編成機能（Ctrl+Shift+O）と、Java5から導入されたstatic importとの相性が悪いからだ。たとえば、JUnit4を使って、 import static org.junit.Assert.*; import static org.hamcrest.Matchers.*; ･･･中略･･･ @Test public void onePlusOneEqualsTwo() { int sum = 1 + 1; assertThat(sum, is(equalTo(2))); }というテストを書いていて、なにか別のクラスを使おうとしておもむろに「Ctrl+Shift+O」を押すと、static importの部分が以下のように展開されてしまう。 impo

S2DomainModel 0.1をリリースしました。S2DomainModelは、Seasar2でドメインモデルやDDDの実装をサポートするためのライブラリです。 http://ouobpo.sourceforge.net/s2domainmodel/ 前回のエントリ「DIコンテナとドメインモデルの相性の悪さ」で書いたとおり、ドメインモデルの中で直接生成されるドメインオブジェクト（= Entity + Logic）に他のオブジェクトをDIすることは設計上難しく、ドメインモデルの自由な設計が阻害されてしまいます。そのため、DIコンテナを使った開発では、リッチなドメインモデルは敬遠されがちです。 S2DomainModelは、この相性問題を解決するためのライブラリです。ドメインオブジェクトにDIできる仕組みを提供することで、DIコンテナを使った、より自由なドメインモデル構築を可能にします。

Seasar、SpringなどのDIコンテナを使っていると、ドメイン層の実装はデータ（Entity／Dto）と振る舞い（Service／Logic）に分ける、いわゆるトランザクションスクリプトのスタイルになりがちだ（参照(1)、(2)）。理由は、1つにはドメインモデルの設計／実装そのものの敷居が高いこともあるが、そのハードルを乗り越えても、DIコンテナそのものがドメインモデルと馴染みにくい側面があるからだと思われる。 DIコンテナはエンティティやDTOにDIできない その側面とは、次の通り。DIコンテナは設計思想からしてファクトリの役目をするものであるため、DIコンテナを使う場合、インスタンスの生成は基本的にDIコンテナが担当することになり、コンポーネントに必要なオブジェクトはすべてDIで渡されるような設計に誘導されてしまう DIを使ったWebアプリケーションのアーキテクチャは、まずリクエ

以前一緒にお仕事をさせていただいたこともある、ビープラウドの佐藤治夫さんが主催の勉強会BPStudy 第7回にて、発表の機会をいただいたので話してきました。発表テーマは「ドメインロジックの実装方法とドメイン駆動設計」です。 http://www.beproud.jp/bpstudy/17/bp-study-7 後ほどBPStudy勉強会のサイトでも発表資料が公開されると思いますが、こちらにもUPしておきます。（アメブロではSlideShareやhandsOutのスライドを直接貼れないようなので、ちょっと変な貼り方をしています） http://handsout.jp/slide/371 以下の二部構成でお話ししました。Ⅰ. ドメインロジックの実装方法 Ⅱ. ドメイン駆動設計の紹介　前半は、お馴染みの「トランザクションスクリプト vs. ドメインモデル」の話です。それぞれのサンプルコードを交え

『Enterprise Integration Patterns』の著者の1人であり現在GooglerのGregor Hohpe氏が「Gregor's Ramblings」というブログを書いていますが、著者本人から許可をいただいたので、それを翻訳するプロジェクトを始めました。 http://code.google.com/p/gregors-ramblings-ja/ Hohpe氏のブログは、EIPの著者であるだけに、EAIやSOAに関する最先端の面白いアイデアがたくさん書かれています。第一回目は、その中でももっとも有名な記事「Starbucks Does Not Use Two-Phase Commit（スターバックスは2フェーズコミットを使わない）」を翻訳しました。 この記事は、Joel Spolsky編著の書籍『The Best Software Writing I』にも選ばれた記事

オブジェクト倶楽部クリスマスイベント2007（12/21）にて、オブジェクトの広場名義で発表の機会をいただいた。「オブジェクト指向の過去・現在・未来」というテーマで、過去編を広場メンバのyojikさん、未来編を同じく広場メンバの大村君（a.k.a. everpeace）、そして現在編を私が担当した。 OO厨厨トレイン（オブジェクトの広場） 私が発表に加わったのがこれ。オブジェクト指向の現在ということで、半ば恣意的に次の3つを現在の切り口として紹介させていただいた。- DI ＋ AOP - サービス指向アーキテクチャ（SOA） - ドメイン駆動設計（DDD） そのうちのDDDについては、DDDパターンの全体像を何とか1枚のスライドで視覚的に説明したいと思い、苦労して作った図がある。かなり頑張って作ったので、ここでも再掲したい。 この1枚の図を元にDDDの全体像を細かく語りたかったのだが、時間

昨年あたりからどういう訳かHaskell、Scheme、OCamlなどの関数型言語が流行りだし、今年はその流行にさらにCPUのマルチコア化というハードの進化も合流する中で、ErlangやScalaといった関数型と並列化の両方の特徴を備えた言語が流行した。 個人的には関数型言語は、その計算モデル（ラムダ計算とβ簡約）があまりに理系的すぎて好みではないのだが（OCamlとScalaはOOのパラダイムも備えているので好き）、どうやらソフトウェア開発の未来を考えたときに見逃せないキープレイヤーの1つになりそうな気配がある。 さて、ドッグイヤーのソフトウェア業界において、その将来を夢想してみることはなかなか楽しい。著名なソフトウェア工学研究者である東京大学の玉井哲雄教授が、ソフトウェア工学の今後10～30年の発展シナリオを予想した「ソフトウェアエンジニアリングの発展シナリオ」という記事を書いている（

いまやWebアプリケーションフレームワークの世界では、MVCが全盛だ。StrutsもJSFもTapestryもWebWorkも、みんなMVCフレームワークであることに変わりがない。MVCフレームワークの要点は、ビジネスロジック（Model）と画面（View）とを明確に分離することにある。その両者を繋ぐのがコントロール（Control）の役目になる。 Webアプリケーションフレームワークは、今後も色々なものが出てくるだろうが、MVCである限り、開発がどれだけ容易かといった細かな部分の違いを競い合うくらいしかできないだろう。もっと考え方をドラスティックに変えないと、新しいものは出てこない。 そんな中で、Webアプリケーションフレームワークに面白い動きがあるとすれば、プラグインベースのWebアプリケーションプラットフォームを作る、といった方向性がひとつあるだろう。Seasarファンデーション傘下

JBoss Rulesをはじめ、Jess、ILOG JRulesなど、ルールエンジンは商用／OSSを問わずいくつか出回っている。ルールエンジンは、SOAの文脈でもよく登場する。しかし、実際のところどうやって使っていいか、なかなかイメージが湧きにくいミドルウェアでもある。 Ronald G. Rossという人が、「ビジネスルールアプローチ」という手法を以下の書籍で提唱しているのだが、その中でルールエンジンの使い方を体系的に分類しているので、参考になる。 Ronald G. Ross, Principles of the Business Rule Approach (Addison-Wesley Information Technology Series) 1. 拒否機能（Rejector）・・・ルールに違反したイベントを棄却する 2. 生成機能（Producer）・・・イベントから何かを生

プログラミングには「分割統治（Divide and Conquer）」という考え方がある。非常に複雑で大きな問題をプログラミングで扱うときは、そのまま全体に取り組もうとせず、問題を単純な小問題に細かく分割して解決せよ、という考え方だ。プログラマにとっての常識といってもいい。 分割統治という言葉自体は、プログラミングの世界で新しく考え出されたものではなく、古代ローマの時代からある非常に古い言葉だ。知っている人も結構いると思う。しかし、そこから先へ、もう少し深く突き詰めて調べてみた人は、案外少ないのではないだろうか？ 分割統治をプログラミングの世界に持ち込んだのはダイクストラ 私の理解では、分割統治の考え方をプログラミングの世界に持ち込んだのは、かの有名なエドガー・ダイクストラ（構造化プログラミングの生みの親）だ。1965年に書かれた論文「Programming Considered as a

プログラミング言語には、リフレクション（reflection）という仕組みとイントロスペクション（introspection）という仕組みとがある。どちらも、プログラム実行時にオブジェクトの情報を参照するテクニックのことを指す。たとえば、オブジェクトのクラスは何か、オブジェクトにはどんなメソッドが定義されているか、といった情報をプログラム実行中に調べ、それに基づいてなんらかの処理を行なう。 実際のところ、リフレクションとイントロスペクションとの違いが私にはよく分からない。ネットで調べてみると、以下のような説明が見つけられる。 ・リフレクションは、実行時にオブジェクトの情報を参照して、それを元にオブジェクトを操作する方法 ・イントロスペクションは、実行時にオブジェクトの情報を参照して、その情報にさらに変更を加える方法 上の説明では、イントロスペクションの方がより強力で、実行時にプログラムその

先日紹介した『オブジェクトデザイン』出版のタイミングで著者Wirfs-Brock氏が来日していたのだが、光栄にも出版打ち上げの飲み会に参加させていただいた。そのときの様子は、著者のブログでも紹介されている。 http://www.wirfs-brock.com/2007/09/notes-from-my-japan-book-tour.html Wirfs-Brock氏と話をした中でいくつか面白い話題を聞けたので、簡単にメモしておきたい。なお、私は英語がそんなに得意な訳ではないので、間違ったことを書いているかもしれない。その辺を差し引いて読んでいただきたい。 やっぱりU.S.ではOOがさかん？ 私は日本と英語圏とではオブジェクト指向に対して温度差があるのではないかと思っているので、U.S.のオブジェクト指向の大家であるWirfs-Brock氏にそのことを聞いてみたが、やはりU.S.ではオブ

少し前のことだが、.Net Rocks! というオンライントークショーのサイトに『Domain-Driven Design』の著者Eric Evansのインタビューが上がっていたので、今になってiPodに入れて通勤の行き帰りに聴いている。 http://www.dotnetrocks.com/default.aspx?showNum=236 インタビューの中で非常に印象的だったポイントを2つ、覚書として書いておきたい。 - DDDだからといって、全部ドメインモデルで構築するものだと思い込むのは間違い - 重要なのは、開発手法としてのアジャイルではなくて、ビジネス本来のアジャイルさ（変化のスピード）についていくこと Martin Fowler, Eric EvansDomain-Driven Design: Tackling Complexity in the Heart of Softwa

私の本『ソースコードリーディングから学ぶ Javaの設計と実装』では、Javaのソースコードを読む際にはまず「ソースコードの地図」となるパッケージ図を描いて、そのパッケージ構造を把握してから読むことを薦めている。 パッケージ図を使って依存関係まではっきり把握するのがベストなのだけれども、実際にやってみるとパッケージが膨大にあって描ききれない場合や、依存関係が複雑に入りくんでいて明確な構造を見出せないことが多い。その場合は、単にディレクトリの階層構造を表すような図を描くだけでもいいと説明している。 上記のように素っ気なく描くのもいいのだが、パッケージ構成をマインドマップを使って描いてみるのはどうだろうか、と最近ふと思った。さっそく試しに、JRubyソースコードのパッケージ構成をマインドマップで描いてみた（ツールにはFreeMindを使った）。 かなりいい。マインドマップは空間を上手に使うので

ouobpoさんのブログテーマ、「設計」の記事一覧ページです。

Eric Evansの書籍『Domain-Driven Design』は、ドメインモデリングやピュアなオブジェクト指向開発の指南書として誉れ高く、ドメインモデルベースでアプリを開発したいときはぜひとも一読したい本だ。このようにDDDは、1アプリレベルのドメインモデル構築に関するものと思われがちだが、実際はその後半部分は単なる1アプリのレベルを超えた話になっていて、アプリケーション統合（EAI）やSOA、エンタープライズアーキテクチャにまで広がる射程をもった設計思想を語っている。 Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software SOAはいま大流行しているが、SOAで本当に重要なのは、メッセージングやWebサービス、ESBを使うといった技術的な問題などでは全然なくて、サービスベースのア

最近のJavaフレームワークは、アノテーションを乱用しすぎだと思う。アノテーションが大好きなプログラマも多い。 たとえば、EJB 3.0 はアノテーションでEoD（Ease of Development）を実現したと言っているし、JUnit 4 はメソッド命名規約からアノテーションベースのフレームワークに切り替えた。Google Guice はアノテーションを使ってDIコンテナを作っている。 （話題とは関係ないが、Guiceについては、シンプルだとか速いとか、そういった部分で評価されているが、他のDIコンテナに対する最大のアドバンテージは、依存性設定時の「流暢なインタフェース 」にあると思う。これは実際設計しようとすると、結構難しいらしい） こうした流れを見ていると、アノテーションを使うのが最先端のベストプラクティスのように見えてくるが、本当はそんなことないと思う。単に、Java言語でアノ

今オープンソース開発で旬の組み合わせは、Eclipse + Maven2 + Subversionだろう。OSS開発者の間ではすでにこの組み合わせがデファクトになっているが、通常のシステム開発でも今後だんだんと浸透してくるだろう。 MavenプロジェクトをSubversionにインポートする場合は、プロジェクト一式をすべてリポジトリに突っ込んでしまうと、Mavenコマンドを実行する度にファイルが更新されてしまってバージョン管理が非常に面倒なことになる。以下のファイル／フォルダはMavenが頻繁に更新するリソースなので、svn:ignoreプロパティを設定してバージョン管理から外した方がよい。 ・ .classpath ファイル ・ target フォルダ まず .classpath ファイルは、「mvn eclipse:eclipse」コマンドを実行する度に（pom.xmlの変更がなくても