リスト：システム開発 を表示しています。（全 11 件）

デザインパターンを世に知らしめるキッカケになった本。誰もが名著だと認める一方で、説明の仕方が難解だとか、具体例が適切でないとかGUI関連のものに偏っているなどとも言われます。特に「デザインの再利用」という視点が強調されているため、説明がやや抽象的に進む感はあります。しかし、世の中のパターン絡みの本はほとんどすべて本書をベースに記述されていますから、本家本元にチャレンジする価値は高いのでは。最初の部分を除けば、基本的にパターンのカタログなので、本書を最初から順番に読み進める必要は一切ありません。最初に書かれているFactory絡みのパターンを理解するのに違和感があったら、もっと後に書かれているObserver、Command、State、Mediatorといったあたりへ飛んで読み進めるとより楽に読ませると思います。（鈴木純一 / 2002-11-30）

開発にオブジェクト指向言語を使用する大きな利点の一つはクラス(階層)の再利用性であるが、現実にはそのようにクラス設計をする事は難しい。本書は再利用性を念頭に置いてクラス設計の手法(デザインパターンと呼ぶ)を経験に基づいて体系化した名著である。Javaをご存知の方は、Javaの各クラス・ライブラリ階層が本書のデザインパターンと酷似している事にお気付きであろう。
本書ではデザインパターンを大きく次の三つに分けている。
(1) 具象クラスを生成するための抽象(インタフェース)パターン
(2) 構造に関するパターン
(3) 振舞いに関するパターン
例えば、(3)で説明されるIteratorパターンはJavaでその名前のまま出て来る。また、(1)で説明されるFactoryパターンが(呼称はともかく)恐らく一番ポピュラーな手法で、具象クラス群の生成を念頭に置きながら、特定の具象クラスに依存しない真に共通な要素を抽象的に定義するパターンである。
本書の内容は学術的に導いたものではなく、経験則に基づいたものだけに実践的である。それでいて、体系的に美しい。機能的に優れたものはデザインも美しいという見本のようである。本デザインパターンの考察にあたっては、建築学を参考にしたというのも面白い。本書を順に全て読む事は容易ではないが、本書の内容を身に付ける事で具象化や継承によるクラスの再利用性が格段に向上する事請け合いである。オブジェクト指向言語を使用してプログラミングをする方にとっては必読と言って良い名著。（紫陽花 / 2007-04-27）

確かにこの本は予備知識なしに読むのは難しいですね。
まず、"デザインパターン"とは何かということを、そしてその記述の仕方(パターン名、問題、解決、結果)を第1章で説明されていますが、事前に知っておいたほうが読みやすいと思います。
第2章ではLexiというTexに似たドキュメントエディタのなかにどんなデザインパターンが使われているか書かれています。個人的にもデザインパターンを説明するにはテキストエディタや描画エディタが最適だと思い、2章も押さえておくと以降も理解しやすいです。
第3章以降でやっとそれぞれ(生成、構造、振る舞い)のデザインパターンが紹介されています。"生成"、"構造"、"振る舞い"というのが何を意味しているのか初めはよくわかりませんでしたが、各パターンを見ていくうちにこの区別の仕方が理解できます。
ただし各章を順番どおりに読んでいくのではなく、後へ先へページを何度もめくっていく中で理解していくことができるでしょう。
「デザインパターン」を学ぶ上で、結城浩氏の「Java言語で学ぶデザインパターン入門」やW.J. ブラウンの「アンチパターン―ソフトウェア危篤患者の救出」もお勧めです。（sire / 2005-09-27）

この本はデザインパターンのバイブルとして名高く、ソフトウェア技術者は一度は目を通すべき本でしょう。
しかし、読みやすくは有りません。例や参照している文献はいかにも研究者向けの難解なものが多いし、本題とは関係のないところで躓くことも多いです。それでも辛抱して読む価値はあります。判りやすさを優先した本は他にあるのですが、この本のようなパターンの「深い」情報を提供してくれる本が他にないからです。
原著が出版されて7年、主流の言語も移り変わり、OOPの図の表記もOMTからUMLに変わりました。そろそろ、深さのレベルを保ったままより判りやすく改訂した第2版がでれば良いなと思います。 （中村拓男 / 2002-09-05）

すべてC++ベースで論じてあり、Javaに関してはC++から変換したJavaコードしかない、よってJava特有の実装上の考慮点は自分で気づかなくてはならない。これは本書の責任ではなく、GoF95も6年の歳月による経年劣化ともいえる。UML表記も然りで、UML1.1以前の表記なので、多少本書のクラス図の書き方に目を慣らす必要がある。だが基本的教科書として、今なお、必須の書だろう。（nemo_kaz1 / 2001-11-30）

