GoFのデザインパターンの自作サンプルまとめ（主にRubyで実装。一部Java） - Tbpgr Blog
概要 GoFのデザインパターンに関して取り扱った記事のまとめ 生成のパターン AbstractFactory | 詳細を意識せず抽象的にインスタンス生成を行う Builder | 複雑なインスタンス生成手順をクラス化する FactoryMethod | インスタンスの作成を独立させる Prototype | コピーしてインスタンスを作る Singleton | インスタンスが一つであることを保証する 構造のパターン Adapter | AとBのインターフェースのアダプターを作る Bridge | 機能の拡張と実装の拡張を分割する Composite | 容器と中身の同一視 Decorator | 飾りと中身の同一視 Facade | シンプルな窓口 Flyweight | 同じ物を共有して処理を軽量化する Proxy | 必要になってから作る Proxy | 必要になってから作る(Forw
Ruby 2.0.0で学ぶ、14個のデザインパターンを作りました[GoF][Design Pattern] - 酒と泪とRubyとRailsと
GoFのデザインパターンとは、「プログラミングのベストプラクティスを体系化したもの」です。このベスト・プラクティスをしっかりと理解して設計すれば、ソフトウェア設計の効率を高めることができます。またデザインパターンが「プログラミングの思想」の共有をよりスムーズにしてくれます。先人たちの試行錯誤の結果を効果的に利用して、プログラミングをもっと楽しんでしまいましょう！ 🗻 デザインパターンのポイントGoFのデザインパターンには下のプリンシパルがあります。 変わるものを変わらないものから分離する インタフェースに対してプログラミングし、実装に対して行わない 継承より集約 委譲、委譲、委譲 必要になるまで作るな(You Ain’t Gonna Need It./YAGNI) 🤔 デザインパターン一覧 アブストラクトファクトリ ビルダ ファクトリメソッド シングルトンパターン アダプタ コンポジッ
![Ruby 2.0.0で学ぶ、14個のデザインパターンを作りました[GoF][Design Pattern] - 酒と泪とRubyとRailsと](https://cdn-ak-scissors.b.st-hatena.com/image/square/c2ea7e72d0d7f3ba6c237909f321e67ffbdaa24e/height=288;version=1;width=512/https%3A%2F%2Fmorizyun.github.io%2Fimg%2Fog_image.png)
RubyでObserverデザインパターン - u16suzuの blog
なんか、FFの調子が悪い。。 今日は、RubyのObserverデザインパターンを試してみました。エラーログ出力に使えそう。 require 'observer' #被観察者 class AObservable include Observable end #観察者 class AObserver def update(str) p str end end #オブジェクト作成 obj = AObservable.new observer = AObserver.new #観察者に被観察者を登録 obj.add_observer(observer) #被観察者のフラグをかえる obj.changed #notify_observersで観察者のupdateメソッド実行。 #notify_observersの引数がupdateに渡される。 obj.notify_observers("hello
【翻訳】EventMachine入門
dan sinclairさんのEventMachineの入門記事（PDF）を翻訳しました。 原文はここからダウンロード可能です： http://everburning.com/news/eventmachine-introductions/ （翻訳の公開と画像の利用は本人より許諾済みです） 翻訳・内容の間違い等があればブログコメントやTwitterなどで遠慮無くご指摘ください。 EventMachine入門 Introduction うん、これから何を学ぶことになるのか、この導入のくだりがスタート地点として役に立つと思う。EventMachine とは何だろう。そしてそれは私たちのために何をしてくれるのだろう。さて、最初の部分は簡単だね。EventMachine は Reactor パターン(*1)の高性能な実装さ。 すげえ、いや、ちょっと待て、Reactor パターンって何だ？ Wiki
まつもと直伝 プログラミングのオキテ 第9回
ソフトウエア設計に登場するパターンをまとめた「デザイン・パターン」について学びましょう。デザイン・パターンを使いこなせれば，複雑なプログラムを効率よく設計できます。今回は，既にあるものを使いまわすPrototype，抽象的にアルゴリズムを記述できるTemplate Method，強い依存性を断ち切るObserverの各パターンを紹介します。 前回は「デザイン・パターンとは何か」を学びました。設計上繰り返し登場する形をデザイン・パターンと呼びます。ごく簡単な例としてはforループがあります。はっきりと分類されたものとしては書籍『オブジェクト指向における再利用のためのデザインパターン』（ソフトバンク パブリッシング）が参考になります。 前回に取り上げたSingleton，Proxy，Iteratorの各パターンに続いて，今回は別のデザイン・パターンを考えてみましょう。Prototype，Tem
Active Record - Wikipedia
「アクティブレコード、アクティブ・レコード」はこの項目へ転送されています。イギリスのレコードレーベルについては「ミュージック・フォー・ネイションズ」をご覧ください。 Active Recordはデータベースからデータを読み出すためのアプローチである。データベーステーブルあるいはビューの1行が1つのクラスにラップされ、オブジェクトのインスタンスがそのデータベースの1つの行に結合される。このクラスはデータベースアクセスのカプセル化も行う[1]。オブジェクトの生成後は、保存メソッドで新しい行がデータベースに追加される。 オブジェクトが更新されると、データベースの対応する行もまた更新される。ラッパークラスはテーブルあるいはビューの各カラムに対するアクセサメソッドを実装するが、それ以外の振る舞い（MVCのモデルが担当すべきロジック）も記述することができる[1]。 テーブルとクラスが一対一で結びつくこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サバクラ両方で動く JavaScript の大規模開発を行うために