ソフトウェア開発におけるデザインパターンまたは設計パターン（英: design pattern）とは、過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものである。パターン（pattern）とは、型紙（かたがみ）やひな形を意味する。 本稿でのデザインは狭義の設計という意味であり、CSSやHTMLなどで使われる意匠デザインの定形を示す「デザインパターン」とは異なる。 書籍『オブジェクト指向における再利用のためのデザインパターン』において、GoF (Gang of Four) と呼ばれる4人の共著者は、デザインパターンという用語を初めてソフトウェア開発に導入した。GoFは、エーリヒ・ガンマ、リチャード・ヘルム、ラルフ・ジョンソン、ジョン・ブリシディースの4人である。彼らは、その書籍の中で23種類のパターンを取り上げた
１．State パターン オブジェクトの内部状態を個々に表すオブジェクトを用意し、それらを切り換えることで状態を表現する。 [構成クラス] ○State クラス 状態に関するインタフェースを定義する仮想クラス 協調関係： Contextを使用する。 ○ConcreteState クラス 具体的な１つの状態を表し、状態に関するインタフェースを実装する。 協調関係： State を継承 Contextを使用する。 ○Context クラス 状態を変化させるオブジェクトのクラス 現在の状態を示す State をもつ。 協調関係： Stateからメンバを参照される。 ○Client クラス Contextを使用するクラス [利用シーン] ○キャラクターの状態を表現 移動やＡＩによるキャラクターの状態を State で表現することが出来る。 ○メニュー選択
Adapterパターン～APIを変更する 絶版に伴い、校正前の原稿テキストを公開したものです。基本的に原稿そのままをHTML形式に変換したものですので、誤字/脱字、説明不足の箇所もあるかも知れませんがご了承ください。初出：「PHPによるデザインパターン入門」（下岡秀幸/畑勝也/道端良 著, 秀和システム, ISBN4-7980-1516-4, 2006年11月23日発売) GoF本における分類 構造＋クラス、オブジェクト はじめに ここではAdapterパターンについて説明します。 adaptという単語には「適合させる」とか「なじませる」「適応させる」という意味があります。つまり、adapterとは「適合させるもの」という意味になります。 日本語でも、「アダプタ」という言葉はあちこちで聞く言葉だと思います。ACアダプタやネットワークアダプタ、一昔前に全盛を誇ったISDN回線で必要になるタ
19.1 State パターンとは 第19章では State パターンを学びます。State とは、英語で「状態」を意味する単語です。 オブジェクト指向設計では、モノをクラスとして表現することが多くあります。State パターンとは、 モノではなく、「状態」をクラスとして表現するパターンです。 状態によって、動作のパターンが変わることがよくあります。 例えば、「機嫌のいい状態」「機嫌が悪い状態」の2つの状態があるお母さんにいくつか頼みごとをすることを考えます。 機嫌のいい状態のお母さんに「お小遣い頂戴」「おやつ頂戴」などのお願いをした場合、 「はいはい」といってお小遣いをくれたり、おやつを出してくれたりするでしょう。 しかし、機嫌の悪い状態のお母さんにこれらのお願いをしても聞き入れてくれないかもしれません。 お母さんは状態によって、振る舞いが変わるわけです。 State パターンとは、この
15.1 Facadeパターンとは 第15章ではFacadeパターンを学びます。プログラムを作っていくと、最初は小さなものでも、だんだん大きくなっていきます。 たくさんのクラスが出来て、相互に関係しあい、複雑になっていきます。 クラスを使う場合には、それらの関係を正しく理解して、 正しい順番にメソッドを呼び出す必要があります。 大きなプログラムを使って処理を行う場合、 関係しあっているたくさんのクラスを適切に制御しなくてはいけません。 その処理を行うための「窓口」を用意しておくと、 個別にたくさんのクラスを制御しなくても、「窓口」に対して、要求するだけですみます。 Facadeパターンは、既存のクラスを複数組み合わせて使う手順を、「窓口」となるクラスを作ってシンプルに利用できるようにするパターンです。 ちなみに、facadeとはフランス語を語源とする単語で「建物の正面」という意味です。発音
イントロダクション オブジェクトを生成するnewは非常に負荷のかかる処理ですので、使いまわしが効くオブジェクトを毎回newするのはパフォーマンス上問題です。 たとえば、後述のファクトリメソッドパターンで取り上げるファクトリは毎回newする必要がないため、初めに生成したオブジェクトを再利用すぺきです。 また、データベースのコネクションプール数を制限したい場合、データベースアクセスオブジェクトの生成数を制限する必要があります。 このようにオブジェクトの生成数を制限したいときは、シングルトンパターンの出番です。 このパターンを使えば、オブジェクトを外部から直接生成させることを防ぐことができ、クラス自体に同時に生成できるオブジェクトの数を管理する機能を持たせることができます。 パターン解説 シングルトンパターンの特徴は、シングルトンクラスのオブジェクト生成を、シングルトンクラス自身が提供するオブジ
プログラムの設計とは、システム全体を複数の小さなモジュールに分け、それらの関連を考えることだと言えます。その際に重要なのは、モジュール間の関連をいかにシンプルにするかです。1つのモジュールの改造が、できるだけ他のモジュールに影響を及ぼさないようにしなければなりません。これは、オブジェクト指向プログラミングに限らず、あらゆるプログラミング技法に共通したことでしょう。 オブジェクト指向プログラミングにおけるモジュールは、クラスまたはオブジェクトです。クラス間の関連は、プログラムの静的な構造を表し、オブジェクト間の関連は、プログラムの動的な機能を表します。今回は、GoFデザインパターンの中から、オブジェクト間の関連をシンプルにするIteratorパターンと、本来つながらないクラスどうしを改造することなく関連付けてしまうAdapterパターンを紹介しましょう。どちらも★5つですから、そのアイディア
今回は、パターンを1つだけ紹介します。「Mediatorパターン」です。GoF本では、それぞれのパターンの「目的]「背景」「効果」などが明示されています。私も、ちょっと真似をしてみましょう。複数のオブジェクトを組み合わせてプログラムの機能を実現するという目的において、オブジェクト間の関連がゴチャゴチャになってしまうという背景（問題）があり、Mediatorパターンの採用によって関連をキレイに整理できるという効果があります。説明だけでは、何のことだかわからないと思いますので、具体例をお見せしましょう。 図1[拡大表示](1)をご覧ください。これは、UML（Unified Modeling Language、ユーエムエル）と呼ばれる表記法で記述されたプログラムの設計図です。UMLでは、四角形の中に下線付きで名前を書いてオブジェクトを表し、関連のあるオブジェクトを矢印で結んで示します。ここで関連
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く