他の方もおっしゃっていますが、１～３章までは必読ですが
時間のない人は辞書的にも使えると思います。
ただ、すべてを一読しておくと、明日行うコーディング等にも
役立つ情報が多々ありますので、ぜひ一読することをお勧めします。
目から鱗が落ちるようなサンプルの宝庫です。（森　博之 / 2004-11-27）

この本は著者のXPでのリファクタリングの経験をカタログ形式でまとめたもので、ソフトウェアを少しずつ日々改善し、ソフトウェアが肥大化が修正を困難にしないようにする小さな手法の集まりを紹介しています。ソフトウェアの構造に日々手を加える(部分的な再設計の)ための、問題点の発見の仕方、直し方がカタログ化されています。
書いてあることの個々の内容は比較的単純なものばかりですが、まずい設計が示唆する問題点、改善による効果、リファクタリングが可能な条件、リファクタリング時に見落としがちな点の指摘などが十分に書かれていて、リスクと効果をよく考えながらリファクタリングが出来るようによく配慮された内容になっています。プログラミング初級者にとって、とても勉強になる内容だと思いますが、経験を積んだプログラマにも日々のプログラミングのチェックリストとして非常に役に立つのではないかと思います。
JAVAでかかれているため、C++を使っている人には多少違和感がありそうですが、.NETプログラミングにはうってつけの内容だと思います。（中村拓男 / 2002-11-10）

達人プログラマ、ソフトウェア職人気質も読みました（ただの流行り好きですね・・・）が前二書がメンタルな部分が多いのに対し、この本は非常に実践的です。
5章まででリファクタリングの意味を知り、後はリファレンス的に手元に置いておきたい本です。サンプルコードが多く明快な解説がされているので詰まったときに調べるのに最適だと思われます。（木下牛 / 2003-04-10）

リファクタリングの技法が非常にいっぱいつまっていてとても役立ちます。
通して読むのは1章から3章くらいまでで、後は辞書引きの方が良いでしょう。
1章から3章までのswitch文をStrategyパターンにもっていくやり方はぜひ身に付けて下さい。
リファクタリングも繰り返し行っていけば、不吉な匂いがするコードを書く前に気づき直すこともできるようになると思います。
直接生産性に影響する技術ではありませんが、保守がしやすく、すっきりとしたコードを書けるようになるので1度読んでみることをお薦めします。（貨物列車を止めた男 / 2004-10-19）

リファクタリングするための個々のテクニックのカタログを説明する
前に、それらを適用するストーリーを例示する章がまず最初に用意さ
れています。そのため、第１章さえ読めばやりたいことの本質が会得
できるので、非常にストレスなく読めます。（この構成は、ＧＯＦの
デザインパターンや、ランダル・L. シュワルツ の「初めてのPerl」
に共通する方法です）
導入の章さえ読めば、個々のリファクタリング技法の節を１節ずつ電
車の中、空き時間等に少しずつ読んでいくことができます。途中の節
から気軽に再開できるので、忙しくて読めない時期があっても最初か
ら読み直しにならない所が嬉しいです。
順番によまずとも拾い読みでも構わないし、もっと言えばカタログだ
から全部読破しなくてもいい、と割り切れるのがいい所です。なんと
なく持ち運んでいつのまにか、読み終わってしまいました。
ファウラーの本の中では、アナリシスパターン（挫折しました）、
ＵＭＬモデリングのエッセンス（若干難しかった）と比べて、
極めて読みやすく買って無駄になることがない本だと思います。（悩み多き頭でっかち / 2002-11-17）

リファクタリング時に、こういう論拠で、こうしたら、
デザインパターンになりました、という具合に、
具体的なサンプルを通じて解説してくれます。
先人のノウハウの固まりだから、設計の段階から、
うだうだせずにデザインパターンを使おう、という意見に、
何となく違和感を感じている人には、
特に、読む価値のある一冊だと思います。（palemoon / 2005-09-16）

この本は、リファクタリングによって設計を改善して行く際に、デザインパターンのエッセンスを取り入れて設計を良くしていく道筋を取り上げています。
最初からデザインパターンを使うのではなく、リファクタリングによって、段々とパターンに近づけていく様を、「先輩とペアプログラミングしている」かのように読み進められます。
『オブジェクト指向における再利用のためのデザインパターン』、『リファクタリング』の両書を先に読んでおけば、本書の内容はすんなりと理解できるはずです。（ / ）

