パターンのこと?と疑問に思う方もいらっしゃると思いますが、ここでは両者をまとめて解説します。誤解をおそれずに言うなら、両者にはたいした違いはありません。この「たいした」の部分のについては、説明を読んでいただければわかるかと思います。なに?直訳すれば工場ですよね。実際に工場なんですけど、何の工場か?もちろん、オブジェクト指向のハナシをしてるんですから、決まってますよね。オブジェクトのインスタンスを、生成する工場なわけです。ファクトリとかなわけです。それをやるとなにが嬉しいのか?ファクトリを使用することで、オブジェクトのインスタンスを作る箇所での、依存度を下げることができるのです。具体的に見てみましょう。風の擬似コードを使って説明していきます。クラスのコンストラクタに直接アクセスしているからです。メソッドを変更しないと、それに対応することはできません。インタフェースで依存度を下げてみるとりあえず、依存度を下げるための一歩として、インタフェースを用意しましょう。インタフェースCの実装}クラスBは、以下のようになるでしょう。}}しかし、これだけでは、依存度はたいして下がっていません。根本的な問題は、コンストラクタへのアクセスにあるのです。問題はコンストラクタコンストラクタの呼び出しを、コードのいろんなところに散りばめることは、コード全体に接着剤をぶちまけるようなものです。アプリケーション全体が強力な依存性で接着されて、岩盤のように固く、変更困難になってしまいます。依存度を下げる役には立ちません。コンストラクタの呼び出しを、排除する必要があります。どこかしらでクラスを明示してコンストラクタを使用しなければ、オブジェクトを生成することはできませんね。リフレクションでも使えば別ですが、それはそれで、多用するのは問題があります。ファクトリを使って依存をなくすコンストラクタの呼び出しが避けられないのなら、いっそ一箇所にまとめて隔離しましょう。それがファクトリってわけです。実装しているとします。インスタンスを生成して返します。メソッド内に隠蔽されました。実装しているものならなんでも、変更なしに扱うことができます。存在を匂わせるものは一切ありません。ソースから一切姿を消してしまうはずです。このように、ファクトリを使用すれば単に依存度を下げることができるだけでなく、依存をまったくのゼロにすることができます。コンストラクタを隠蔽しているだけでなく、実は大きな可能性を秘めています。サブクラスを返すこともできます。関係がないクラスを返すこともできます。関係のない、別のところで決めることができるのです。メソッドで返すようにすることができます。これぞまさに自由!実装上の自由というのは、依存性がゼロになったときにだけ生まれるものです。インスタンス生成に自由をもたらすことが、ファクトリの目的です。いずれも言わずと知れたデザインパターンの代表格です。これらの違いのわかりにくさが、なんとなくファクトリ全体をとっつきにくいものにしているような気がします。つの部品というような関係です。その境界がどこにあるのかについて、混乱しやすいのではないでしょうか。わかってしまえば結構簡単なものです。パターンとはここまでで書いてきた擬似コードの全体像を見てみると、こんなかんじですね。インスタンスの生成を委譲しています。パターンそのものです。パターンとはファクトリは、オブジェクト生成に自由をもたらすとは、すでに言いました。実際に生成されるオブジェクトが切り替わるように変更してみましょう。変更することなく、このクラスを扱うことができます。文などの条件分岐を使用することもできますが、条件分岐が増えることはコードの複雑性の増大に直結してしまいます。ここではサブクラスによって切り替えることにします。インスタンスを生成します。クラスのサブクラスを作るだけで対応できるようになったことが、おわかりいただけるでしょうか。パターンの一つの例でもあります。依存が取り除かれました。いうように各インスタンスに対応するファクトリサブクラスの中に、依存性が閉じ込められたわけです。行で済むのに比べると、ものすごい量です。これは単なる擬似コードなので、できるかぎり見やすいように、シンプルに書いたものです。たしかに、このような極シンプルなケースであれば、ファクトリよりただの条件分岐のほうがベターな場合があります。実際のアプリケーションのコードでは、こうはならない場合がほとんどでしょう。プログラミング向けテキストエディタの、シンタックスハイライティングを実装するとします。キーワードやリテラル、コードブロック、コメントなどシンタックスの種類はたくさんありますが、どれもプログラミング言語ごとに内容は違います。このたくさんのシンタックスを、それぞれオブジェクトであらわすとしたらどうでしょうか。(実際にそれが最適解かどうかは別としてです)プログラミング言語というのは、移り変わりが激しいものです。日々生まれては消えていくし、昨日は誰も知らなかった言語が今日はメジャーになっているかもしれません。条件分岐でいちいちオブジェクトを切り替えていたとしたら、アプリケーション全体に渡って同じような条件分岐が散りばめられることになります。条件分岐を採用してしまったら、新しいプログラミング言語に対応するのは、非常にコストがかかる仕事になります。いう場合、全てのシンタックスオブジェクトの生成を一手に引き受けるファクトリを用意するというのも、効果的な手段です。することで、ファイルタイプやユーザの選択によってファクトリが切り替わると、ハイライティングルールが一挙に切り替わるようにできます。作ることと、新しいファイルタイプにそれを関連付けること、そして選択オプションを追加することだけです。それ以外の既存のオブジェクトについては、全く心配する必要がありません。フィールの切り替えなどでも、ファクトリを利用することができます。ミドルウェア、フレームワークの種類によってアイソレーションレイヤ全体を切り替えるようなファクトリを用意することで、ポータビリティの大幅な向上を実現するというような、大規模な仕組みにも応用することができます。パターンの違いの説明をわかりやすくするために、大幅に改訂しました。ファクトリの応用についても触れてみました。変更することなく、このクラスを扱うことができます。ライフタイムにどのオブジェクトが責任を持つべきかによって決まります。以下、これについて詳しくご説明しますが、だいぶ長文になってます。よろしければ、お付き合いください。操作するためのクライアントアプリケーションを作りたいとします。サポートしてみましょう。サポートするのが大変な作業になるのは、想像に難くありません。パターンの適用を検討してみましょう。共通して必要ですが、実装の内容はまちまちです。いちいち意識しなくてもいいように、共通のインタフェースを用意します。やりとりするオブジェクトは、そのインタフェースを実装します。パターンを適用してみます。追加するオブジェクトは、以下のとおりです。操作するオブジェクトを生成します。それらのオブジェクトもまた共通のインタフェースをそなえていて、ビジネスロジックからはそれを通して同じように操作できるようになっているはずです。名前が示すとおり、これらは一連の処理のコンテキトを形成するものです。ツイートになるという意味で、これらのファクトリが生成するオブジェクト群はコンテキストなのです。処理対象とするかが決まるときです。選択のしかたは、いくつか考えられます。取得した内容をマージしたものを表示し、投稿の時点で、どれに投稿するかをユーザが選択する。投稿先をあらかじめ設定できるとか、いろいろやりかたはあるでしょう。生成すればいいでしょう。ログインボタンのクリックで決まるのであれば、そのイベントから直接コールされるビジネスロジックで生成してもいいと思います。この方法では依存性はまだ僅かに残されることになりますが、同時に導入される複雑さに見合う効果が見込まれないのであれば、これ以上の依存性の排除にこだわる必要はありません。インスタンス化すべきかもしれません。ライフタイムがほぼ一致することになるでしょう。インスタンス化し、そのライフタイムに責任を持ちます。ライフタイムを管理する責任を任せるべきかもしれません。インスタンスを生成する処理はコンテキストマネージャ内に隠蔽され、ビジネスロジックからは完全に隔離されます。このように、アプリケーションの設計はいつもケースバイケースです。パターンは主に依存性の排除のために利用されます。なんのために依存性を排除するのかというと、複雑さの抑制とモジュール性の確保のためです。依存性の排除は複雑さを増大させる傾向があるものです。これ以上小分けにする必要がないところで依存性排除のためだけのコードを追加すると、ほとんど恩恵はないのに複雑さだけが増えることにもなりかねません。ツールページビューの合計オススメの書籍Groovy言語仕様の解説書です。対象バージョンはだいぶ古くなりましたが、いまだにこれだけまとまった情報源はないと思います。単なる解説にとどまらず、そのマインドまでも伝える良書です。この本の著者たちは、Groovy開発者本人たちです。仕様一つ一つの意図が、開発者本人の口から明確に述べられているわけです。Groovyをマスターするには、この本でGroovyのコアを学び、最新情報や、エコシステムを構成する周辺技術についてはWEBで情報を漁るのが、いいやり方ではないでしょうか。オブジェクト指向設計の原則など、ソフトウェア開発の基盤となる重要な知識がまとめられています。実際の開発の流れに沿って、デザインパターン適用の実例をまじえつつ、アジャイル開発の実際が説明されています。タイトルは「アジャイルソフトウェア開発の奥義」となっていますが、「アジャイル」はただのアイキャッチではないでしょうか。ほんとは「ソフトウェア開発の奥義」。アジャイルな開発をする人はモチロンのこと、そうでない開発をする人にとっても、必須の知識が満載です。現場で即役立つテクニックについて、具体的な例をまじえながら丁寧に解説してくれています。書かれていることを、そのまま実践するだけでも、それなりの成果を得ることができます。イマドキ、バージョン管理が全くないプロジェクトはまずないと思います。バージョン管理の概念について、基本的なところを知らないまま、単に手順書に従っているだけの人は、意外と多いようです。ユニットテストはどうでしょう?本当のコツも、正しいやり方もよく知らないうちに、挫折したり断念したりしている人が、いまだに多いように思います。ユニットテストとバージョン管理は、組み合わせることで相乗効果を発揮します。そのためのノリが、「自動化」です。自動化は、プログラマにとっては最も身近で、強力なツールですが、ここでも絶大な威力を発揮します。実際、ユニットテストはなんらかの自動化がなければ、事実上機能しないでしょう。サブタイトルの「バージョン管理/ユニットテスト/自動化」は、無関係なトピックをただ列挙したわけではないのです。これら3つをうまく組み合わせていくことが、ソフトウェア開発の現場を改善する、大きな力になるでしょう。プログラマならいつも漠然と感じてることを、言葉にしてはっきりさせてくれたり、言いにくいことをズバッと言ってくれてます。一方で、僕は起業家的な考えは持ってないので、ビジネスについてのハナシには、全く新鮮なオドロキを感じました。賢いプログラマは、自分の感じるところを信じて押し通すことが、結局は自分のためにもチームのためにも最良なんです。問題は、ポール・グレアムがハッカーと呼ぶ賢いプログラマの範疇に、自分がちょっとでもひっかかっているのかどうか、知るすべがないことです。そこは信じてつっ走るしかないです。