Tbpgr Blog

Employee Experience Engineer tbpgr(てぃーびー) のブログ

GoFのデザインパターン

RubyでProxyパターン/Matzは松江から来るのに時間がかかるのでProxyRubyistを置く!(Forwardable版)

概要 RubyでProxyパターン/Matzは松江から来るのに時間がかかるのでProxyRubyistを置く! http://d.hatena.ne.jp/tbpg/20120306/1331048460 の内容をForwardableを利用して書き直しました。 http://www.ruby-lang.org/ja/old-man/html/Forwardable.html 登…

GoFのデザインパターンの自作サンプルまとめ(主にRubyで実装。一部Java)

概要 GoFのデザインパターンに関して取り扱った記事のまとめ 生成のパターン AbstractFactory | 詳細を意識せず抽象的にインスタンス生成を行う Builder | 複雑なインスタンス生成手順をクラス化する FactoryMethod | インスタンスの作成を独立させる Protot…

RubyでInterpreterパターン/HTML5のセクション構造に対応したWebページの生成

概要 GoFのデザインパターンのInterpreterパターンについて。 任意の文法規則をクラスで表します。 汎用言語を使用して、特定分野の用途に絞ったミニ言語(DSL)を作成する際などに利用される。 問題領域に近く・処理効率がよく・保守性の高いプログラムの作…

RubyでCommandパターン/たたかう・ぼうぎょ・じゅもん・アイテム/ガンガンいこうぜ・いのちをだいじに・いろいろやろうぜ

概要 GoFのデザインパターンのCommandパターンについて。 処理をクラスとして独立させることで、再利用性を高めたり 複数履歴履歴に対応したりさせることが出来る。 よくある用例 複数操作のUndo プログレスバーの管理 ウィザード スレッドプール 登場人物 C…

RubyでProxyパターン/Matzは松江から来るのに時間がかかるのでProxyRubyistを置く!

概要 GoFのデザインパターンのProxyパターンについて。 ある処理について、代理人を置くことで処理を分散して負荷を軽減させる。 登場人物 Subject = 主体 RealSubject = 主体の実体 Proxy = 代理人 Client = 利用者 UML 実装サンプル サンプル概要 Rubyに関…

RubyでFlyweightパターン

概要 GoFのデザインパターンのFlyweightパターンについて。 再利用可能なインスタンスを保持しておくことで 処理の軽量化を図ることことを目的とするのがFlyweightパターンです。Flyweightの語源はボクシングのフライ級。 ボクシングの階級の中でも軽量な階…

RubyでStateパターン

概要 GoFのデザインパターンのStateパターンについて。 状態をクラスで表現します。 状態と処理を分割することでプログラムをよりシンプルにします。 登場人物 State = 状態。状態に依存した振る舞いを表す ConcreteState = 具象状態 Context = 状況、文脈 U…

RubyでMementoパターン/擬似クリップボード機能で理解

概要 GoFのデザインパターンのMementoパターンについて。 ある時点でのスナップショットを残すことによって undo,redo,snapshot,history などの機能を実現します。Memento(=記念品)にはwide interfaceとnarrow interfaceを用意します。 wide interfaceはpr…

Rubyで泣く子も泣きやむObserverパターン

概要 GoFのデザインパターンのObserverパターンについて。 観察者が被験者の変化に応じた処理を行う場合に使用。 観察者と被験者の依存が弱まり、追加が容易になることが利点。 登場人物 Subject = 被験者 ConcreteSubject = 具象被験者 Observer = 観察者 C…

RubyでMediatorパターン

概要 GoFのデザインパターンのMediatorパターンについて。 多数のメンバー(同僚、Colleague)を利用する処理を調停者(Mediator)を通して行うパターン。 個別のメンバーにばらばらに重複するような処理を持たせずに一か所で管理することで 保守性を向上さ…

RubyでFacadeパターン

概要 GoFのデザインパターンのFacadeパターンについて。 複雑な手順の処理の窓口=Facadeを用意することで システムをシンプルにする。 登場人物 Facade = 窓口 ModuleA = 処理A ModuleB = 処理B Client = 利用者 UML 実装サンプル サンプル概要 親子構造を…