～リファクタリング、という言葉を意識するようになったので、買ってみたのがこの本です。ぼくはデザインパターンはよく知りませんが、例をあげて丁寧に方法を示してくれています。本の中では、なぜリファクタリングが必要なのか、また、デザインパターンの適用の仕方を、筆者の経験を交えて説明してくれます。例として、問題のあるコードについて、一般的なデ～～ザインパターンの適用手順と、具体的な適用例を示してくれるのでとてもわかりやすいです。むやみにデザインパターンを適用するのではなく、状況にあわせてリファクタリングを行うことを教えてくれます。～（ / ）

単なるデザインパターンの説明だけの本よりは理解しやすいです。
どこもかしこも「デザインパターンを使えばよい」ということではなく、
「小さい金槌でこんこん叩けばいいところを大きな金槌を振り回すよう
な状況でデザインパターンを使うのはよくない」という内容の記述が
あり、はっとしました。
自分を含め、勉強したての人ほどついその傾向があるとおもいます。
じっくり読むことでリファクタンリグもデザインパターンへの理解も深まります。（ / ）

内容だけであれば星4～5です。
決して目新しいことが書いてあるわけではありませんが、知識の整理や体系付けには最適です。業務経験者であれば少なくともこの中のパターンのいくつかは使ったことがあると思いますが、はたして採用したアーキテクトが最適であったか、改めて考えさせられると思います。
この手の本としては仕方ないですが日本語訳は難ありです。多分これを読むぐらいの方なら原文もある程度想像がつくとと思いますが、訳さなくてもよいところまで無理に訳してあったり、機械的に訳してあるだけで、前後の意味がおかしいところがあります。
日本語訳で一通り読んで、原文を手元に置いておくのも手かもしれません。（amx-004-2 / 2005-05-23）

とにかく訳が良くないです。
パターン名だけでも、軽オフラインロック(Optimistic Offline Lock)、重オフラインロック(Pessimistic Offline Lock)、緩ロック(Coarse-Grained Lock)等、原文の意味が全く伝わってきません。極めつけは、データ変換オブジェクト(Data Transfer Object)、どうして「変換」なのか全く理解できません。
もちろん文章も意味が通らない訳が散見されるため、どんなに読み込んでもとても理解できるとは思えません。
しかし、原書は間違いなく良書なので、原書を購入することをお勧めします。（kariya_mitsuru / 2009-04-12）

～ずっと英語版の話は飛び交っていて、訳出をずっと待ち望んでいたのですが、ようやく出ました。
ファウラー氏でパタンといえば「アナリシスパターン」ですが、この本はそれほど読みにくくはありません。「UMLモデリングのエッセンス」ほど読みやすくもないですが。
読み心地は「リファクタリング」に似た感がありました。
出てくるパターンは、「よくある～～ような作り」を整理したものが中心で、パターンとして整理し対比する事でそれぞれのメリットとデメリットが浮き彫りにされています。
既に見知ったものがパターンとして整理されて、おぼろげだったものにくっきりとした輪郭が浮かび上がるような、そんな感覚を何度か覚えました。
最後に茶々ですが...
著者本人のblikiに曰く、この本のテーマはエンタープラ～～イズアプリケーションの設計方法で、エンタープライズアーキテクチャはまた別の話との事で、エンタープライズアーキテクチャについては特に触れられていません。
な訳でエンタープライズアプリケーションのレイヤ化は中心的なテーマですが、エンタープライズアーキテクチャのレイヤ化なんて触れられていません。残念。～（ / 2005-05-08）

先ずはタイトルどおりの感想を強く持ちました。
内容は文句無しにすばらしく、読んで損はない本だと思います。しかし日本語を理解するのに多大な労力をするので、それなら原書を読むべきだったと後悔するかもしれません。これが原書で読んでいたら文句無しに星５つだったと思います。
内容的に目新しいことがあるわけではく、経験を積んだエンジニアなら誰もが悩み経験してきたケースに対するベストプラクティスを形式知にしたカタログだと思います。
なので、読んでいくと昔悩んだことがパターンとして切り出されていて、それを見ると”うむうむやっぱりそうなるよねー”と自分の過去の設計を振り返ったり、新たな発見があったりと読んでいて楽しかったです。
またこの本は、若手のエンジニアに一番に読んでもらって、まずはパターンのボキャブラリを増やしてほしいのですが、ある意味あたりまえのことのカタログなので経験がないとその価値に気づかないことや、日本語訳の文面を別の意味で取ってしまう恐れがある気がします。それでもこの本は新人・若手に是非読んでもらいたいお勧めの一冊だと思います。（プロモデラー / 2005-08-03）

