UMLによるStateパターン[1][2] Lepus3（英語版）によるStateパターン[2][3] State パターン（英: state pattern、ステート・パターン）とは、プログラミングで用いられる振る舞いに関する（英語版） デザインパターンの一種である。このパターンはオブジェクトの状態（state）を表現するために用いられる。ランタイムでそのタイプを部分的に変化させるオブジェクトを扱うクリーンな手段となる[1]:395。 擬似コードによる例[編集] ドローソフトを例に取る。このプログラムは任意の時点においてさまざまなツールのうちの1つとして振る舞うマウスカーソルを持つ。複数のカーソルオブジェクトを切り替える代わりに、カーソルは現在使用されているツールを表す内部的な状態を保持する。（例えばマウスクリックの結果として）ツールに依存するメソッドが呼ばれると、メソッド呼び出しはカー

デザインパターンで状態を示すStateパターンっていうのがある。 これを説明して、「Stateパターン、すげー（＠＿＠！）」 って感心されたんで、書いておいて見る。 ■そもそも、Stateパターンとは？ 状態を示す（抽象的な）スーパークラスStateをつくり、 （具体的な）各状態は、それを継承した、各状態クラスを作ります。 例：Stateクラスには、executeがある

最近、物欲に目覚めてしまってAmazonでいろいろ買ってたら、今月の請求が7万を超えて素に戻ってしまった戸田です。 ちょっとbluetoothデバイスに凝り始めてしまって…。（汗） さて、オブジェクト指向設計のバイブルと言えば、いわずと知れたGoF本（オブジェクト指向における再利用のためのデザインパターン、Erich Gamma, Ralph Johnson, Richard Helm, John Vlissides著、ソフトバンククリエイティブ刊）です。 ここで紹介されている23のパターンはどれも小手先のテクニックではなく、エッセンスが抽出されており応用範囲が広いものばかりです。 なによりも今まで暗黙知になりがちな、設計の定石・パターンに共通の名称（言語）を与えて、名称による概念の共有ができるようになったという功績は計り知れません。 もちろん、KREISELにおいてもこれらのパターンを活

Strategy パターン（ストラテジー - ）は、コンピュータープログラミングの領域において、アルゴリズムを実行時に選択することができるデザインパターンである。 Strategyパターンはアルゴリズムを記述するサブルーチンへの参照をデータ構造の内部に保持する。このパターンの実現には、関数ポインタや関数オブジェクト、デリゲートのほか、オーソドックスなオブジェクト指向言語におけるポリモーフィズムと委譲、あるいはリフレクションによる動的ダック・タイピングなどが利用される。 このパターンは、関数が第一級オブジェクトである言語では暗黙のうちに使用されている。例として後述のPythonコード例を参照のこと。 Strategy パターンは、アプリケーションで使用されるアルゴリズムを動的に切り替える必要がある際に有用である。Strategy パターンはアルゴリズムのセットを定義する方法を提供し、これらを

(ほとんど写経なんだけど)とにかくできたー!と思って、調べてみたら山のように実装があって、ま、そんなもんかと思い直す。 class Singleton_(object): '''singleton pattern implementation reffered from thread http://www.python.jp/pipermail/python-ml-jp/2002-November/002075.html , thanks! usage: inherit Singleton and call Inheretee.instance()''' instance_ = None def __new__(cls): if cls.instance_ is None: cls.stat = [] cls.instance_ = object.__new__(cls) return c

