State パターン 「State」という英単語は、「状態」を意味します。 このパターンでは、ある物についての各状態をそれに対応した各クラスで表現します。（つまり、状態1つにつき、クラス1つで表現します。） 通常、条件(状態)に一致するか否かの処理は、if文を使用し、コーディングしますが、その条件分岐数が多い場合、1つの条件で処理するコード量が多い場合、また同じ条件分岐が複数の箇所に点在する場合等、メンテナンスし辛いものとなってしまいます。しかし、このパターンを適用すると、その状態状態を個々のクラスで表現するため、単純明快となります。 役割り 1. State(状態) 状態を表すクラスです。 状態毎に振舞いが異なるメソッドのインタフェースを定義します。 2. ConcreteStateA・B(具体的な状態) 「State」のインタフェースを実装し、具体的な状態を、「1クラス」 = 「1状態

# 久々に技術ネタを書いてみる。 # と言っても、某掲示板で使ったネタの使い回し。 C++ にはなかった新しいキーワードとして、C# では interface というものが出てくる。 interface は、Java ではおなじみのキーワードだ。 例． interface ICloneable { object Clone(); } interface では公開されているメソッドとプロパティの外見 (名前、パラメータ、戻り値) だけが宣言されていて、実装部分が定義されていない。実装部分は、その interface を実装するクラスによって定義される。 例． class Employee : ICloneable { private string name; public string Name { get { return name; } set { name = value; } } p

イントロダクション オブジェクトを利用する側からすれば、使用する際にオブジェクトの詳細を意識したくはありませんよね。 たとえば、条件によってデータファイルの読み込みに使うオブジェクトが異なる場合、CSV形式であればCSVDataReaderオブジェクトを、XML形式であればXMLDataReaderオブジェクトを生成します。 通常はif、else、switchなどの条件分岐を使用して、条件ごとに生成するオブジェクトを変更します。 ここで新たなデータファイル形式への対応が必要になった場合は、新しいオブジェクト生成処理と、条件式を追加しなければいけません。 オブジェクトの使用者は、オブジェクトが使用できる状態で受け渡してもらい、オブジェクトは使うことだけに専念したいものです。 また、このようにオブジェクトの生成処理と使用処理が同じコードに書かれていた場合、オブジェクトの生成処理によってオブジェ

昨日会社のメンバーからコーディングについて相談を受けました。 話を聞いていると、オブジェクト指向設計を利用してコードをリファクタリングしたい様子でした。 彼は頑張ってインターフェースやクラスを自分で定義していたんですが、ちょっとぎこちない設計だったので、おいらはStateパターンとFactoryパターンらしきテクニックを使って、改善のお手伝いをしてみました。 そのときの事例をめちゃくちゃデフォルメして説明すると、こんな感じになります。 プログラムはStateに応じて文字や色を変更します。 初期状態です。 ボタンを押すとStateに応じて文字や色が変わります。 メンバーが最初に書いていたプログラムのイメージはこんな感じです。 using System; using System.Collections.Generic; using System.ComponentModel; using S

元ネタ - iマリオでデザインパターン その1 【Strategyパターン】 - hidecheckの日記 そのエントリーのコメントにも書いたとおり、StateパターンとStrategyって混同しやすいと思う。（もしかしたら今もそうかも。ツッコミください。） そこで僕もStateパターンで何かマリオ的なモノを作ってみようということで、やってみた。とりあえず今回の仕様はこちら。（実際のマリオの挙動と違うかもですが、そこはご了承を！） 今、デフォマリオの状態 スーパーきのこを食べた⇒デカマリオになる ファイアフラワーを食べた⇒デカマリオになる ノコノコに当たった⇒ゲームーオーバー 今、デカマリオの状態 スーパーきのこを食べた⇒デカマリオになる（というか変化無し） ファイアフラワーを食べた⇒ファイヤーマリオになる ノコノコに当たった⇒デフォマリオになる 今、ファイヤーマリオの状態 スーパーきのこ

Factory パターンって、Abstract Factory パターンのことを言ってるの？それとも Factory Method パターンのこと？ と疑問に思う方もいらっしゃると思いますが、ここでは両者をまとめて解説します。 誤解をおそれずに言うなら、両者にはたいした違いはありません。 この「たいした」の部分のについては、説明を読んでいただければわかるかと思います。 コンテンツ Factory ってなに？ それをやるとなにが嬉しいのか？ インタフェースで依存度を下げてみる 問題はコンストラクタ ファクトリを使って依存をなくす ファクトリの可能性 Abstract Factory と Factory Method の違い Abstract Factory パターンとは Factory Method パターンとは Factory パターンの応用 Factory ってなに？ 直訳すれば工場です

貴方がもっともよく使うデザインパターンのベスト１０を教えてください Naoya氏のJavaScript OOPとかを見ていたら、ふと疑問に思いました。 みんなデザパタってどういうの使ってんだろう？ 自分のOOPは完全に本のみの自己流、先輩も師匠もなにも存在しません。しかも言語がflashでプロトタイプベースときています。んなわけで、スッゲェ偏ってると思うので、他のみなさんがどんなの使ってるのか気になる今日この頃デス。 １位： Template とりあえずこれがないと、サブクラス真面目に作る気になれません。 ２位： Observer イベントリスナーモデルの便利さでＯＯＰに目覚めました。 ２位： Singleton １作に１個はつかいます、大好き。 3位： Mediator 要所要所でメディエイターを作るのが好きです。時間たってからコード読んでも思い出しやすくなるので。 ４位： Comman