本書は2部構成となっており、前段が概論で後段は50件にも及ぶパターンのカタログとなっている。まず第１部の概論をじっくり読みながら、文脈に登場するパターン(ゴシック表記してある)について第2部の記述を確認し、第1部に戻ってさらに読み進むというのがよい。カタログだけを一気に読み下しても、どういう文脈でどんな得失があるかの論点がつかめなくなる。
プログラミング経験がメインフレーム系や制御系しかないという人たちにも、自分たちのソフトウェア構造ではどのパターンの組み合わせになっているかが見えてくる。Visual Basic環境でSQLサーバなどから得たレコードセットを中心にプログラムしている人や、WebアプリケーションをPerlで書いている人たちも同様である。もちろんJ2EEやXML Webサービス環境にある人たちにも、分散オブジェクトの使い方やO/Rマッピングについて、いくつかのパターンから有効な示唆が得られるだろう。各々の開発環境におけるソフトウェア構成を捨てることはできないにしても、それにはどういう面では強みがあり、どういう弱みがあるかは本書により確認できる。
概論の中では、トランザクションの特性についてとデータの並列操作についての話題もきちんと説明されているので、プログラミング初心者や、これまであまりそうしたことに注意を払わなくてすんでいたプログラマにとっても、大いに参考になる。
メインフレーム系や制御系にいる人たちは、クラス図およびシーケンス図の意味や、リレーショナルDBにおけるテーブル間の関係については、きちんと理解しておかないと何がありがたいのか解らないかも知れない。そういう方たちには、これを機会にオブジェクト指向やデータ中心アプローチの入門書(初心者向けという意味ではない。プロフェッショナル向けに、記法とか文法とか細かいところにあまりこだわらず「何に着目するのか、何故そうするのか」について簡潔に書かれたもの)を読むことをお奨めする。（jojo / 2006-12-28）

あなたは以下のような謳い文句をどこかで聞いたことがありますか?
・オブジェクトとはデータと振る舞いを持った「もの」である
・カプセル化とはデータを隠蔽することである
・オブジェクト指向言語では継承を使用することによって再利用が促進される（差分プログラミング）
・オブジェクトとは現実世界における実体であるため、名詞と動詞を抽出することで適切なクラス設計を行うことができる
この本は本来あるべきオブジェクト指向設計においてはこれらが適切ではないということをデザインパターンを使って解説しています。
この本を以下の方に薦めます。
・デザインパターン本（GoF本を含む）を読んだがいまいち理解できなかった方（オブジェクト指向初級者）
この本はデザインパターンの解説だけではなく、その元となっているオブジェクト指向原則についても説明しています。そのため他のデザインパターン本よりも有益でありかつ理解しやすいものとなっています。
・オブジェクト指向はある程度理解していると考えている方（オブジェクト指向中級者）
オブジェクト指向原則やデザインパターンに対する知識の整理が可能となります。「それについては知っていた」という箇所が出てきた場合には自分を褒めましょう。（この逆は、「もしかしたら自分はオブジェクト指向初級者だったのかもしれない。」です。）
また、この本が他のデザインパターン本よりも理解しやすいのは以下の理由もあると思います。
・著者がデザインパターン講義を行っている講師である
理解するのが困難な箇所について何度も解説を行った経験があり、そのためその解説が洗練されている。
・翻訳がすばらしい
村上雅章さんの翻訳は本当にすばらしいです。
オブジェクト指向及びデザインパターンについて書かれた本を今までに多く読んできましたが、この本が一番分かりやすく有益であると思いました。（kazu_m / 2006-01-25）

僕はこの本によってオブジェクト指向への「パラダイムシフト」を経験しました。結城浩さんの「java言語で学ぶデザインパターン入門」を理解した後に読むとちょうど良いと思います。
本書では、デザインパターンの中でもオブジェクトコンポジション系のパターン（strategyやbridgeなど）に特に焦点が絞られています。問題領域の中の「可変領域」と「不変領域」を見極めることの重要性が何度も何度も強調されます。このプロセスによって、堅牢な骨組みと柔軟な構成要素を組み合わせたアプリケーションを構築することが可能となり、それはつまり保守性と拡張性の両者に優れたシステムをつくることに他なりません。
ここまで初学者にわかりやすく、しかもオブジェクト指向の本質をとらえて解説した本はないと思います。（中島達彦 / 2008-02-28）