この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2015年10月） 脚注による出典や参考文献の参照が不十分です。脚注を追加してください。（2021年8月） 出典検索?: "Observer パターン" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL この記事内にあるすべての画像は、ベクターイメージである SVG ファイルとして再作成されるべきです。これにはいくつかの利点があります。詳しくはWikipedia:SVGへの乗り換えを参照してください。この画像の SVG 形式がすでに利用可能である場合は、アップロードしてください。アップロード後、この画像にあるこのテンプレートを{{SVG版利用可能

Facade パターンあるいは Façade パターン（ファサード・パターン）とは、GoF（Gang of Four; 4人のギャングたち）によって定義された、コンピュータソフトウェアのデザインパターンの1つである。Facade（ファサード）とは「建物の正面」を意味する。異なるサブシステムを単純な操作だけを持ったFacadeクラスで結び、サブシステム間の独立性を高める事を目的とする。 概要[編集] Facadeパターンの例として、サブシステムとしてのコンパイラーを考える。システムとしてのコンパイラーは字句解析器や構文解析器などから構成されている。これらの構成要素は、新たなコンパイラーやその他ソフトウェアを作成する上でサブシステムとして利用することが出来る。しかし、一般ユーザーにとってコンパイラーはソースコードからプログラムを生成するためのものであり、ソースコードをコンパイルできる機能があれ

Flyweight パターン（フライウェイト・パターン）とは、GoFによって定義されたデザインパターンの1つである。等価なインスタンスを別々の箇所で使用する際に、一つのインスタンスを再利用することによって計算資源の浪費を減らすことを目的とする。なお、flyweightとは、英語で「フライ級」を意味し、ボクシングにおける体重別階級の1つである。 クラス図[編集] Flyweight パターンのクラス図を以下に挙げる。 FlyweightFactory クラスは Flyweight インスタンスのコンテナをフィールドとして持ち、Flyweight オブジェクトを返すメソッド getFlyweight() を実装する。 概要[編集] Flyweight パターンで設計された API では、利用者は Flyweight クラスにあたるインスタンスを取得する場合に、直接そのクラスのコンストラクタを呼

Factory Method パターン（ファクトリメソッド・パターン）[1]とは、GoF (Gang of Four; 四人組)によって定義されたデザインパターンの1つである。 Factory Method パターンは、他のクラスのコンストラクタをサブクラスで上書き可能な自分のメソッドに置き換えることで、 アプリケーションに特化したオブジェクトの生成をサブクラスに追い出し、クラスの再利用性を高めることを目的とする。 Virtual Constructor パターンとも呼ばれる[1]。 クラス図[編集] Factory Method パターンのクラス図は以下の通りである。 抽象クラス Creator は 抽象クラス Product を生成するメソッドを持つ。 クラス ConcreteCreator は Creator の具象クラスであり、ConcreteProduct を生成するメソッドを持

Template Method パターン（テンプレート・メソッド・パターン）とは、GoF (Gang of Four; 4人組) によって定義されたデザインパターンの1つである。「振る舞いに関するパターン」に属する。Template Method パターンの目的は、ある処理のおおまかなアルゴリズムをあらかじめ決めておいて、そのアルゴリズムの具体的な設計をサブクラスに任せることである。そのため、システムのフレームワークを構築するための手段としてよく活用される。 クラス図[編集] 以下に Template Method パターンのクラス図を挙げる。 AbstractClass は、public で宣言された templateMethod() と protected で宣言されたいくつかの抽象メソッドを持つ。ConcreteClass は AbstractClass を継承し、AbstractC

Singleton パターン（シングルトン・パターン）とは、オブジェクト指向のコンピュータプログラムにおける、デザインパターンの1つである。GoF (Gang of Four; 4人のギャングたち) によって定義された。Singleton パターンとは、そのクラスのインスタンスが1つしか生成されないことを保証するデザインパターンのことである。ロケールやルック・アンド・フィールなど、絶対にアプリケーション全体で統一しなければならない仕組みの実装に使用される[1]。 クラス図[編集] Singleton パターンの一般的なクラス図を示す。 Singleton は同じ型のインスタンスを private なクラス変数として持つ。この変数には Singleton.getInstance() からアクセスする。Singleton のコンストラクタは private である。 このクラス図で注目すべきこ

23種類のGoFデザインパターンには、それぞれ親しみやすい名前が付けられています。今回紹介する2つのパターンの名前を直訳すると、「橋（Bridge）」および「装飾者（Decorator）」となります。どちらも構造に関するパターンに分類されているので、構造として橋を架けたような工夫、そして構造に飾りを付ける工夫であることが予測できます。オブジェクト指向プログラミングにおける橋と飾りとは、いったい何なんだろう．．．興味が湧いてきたところで本題に入りましょう。 【お役立ち度】★★★★★ ●拡張から実装に橋を架けるBridgeパターン 継承元のクラスをスーパークラスと呼び、継承先のクラスをサブクラスと呼びます。サブクラスの役割には、スーパークラスの抽象メソッドを適切に実装することと、スーパークラスの機能を拡張することがあります。 ここで、引数に与えられたデータを描画するdrawメソッド（抽象メソッ

親父の小言のように何度も同じ話をして恐縮ですが、とても大事なことなので聞いてください。GoFの23種類のデザインパターンは、生成に関するパターン、構造に関するパターン、振る舞いに関するパターンの3つに分類されています。このことから、オブジェクト指向プログラミングを上手に実践するには、生成、構造、振る舞いに関する工夫をすればよいことがわかります。GoFデザインパターンは、工夫のお手本集なのです。 個々のデザインパターンの本質（何が便利なのか）を見抜くコツは、どの分類に属しているかを確認することです。今回紹介するSingletonパターンは生成に関するパターンに分類され、Flyweightパターンは構造に関するパターンに分類されています。すなわち、オブジェクトの生成に関する工夫と、プログラムの構造に関する工夫です。 【お役立ち度】★★★☆☆ ●オブジェクトを1つだけしか生成させないSingle

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。 GoFの23のパターンが有名です。デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。 そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。 12番目は処理手順やアルゴリズムをスムーズに交換できるようにするStrategyパターンのメモです。 Strategyパターンは、実行時に処理のアルゴリズムを決定したいときに使うパターンです。 処理のアルゴリズムとは、例えばソートの方法であったり、数値の計算の仕方であったりします。 1つ目のアルゴリズムを使うと計算は速いがメモリ