どんなふうに作るか考え抜くのもありだし適当に作るのもありだ。普通は、一般的なパターンに従うほうがいい。他の人にもそのコードを理解してもらいやすくなるからである。多用されているデザインパターンのひとつが、ファクトリーパターンだ。使いたいオブジェクトを生成するだけのクラスを用意する。こんなコードを考えてみよう。こんなふうにするメリットは二つある。クラスに手を入れたり名前を変更したり別のものに入れ替えたりすることになっても簡単にできるということ。クラスを使っているところをひとつひとつ修正するとかいうことはしなくてもよい。そのすべてのファクトリーに閉じ込めてしまえること。新しいインスタンスを作るたびに毎回同じようなことを繰り返さずに済む。なにがなんでもファクトリーパターンを使えばいいってわけではない。無駄に複雑になったように見えるかもしれない。変なトラブルに巻き込まれないためにもファクトリーを使っておいたほうがいいだろう。特定のクラスのたったひとつのインスタンスにだけアクセスさせるようにしたいということがよくある。そんなときに使えるのがシングルトンパターンだ。getInstance()メソッドを使ってシングルトンパターンを実装している。これらのことに注目しよう。演算子で新しいインスタンスを作れなくなる。演算子でインスタンスをクローンしようとしてもできなくなる。インスタンスのアンシリアライズができなくなる。サブクラスを作れるようになる。ひとつのインスタンスだけしかないことを保証しないといけない場合だ。イベントキューみたいな共有リソースを使っていたりする場合に活用できる。シングルトンを使うときには注意が必要だ。アプリケーションにグローバルな状態を導入することになってしまい、テストがしにくくなる。(し、むしろそっちを使うべきだ)。アプリケーションの設計から取り除ける。オブジェクトが具象クラスについて知らなくてもよくなるからだ。クライアントクラス側から特定のアルゴリズムのインスタンスを作れるようになる。このときに、実際の実装に関する知識はなくてもかまわない。このパターンにはいくつかのバリエーションがあるけれど、ここでは一番シンプルなものを解説する。最初に示すのは、アルゴリズム群を表すコード片だ。シリアライズした配列、JSON、あるいは単なるデータの配列が欲しいとしよう。}}このようにアルゴリズム群をカプセル化しておけば、使う側のコードからもうまい具合に使えるようになる。他の開発者が新たな出力形式を追加したとしても、使う側のコードは変更する必要がない。個々の具象「出力」クラスがOutputInterfaceを実装していることに気づくだろう。具象実装が従うべきシンプルな規約をあてはめること。使え、正しい型(この場合は’OutputInterface’)を使っていることを保証できるということだ。必要な振る舞いを実行時に設定したりするものだ。}}このクライアントクラスにはprivateなプロパティが用意されている。実行時には、必ず’OutputInterface’型を設定しておく必要がある。指定した型の具象クラスのload()メソッドが呼ばれることになる。そこですべてのリクエストを処理するというパターンだ。依存情報を読み込んだりリクエストを処理したりレスポンスをブラウザに返したりといった責務を負う。フロントコントローラを利用すると、コードのモジュール化が進めやすくなる。フックとして組み込みやすくなる。使うと、コードを論理的に分解してそれぞれ特定の役割を担わせることができる。モデルはデータアクセス層を扱い、データを取得してそれをアプリケーションで使いやすい形式で返す。それをレスポンスとして返す。扱い、これをレスポンスとしてウェブブラウザに返す。その関連パターンについてさらに知りたければ、これらを参考にしよう。www.phptherightway.com.。