「GOF 本」や「結城本」でデザインパターンを学んだものの、
実戦で全くパターンが使えない・・・
いや、目の前の問題に対してどうパターンを使って解決すればいいのか
そのコツが全く判らないという開発者は、非常に多いのではないでしょうか？
この本は、著者が実際にアプリケーション設計を行った際、
設計上の問題をどうデザインパターンを使って解決していったか、
その具体例を示しながら、各パターンを判りやすく解説するとともに、
オブジェクト指向の真髄・・・オブジェクト指向の何たるかを
しっかり掴めるよう判りやすく解説してくれてます。
他の方も指摘されてるとおり、まさに「タイトルに偽りなし」の名著です。
日経BPから発行している「パターン指向リファクタリング入門」と合わせ読むと
パターンを実戦でより効果的に利用できるようになると思います。お勧めです。
（風の又兵衛 / 2008-10-19）

題名は少し原作と変わったが、デザインパターンについての解説書。
著者が過去に携わった業務における、著者の誤った設計を示し、
デザインパターンについて説明しながら、それを用いて
現在最善と思われる解決策を深い考察とともに説明している。
それでいて、理解しやすくオブジェクト指向の原則を説明しながら
しっかり各パターンについて説明している。
これは、よくある『わかりやすい、、、』『はじめての、、、』
のような誰でも書けそうな上から目線の書籍とは全く違う。
一流の設計者が自分の経験を基に最善の設計についての追求を
続けた過程が述べられており、より技術者好みの深い考察が多い。
（必然的に、リファレンスとしての用途では使えない。）
著者はおそらく、自分の過去の仕事に対する検討や反省を続けていた
のだろうという印象を受けた。このような書籍を多く読むことで、
設計に対する自分なりの哲学を身に着けることができるだろう。
特に秀逸だと思ったのは、Bridgeパターンの説明である。
今までピンとくる解説がなく曖昧に覚えていたものが、すっきりと
理解できた。他の方に説明するときは、この本の例を使うことにしている。
プロとして設計に携わっているならば必読だと思う。（ひにもの / 2008-07-28）

この本は上級者向けでないが、かといって初心者向けでもないと思う。
これまでデザインパターンの書籍を読んで今ひとつ理解できなかったり、腑に落ちなかったり、もしくは挫折したことある人に、この本をお薦めしたい。全部とは言わないが、かなり頭の中がスッキリするし、これまで感じていた疑問や不理解が自分だけじゃないことがわかるはず。
最初はこの本に慣れるまで違和感を感じるかもしれないが、Facade、Adapterパターンを読むころには購入した価値ありときっと思うはず。著者の並々ならぬ自信と情熱が伝わってくる。また、翻訳もすばらしいので安心して最後まで読める。この本を理解できたならば、あとは実践のみ！？（はるちゃんのぱぱ / 2005-09-20）

オブジェクト設計やテーブル設計の良い参考書だと思います。
ビジネスアプリケーションに良く出てくる課題を、２５のビジネスパターンとして実践的に解説したパターンカタログです。
ビジネスアプリケーションの関心事の整理の枠組みとして、
・３つの基本オブジェクト
・業務レベルと方針レベルのレイヤ化
・横断的なな関心事
の３つの視点を提示しています。
まず、ビジネス活動に登場するオブジェクトを３つの基本タイプで考える。
Resource：経済的に価値のあるモノ。
Event ：経済活動で発生したコト。
Agent ：リソースの所有者、経済イベントの行為者。（ヒトまたは組織）
ＲＥＡパターン、日本語でいえば、モノ・コト・ヒト　パターンですね。
Ｔ字型ＥＲモデルの考え方に、経済活動の主体である「ヒト」の視点を追加したモデルです。
次に、経済活動の基本構造を、「業務」レベルと「方針」レベルにレイヤ分割する。
業務レベルは、経済活動の基本をなるモデルのレイヤ。
異なる経済エージェント間の取引である「交換プロセス」と、自分が所有するリソースに対する生産や消費のモデルである「変換プロセス」としてとらえます。
経済活動の領域を、他者との取引と、内部の活動にわけている。本質的に別のモデルを適用すべきと言っている。
方針レベルは、経済活動を制御するビジネスルールをモデル化するレイヤ。
「契約」や「予約」が企業活動を駆動する。
企業は「スケジュール」にそって生産活動をする。
顧客や商品の「タイプ」によって、異なるビジネスルールを適用する。
モノとモノとの関係（連結）。
ヒトとヒトとの関係（責任）。
ヒトとモノとの関係（監督）。
三つめのモデリングの視点が「振る舞い」のモデリングパターンです。
ビジネスアプリケーションに登場する、典型的な関心事を丁寧に取り上げている。
エンティティを「識別」する問題。「分類」するということ。
経済活動の「場所」と「期日」。経済活動の「記録」と「現在高」。
「説明」と「注釈」の違い。「通知」の問題。
．．．
最後に、これらのパターンを使って、具体的な業務への適用例を説明しています。
「現金販売」「返品」「貸与と賃貸」「融資」などの交換プロセスの具体例。
モノの「生産」やサービスの「使用」など企業内部の変換プロセスの具体例。
「購入注文」「保険」「輸送」など、サービス提供の約束とその履行の具体例。
ビジネスの基本パターンとモデリングテクニックの参考書として、私は、この本と　Domain-Driven Design: Tackling Complexity in the Heart of Software を、なんども読み返しています。（masuda220 / 2007-09-19）