RubyでVisitorパターン

概要 GoFのデザインパターンのVisitorパターンについて。 データ構造と処理の分離を行うことによって OPC(The Open-Closed Principle)を実現する。 拡張については開かれていて、修正については閉じられている。VisitorとElementが協調して処理を行う形式を …

RubyでChainOfResponsibilityパターン

概要 GoFのデザインパターンのChainOfResponsibilityパターンについて。 処理の責務をたらい回しにする。利点としては ・要求側は処理を呼び出す最初の相手だけ知っていれば良い ・処理の連鎖の修正が容易 ・各自の処理に専念できる欠点としては ・遅いこと …

RubyでDecoratorパターン

概要 GoFのデザインパターンのDecoratorパターンについて。 飾りと中身を同一視するパターン。 利点 元のクラスの中身を変えずに機能を追加出来る 組み合わせで様々な機能を実現できる 欠点 小さいクラスが大量に出来る 登場人物 Component = 抽象コンポーネ…

RubyでCompositeパターン

概要 GoFのデザインパターンのCompositeパターンについて。 よくある例としてファイルとフォルダを同様のComponentとして扱い、 再帰処理を可能とする。 木構造を再現する際などに利用。 登場人物 Component = コンポーネント。構成要素 Composite = コンポ…

RubyでStrategyパターン

概要 GoFのデザインパターンのStrategyパターンについて。 委譲によってアルゴリズムを交換可能にする。 登場人物 Context = コンテキストクラス Strategy = 抽象戦略 ConcreteStrategy = 具象戦略 UML 実装サンプル サンプル概要 ある言語のソースコードを…

RubyでBridgeパターン

概要 GoFのデザインパターンのBridgeパターンについて。 クラス〜サブクラスの機能の階層。 抽象クラス〜具象クラスの実装の階層。 それぞれを独立させることで保守性を高める。 新たな機能、新たな実装の追加が容易となる、 登場人物 Abstraction = 抽象ク…

RubyでAbstractFactoryパターン

概要 GoFのデザインパターンのAbstractFactoryパターンについて。 Factoryで利用するオブジェクト一式をまとめて入れ替えることが可能です。 登場人物 AbstractFactory = 工場の抽象クラス ConcreteAbstractFactory = 工場の具象クラス AbstractProduct = 製…

RubyでBuilderパターン

概要 GoFのデザインパターンのBuilderパターンについて。 Builderパターン 内容 一覧の流れを行うBuilderをDirectorから呼び出す。 一定の手順を必要とするオブジェクトの生成を柔軟に実装することが出来る。 登場人物 Director = 現場監督 Builder = 建築者…

RubyでSingletonパターン

概要 GoFのデザインパターンのSingletonパターンについて。 インスタンスがひとつであることを保証するのがSingletonパターン。 登場人物 Singleton = シングルトン UML 実装サンプル サンプル概要 あるサイトのアクティブユーザーを管理するクラスを実装し…

RubyでTemplateメソッドパターンとFactoryメソッドパターン

概要 GoFのデザインパターンのTemplateメソッドパターンとFactoryメソッドパターンについて。 FactoryメソッドパターンはTemplateメソッドパターンを利用しているので Factoryメソッドパターンのサンプル説明を持って、Templateメソッドパターンの説明を兼ね…

Adapterパターン

GoFのデザインパターンのAdapterパターンについて。■概要 ある機能Adapteeに変更を加えることなく新しい機能を追加したい場合の アダプタを作成して対応するデザインパターン。コンセントと家電の間の電圧変換を行うACアダプタをイメージするのが分かりやす…

Iteratorパターン

■Iteratorパターン Iteratorパターンの構成 要約 集合体(Aggregate)と反復ロジック(Iterator)の分離 を行うことによって変更に強くなる。 例えば反復ロジックのみを変更したい場合、Iteratorのみを 変更すればよく、ループのロジックの変更は不要となる…