dpinfo.html
目次 はじめに Abstract Classパターン Abstract ClassパターンRuby版 (by 助田雅紀さん) Balkingパターン Before/Afterパターン Futureパターン FutureパターンRuby版 (by 助田雅紀さん) Generation Gapパターン Hook Operationパターン Hook OperationパターンRuby版 (by 助田雅紀さん) Immutableパターン Marker Interfaceパターン Monostateパターン MonostateパターンRuby版 (by 助田雅紀さん) MonostateパターンPerl版 (by 宮川さん) Null Objectパターン Null ObjectパターンとSingletonパターン Producer-Consumerパターン Sharableパターン Singl
Unity開発で使える設計の話＋Zenjectの紹介
4. おしながき • 設計とは – 設計とは何か、設計の何がよいのか – モデリングとクラス設計 • 覚えておくべき基礎知識 – クラス図の読み方 – SOLID原則 – デザインパターン • Zenjectの紹介 – 依存性注入とは何か • まとめ
Template Method Patternがマッチする場合、マッチしない場合 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
んーー TemplateMethodPattern は乱用されがちな気がするなあ— しんぺい a.k.a. 猫型蓄音機 (@shinpei0213) 2019年1月11日 Template Method Patternを使いたくなったときは一度引いて見てちゃんと解放閉鎖原則を満たすかどうかを考えて見てもたぶん損はないと思う— しんぺい a.k.a. 猫型蓄音機 (@shinpei0213) 2019年1月11日 Template Method Patternは「継承で実装を再利用する」系のパターンなんで、密結合を産みがちですよね。フレームワークを実装するときにはすごくマッチするパターンなんだけど、アプリケーションコードで使いたくなったときには「ちょっとまてよ、これらはほんとうに"同じ処理"かな？」って考えたい— しんぺい a.k.a. 猫型蓄音機 (@shinpei0213) 2019年1
Template Method パターン - Wikipedia
Template Method パターン（テンプレート・メソッド・パターン）とは、GoF (Gang of Four; 4人組) によって定義されたデザインパターンの1つである。「振る舞いに関するパターン」に属する。Template Method パターンの目的は、ある処理のおおまかなアルゴリズムをあらかじめ決めておいて、そのアルゴリズムの具体的な設計をサブクラスに任せることである。そのため、システムのフレームワークを構築するための手段としてよく活用される。 以下に Template Method パターンのクラス図を挙げる。 AbstractClass は、public で宣言された templateMethod() と protected で宣言されたいくつかの抽象メソッドを持つ。ConcreteClass は AbstractClass を継承し、AbstractClass で定義さ
やはりあなた方のDependency Injectionはまちがっている。 — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or something
今日はPHP界隈で大人気のDependency Injectionと、それに関連する用語について整理しておこうと思います。 以下のような状況があるのではないか？と思ったからです。 多くのPHPユーザがDependency Injection（DI）をよくわかっていない、あるいは正確に説明できません。 そして、デザインパターンである「DIパターン」とDIをサポートするツールである「DIコンテナ」を混同しています。 また、「DIパターン」と「サービスロケータパターン」をうまく区別できていません。 Dependency Injectionとは何か？ Dependency Injectionとは「Dependency」を「Injection」するというデザインパターンです。 日本語では何故か「依存性の注入」と訳されており、これが混乱の元ではないかと思います。 日本語で「依存性」と言うと、「依存性は
デザインパターンの話 - Qiita
irxground 君が再考: GoF デザインパターンといふ記事を書いてゐるので自分もちょっとコメントしてみます。 基本的に irxground 君と同意見のところは省略します。 あと、GoF の本自体は私は読んでゐません。 (GoF のパターン以外のパターンに関する意見の方が長くなってますね……。) GoF のデザインパターン 生成に関するパターン Builder そもそも builder パターンは Java の String と StringBuilder の様に可変オブジェクトと不変オブジェクトを別のクラスに設計しなければならない言語でしか基本的に役に立たないパターンであり、C++ の様にキャストだけで可変オブジェクトを不変オブジェクトに変換できる言語ではこのパターンは無用なはずである。 Java が出る前の本でこれがパターンとして挙げられてゐたといふのが俺には不思議に感じられる
15．Facadeパターン
15.1 Facadeパターンとは 第15章ではFacadeパターンを学びます。プログラムを作っていくと、最初は小さなものでも、だんだん大きくなっていきます。 たくさんのクラスが出来て、相互に関係しあい、複雑になっていきます。 クラスを使う場合には、それらの関係を正しく理解して、 正しい順番にメソッドを呼び出す必要があります。 大きなプログラムを使って処理を行う場合、 関係しあっているたくさんのクラスを適切に制御しなくてはいけません。 その処理を行うための「窓口」を用意しておくと、 個別にたくさんのクラスを制御しなくても、「窓口」に対して、要求するだけですみます。 Facadeパターンは、既存のクラスを複数組み合わせて使う手順を、「窓口」となるクラスを作ってシンプルに利用できるようにするパターンです。 ちなみに、facadeとはフランス語を語源とする単語で「建物の正面」という意味です。発音
DataMapper を使う - KrdLab's blog
ActiveRecord はかなり便利な O/R mapper ですが，さらに上(？)がありました． DataMapper http://datamapper.org/ なお，このエントリは 0.9.11 をベースに書いています． このエントリの目次と他エントリへのリンク 概要 [関連するエントリ] Why DataMapper? Getting Started With DataMapper 接続 マイグレーション Logger モデル定義 Property 定義 Validation 指定 [関連するエントリ] Properties Validations Index Single Table Inheritance Hook モデル操作 作成 読み取り 更新 削除 [関連するエントリ] Finding トランザクション [関連するエントリ] Transactions アソシエーション
コンストラクタの代わりにstaticファクトリーメソッドを検討する - Strategic Choice
package asakichy.第02章オブジェクトの生成と消滅; import static org.hamcrest.Matchers.*; import static org.junit.Assert.*; import java.math.BigInteger; import java.util.ArrayList; import java.util.Collections; import java.util.EnumSet; import java.util.HashMap; import java.util.List; import java.util.Map; import java.util.Random; import java.util.concurrent.ConcurrentHashMap; import org.junit.After; import org.j
再考: GoF デザインパターン - Qiita
本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代にカタログ化された 現代のプログラミングと合致しないものが多い 「オブジェクト指向における～」と断っている以上、OOPに絡める必要があった パターンのいくつかに「多態性を用いると便利」という蛇足がついている 挙げたパターンに根拠がない 「とりあえず、23個ほ
Observer パターン - Wikipedia
この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2015年10月） 脚注による出典や参考文献の参照が不十分です。脚注を追加してください。（2021年8月） 出典検索?: "Observer パターン" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL この記事内にあるすべての画像は、ベクターイメージである SVG ファイルとして再作成されるべきです。これにはいくつかの利点があります。詳しくはWikipedia:SVGへの乗り換えを参照してください。この画像の SVG 形式がすでに利用可能である場合は、アップロードしてください。アップロード後、この画像にあるこのテンプレートを{{SVG版利用可能
続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi
三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