アスペクト指向の説明って、なぜかロギングばかりなんだけど、この本はビジネスで扱う要因をアプリケーション群を横断するアスペクトとしてまとめあげてる。
ソフトウェアアーキテクチャの勉強には辛いけど、変化球好きにおすすめ。（gauchez / 2007-10-17）

マーチン・ファウラーの『エンタープライズアプリケーションアーキテクチャパターン』（PoEAA）では、
エンタープライズアプリの心臓部であるビジネスロジックの作り方には(1)トランザクションスクリプト、
(2)ドメインモデル、(3)テーブルモジュールの3パターンがあると説明されています。
複雑なビジネスロジック構築には、(2)のドメインモデルが一番いいと書かれているのですが、
PoEAAはアーキテクチャ全般をまんべんなくパターン化することに主眼が置かれているので、
ドメインモデルについてそれ以上詳しく説明してくれていません。
本書DDDは、ファウラーも推薦しているように、この「じゃ、ドメインモデルをどうやって構築すればいいの？」
を詳しく教えてくれる本です。基本的なOO開発方法をマスターし、ピュアなOOスタイルではないながら
アプリをきちんと作れるようになった中級以上のエンジニアが、今度は複雑なビジネスロジックをOOスタイルで
美しくかつ保守しやすい形で構築することを目指すときの必携書です。（ハナオ / 2006-06-16）

役に立つソフトウェアを作るには、問題領域（ドメイン）に詳しい人の知識を、コードに変換して、動くソフトウェアにすること。
この本は、そのためのテクニック、ノウハウ、パターンを満載したすばらしい設計ガイドブックです。現場で分析・設計をする方にぜひ読んでほしい本です。
４部構成になっています。
Part 1 : ドメイン駆動設計(DDD)の目指すもの。基本コンセプト。
Part 2 : モデリングの基本テクニック
Part 3 : ドメインを深く理解する（モデルのリファクタリング）
Part 4 : 大きくて複雑な問題を解きほぐす　
Part 1 は、考え方や用語の説明が中心です。ビジネスに価値をもたらし、利用者が喜んで使ってくれるソフトウェアを作るには、ドメイン駆動設計が効果的、という内容です。
Part 2 は、モデリングの基本要素、クラス・関連・パッケージの効果的な使い方のガイドです。これらの要素を細かいところまで気を配って使うことで、どれだけ、モデルが明快になるかを丁寧に説明しています。
なんとなく四角と矢印を描いているだけではダメなんだと、目からうろこが落ちる思いでした。
また、モデルと、Java や SQL の実装が直接関連している点の説明も具体的に参考になります。
Part 3 は、ドメインの表面的な理解、初期のぎこちないモデルをリファクタリングすることで、隠されていたドメインの知識、構造を明らかにしていく過程の説明です。
モデリングと設計を洗練させるための実践ノウハウが詰まっています。
Part 4 は、現実世界の複雑な問題への取り組み方の実践ノウハウ集です。
異なるモデルを元にしたシステム間を連携する時の問題の解決方法。
モデルが入り組んできた時の、関心ごとの分離の方法。
現実の複雑なアプリケーション開発に取り組む時のいろいろな解決パターンとそのトレードオフ関係が具体的に説明されています。
各章の最初に、その章の内容を象徴した写真が載っています。
最初は、ぴんとこない写真ばかりでした。
何度も読み返して、章の内容が理解できると、突然、写真の意味がわかった、という経験を何回もしました。
ほんとうに奥が深い本です。私は、何回も読み返していて、そのたびに新しい発見があります。（masuda220 / 2007-09-21）

This Book focuses on domain and domain logic.it also explains as that complex domain designs should be based on a model.（ / 2005-07-08）

「オブジェクト指向は利益を得ることを許してはくれるが、それをただでめぐんでくれるわけではない」と『UMLモデリングのエッセンス 第2版』で孫引きしたFolwer氏じしんによる、その言明に対する証明が本書である。
本書は、表記がOdel法であったり、訳文の読み辛さもあってか、Folwer氏の他の著作とは違って現場レベルでの浸透度はひまひとつのように思える。
が、言葉だけが独り歩きしている感の強い「モデル」「モデリング」(「オブジェクト指向分析」と呼びたければそう呼んでもよい)といった概念を、その作業過程(思考/試行過程)を示すことで明確にするという視点は他の類書にはない本書のアドバンテージである。
「パターン」と銘打ちながらも、いわゆるパターン言語、パターン・カタログ的な記述を行っていないことも、モデリングの過程を重視してのことだろう。
だから、本書は、一読してたちどころにそれを理解できるといったものではない。実際のモデリング・スキルの習得が、自分じしんで手を動かすことでしか達成できないのと同じように。
読者じしんが手を動かして、例題についてのオブジェクト図(クラス図だけでは不十分だ)を作成し、そのモデルを吟味する過程においてパターンの立ち上がる瞬間を、読者みずからが体験することなしに、本書に対する理解はありえない。自らが手を動かせば、本書の記述は何ら難解ではない。本文中の図がOdel法であることも逆手に取って、自らの手でUML化してしまえばよい。
本書で描かれている、現実世界に存在するものをオブジェクトとして捉える視点とその技術は一部の「モデリングおたく」が習得すれば良いというものではない(「アナリスト」が作成したモデル図を読み解いて実装に落とすのはだれ？)。そうでなくても「オブジェクト」に対する感覚(「クラス」に対する、ではない)をより鋭敏にするためにも、すべてのオブジェクト指向技術者にとって必携の一冊である。
附記: 旧装版のレビューでは「モデリングおたく向け」と、本書に対するよくある誤解のみがレビューとして存在していた。こんかいの新装版の発売を機に、擁護の意味も兼ねてレビューした。このレビューが一人でも多くの技術者がこの書を手にとり、実際に手を動かすことで本書に対する理解を深めてくれるきっかけになれば幸いである。（f451 / 2002-05-26）

いわゆる（デザインパターンのような意味合いでの）パターンカタログではありません。パターン的な形式で書かれている部分もありますが、結果としてのモデル（パターン）ではなく、どうやってモデリングするのかを（明に暗に）書いている部分がより重要だと思います。その過程を自分でなぞりながら読むと得るものが多いのでは。（鈴木純一 / 2003-08-03）

オブジェクトの世界では知らない人がいないのではと思われる
マーチンファウラーによる分析例の本
アナリシスパターンということで、パターン集ではなく、アナリシスつまり
分析の考え方を集めた本になっています。
構成は、まず概念モデルなどの説明があり
実際の分析例（責任関係、観測と測定、企業財務の観測、オブジェクトへの参照、
在庫管理と会計、会計モデルの利用、計画、トレーディング、デリバティブ
トレーディングパッケージ）が全体の４分の３程度割いています。
２部は分析を補足する説明として、アーキテクチャ、ファサードなどの解説
そして付録として技法・記法、パターン一覧が載っています。
一度は業務分析を行った経験のある方であれば、著者が何の意図でこのような
本を作ったのかがよくわかるのでは無いかと思います。まさに
分析例集の感はあるのですが、良く練られた分析では無いかと思います。
また、今まで、アナリシスとアーキテクチャの関係がいまいちしっくり
こなかった私にとっては、とてもわかりやすい本でした。
逆に、業務分析を必要としない人にとっては、難しい内容かもしれません。
目的には完璧なまでにすばらしい本なのですが、いかんせん
この本は高いです。お値段の点で評価が一つ下がっています。（親カッパ / 2009-03-05）

システムの開発プロセスにおいて、現実世界をいかにモデリングするか、という「要求分析」から「設計」につなげていく過程で一番重要なモデリング技術について語られた本です。
初めて読んだのはかれこれ５年ほど前になりますが、業務アプリケーションのシステム開発で、現実世界をモデリングする上で必要となってくる、責任、観測、測定、計画といった認識論的なテーマが扱われており、読んでいるとモデリングについてのイマジネーションが非常にかきたてられ何度読んでも飽きない本です。
私がマーチン・ファウラーに心酔するきっかけとなった本で、非常にお勧めです。
（上昇志向 / 2006-10-28）

　メタレベル（著者は意識レベルと呼んでいる）でのモデリングで抽象レベルが１ランク高いので広範囲なビジネスモデリングに役立つと思います。何度読み返しても味のある本だと思います。
（k-nagano / 2007-01-18）

確かに序文の翻訳はむちゃくちゃですが，その他の部分は他の技術書の翻訳と大差ないと思います．
本書の肝は文章ではなく問題を解いていくことにあります．必ず紙と鉛筆と計算機（コンピュータ）を手元に用意し，時間を掛け考えながら解き進めていくべきでしょう．読む本ではなく考える本です．
原文はこちらで公開されています．http://mitpress.mit.edu/sicp/（InTheDark / 2008-10-03）

大学の情報系というと、LispかPascalが基本でした。
本書のように、コンピュータ、プログラムの仕組みを親切に教えてくれるものをもっと早く知っていれば、脇道にそれなかったかもしれない。
計算機の仕組みと、プログラミングの基本技術について知ることができます。
名古屋アジャイル勉強会でも、しばしば話題になっています。
計算機、プログラムの構造が、いかに重要化がわかると思います。
最近、大学ではＬＩＳＰは流行らないと嘆いていた先生がおみえになりました。
ＬＩＳＰはアセンブラのようなものなので、情報科学系では。本書を使って１年で教えるべきだとお話しました。
海外の講義の映像が自由に見られるので、自習も可能です。（kaizen / 2008-05-01）

内容は文句なしに最高です。
とにかく考えながら読むのが楽しい本です。
PCにSchemeの処理系を入れてポチポチやりながらやってもいいと思いますし、
紙と鉛筆で、手でやってみても面白いと思います。
ですが、翻訳が最低です。
訳が良くない本とかはありますが、これは問題外です。
こんな翻訳がまかり通っているとは。
誰か、別の人に訳して欲しいところです。
本当は良い本のはずなのに、翻訳の悪さが一気に価値を下げています。
（ark / 2008-07-13）

「これ1冊でコンピュータのすべてがわかる本」ではありませんが、プログラマにとって必読の本です。この本で言う解釈(Interpretation)を理解すればプログラマにとって新たな道が開けるでしょう。scheme の言語解説に始まり、scheme 上で新たな言語を生成し、インタプリターを生成し、最終的にはコンパイラまで作ります。gcc コンパイラが lisp を採用している(?)意味がわかります。
この類いの本は他にありません。
日本語をよく読めば原文の意味もわかります。訳文（の評価）に惑わされずに上を目指すプログラマなら是非読むことをお勧めします。（りょうす / 2007-12-10）

原著を読んだほうがいいと思います。内容的にはかなり良いと思いますが、
誤訳が多い気がします。原文と比較してみましたが。。。（ / ）

インパクトのあるタイトルと黒々とした表紙から、ギーク向けの本と思ってました。
が、読んでみるとソフトな内容。
プログラマとして知っておくべき、気をつけるべき、そして実践するべき内容が上手くまとめられており、「そうそう、そうなんだよねー」とウンウンしまくり。
もっと早く読めばよかったという気もするが、若い頃に読んでも実感が湧かなかったろうな。
挿入されているお話も面白く、新人研修などの講師になったら話のネタに使えそうだわ。
（生徒がこの本を読んでいませんように・・・）（殿下 / 2007-05-02）

この本には、プログラミングの原則が、詳細かつ分かりやすく記述されている。
それらは、プログラミングをする上での、ごくごく当たり前の事柄なのだが、意外に実践できていなかったりする。
新人プログラマなど、とりあえずは動くものが作れるが、品質がいまいちな人たちに、最も読んでほしい本である。（卍 / 2007-02-21）

タイトルは「達人プログラマー」だが、実際の内容は、
システム開発に携わるエンジニアが心がけておくべき内容だと思う。
この本に以下のような記述がある。
ソフトウェアの無秩序さは加速度的に増大する。
そのため、質の悪い設計を行わない、または修正することが出来ない理由を明記するなど最初の無秩序を作らないことが重要である。
これはごく当たり前のことだが、分かりやすい例で書かれているため、知識として身につけ易くなっているところがこの本の良いところだと思う。（3cr / 2003-12-25）

もっと早く読むべきだったと後悔しています。
達人の仕事振りを説いた１冊です。
この本のキーワードとなる言葉は、
１、割れ窓をなくす
２、蛙の煮物
３、伝達しよう
４、ＤＲＹ原則
５、直交性
６、自動化
７、絵画の制作のやめ時を知る
プログラマーでこの本を読んでいなかったら、
急いで読みましょう。
それ位、知らないと恥ずかしいです。（なか / 2007-04-23）

この本には、質のよいプログラムを書くことが出来るようになるよう、
70個のヒントを示しながら、良いプログラミングの方法を教えている。
自分も早くこのような本にめぐり合えていたら、と思う。
ヒント38：抽象概念はコード上に、詳細はメタデータ上に書くこと、
など、示唆に富むヒントから基本的なヒントまで、すべて為になった。
いろいろなレベルの方にお勧めできる本です。（ / ）