ちょうぜつのカレンダー | Advent Calendar 2019 - Qiita
About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)
やはりあなた方の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」するというデザインパターンです。 日本語では何故か「依存性の注入」と訳されており、これが混乱の元ではないかと思います。 日本語で「依存性」と言うと、「依存性は
【Android】Activityを肥大化させないためのデザインパターンを紹介します。 | ヘッドウォータースのブログ TechNote
こんにちは。良昌です。 Androidのライブラリはすごく便利なのですが、内部的に複数のスレッドを走らせる機能などは、終了時のコールバック関数をターゲットのActivityで実装するため、インスタンスの生成自体もターゲットのActivityで行うことが多いと思います。 そのため、少し機能をリッチにしてしまうと、肥大化されたActivityが作られてしまうのではないでしょうか。 効率良くアプリを量産するためには、使い回しの効く独自のライブラリを作っていくことが重要だと思いますので、今回は簡単な例を挙げて、Activityを肥大化させないためのデザインを紹介します。 [Android]Activityを肥大化させないためのデザインパターンを紹介します。 ■ Activityを肥大化させる原因の例 スレッドの終了を通知する機能は色々とありますが、今回はandroid.os.CountDownTi
デザインパターンとともに学ぶオブジェクト指向のこころ を読んだ - takatoshiono's blog
読んだ理由 最近、ソフトウェアの設計力が不足していると感じる。もっといい感じにクラスを設計して、オブジェクト指向ぽいプログラムを書けるようになりたい。しかもスピード感を持ってやりたい。ということで、いまさらだけど、オブジェクト指向についてもう一度学んでみようと思った。本を読めばいいという訳じゃないけど、とりあえずもっと知識を増やしたい。渋谷の東急百貨店 7F の丸善＆ジュンク堂書店に行って、 オブジェクトデザイン (Object Oriented SELECTION) エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) の3冊で悩んだ結果、これを買った。決める要因となったのは、 ついでにデザインパターンについて理解を深められたらいいなと思った これまで
matarillo.com: UIパターン
UIパターン 追記 この記事の一部を加筆・修正したものを「開発者が知っておくべき、6つのUIアーキテクチャ・パターン」として@ITに転載しています。 MVVMを追加した上で、アプリケーションモデルとMVVMをプレゼンテーションモデルのバリエーションとして位置づけました。 MVPの2つのスタイルとして、監視コントローラとパッシブ・ビューを説明しました。 まえがき Martin Fowlerの"GUI Architectures"を訳したので公開しようと思ったのだが、FAQページに「EAA developmentとかDSLなんかは商業出版するんで例外ってことで」と書いてある。面倒だったので翻訳の公開はやめて、「自分の理解を書く」というスタイルにしようと思う。 Fowler氏が説明しているのは 「フォームとコントロール」、「モデルビューコントローラー (MVC)」、「プレゼンテーションモデル」、
サルでもわかる 逆引きデザインパターン 第4章 逆引きカタログ その他 実行時例外を標準的に使う
イントロダクション ここまでは今までのJavaの常識からはありえない「実行時例外を使いましょう」という考え方をご紹介します（ちなみにこれは『実践J2EEデザイン』という書籍で紹介されたイディオムで、デザインパターンではありません）。 筆者も「実行時例外を使おう」と初めて聞いたときはたいへん驚きました。今までの常識が崩れ去った気分でした。 しかし、今ではこの方法で、問題なく、以前よりも効率良くアプリケーションを書いています。 パターン解説 例外には大きく分けて検査例外と実行時例外があります。 検査例外はjava.lang.Exceptionを継承した例外です。 検査例外が発生する場所では、必ずcatchブロックで例外をキャッチするか、throws句で例外をメソッドの呼び出し元に投げる宣言をする必要があります。 実行時例外はjava.lang.RuntimeExceptionを継承した例外です
クロージャデザインパターン (PHP 版)
2013年4月13日追記: PHP 5.5 で finally 句が追加されたので Loan パターンを追記しました。 Closure Design Patterns で紹介されている Groovy のコードを PHP に翻訳しました。無名関数とクロージャを区別しても情報が分散してしまうのでクロージャに統一しました。Method Combination (関数合成)は省略しました。原文ではカリー化(currying) と書いている箇所を部分適用 (partial application) に訂正しました。カリー化と部分適用の違いについてはこちらのブログに解説があります。Groovy コアに本当のカリー化メソッドを採用することへの要望があり、長期的には取り込まれる見込みのようです。 これらのパターンは Venkat Subramaniam 氏および Neal Ford 氏のプレゼン資料から抜
フロントコントローラ - Strategic Choice
フロントコントローラ＠Webプレゼンテーションパターンリクエストすべてを受け付けるコントローラ。どういうこと？フロントコントローラは、一旦全てのリクエストを1つの「ハンドラ」オブジェクトが受けて、それらを「コマンド」オブジェクトに振り分ける仕組みです。どうすれば？フロントコントローラは、「ハンドラ」と「コマンド」から構成します。ハンドラは、URLとリクエストから必要な情報を抽出します。どのようなアクションを実行するかを判断し、アクションを実行するコマンドに委譲します。ハンドラは、レスポンスを返さないため、サーバベージとしてではなくクラス*1として実装されます。ハンドラ自体は極めてシンプルなプログラムであり、実行するコマンドを判断する以外は何も行いません。コマンドは、アクションの実処理を行うクラスです。最終的なビューの決定も、コマンドクラスで行います。コマンドもサーバページではなく、クラス*
数多くのコンストラクタパラメータに直面した時にはビルダーを検討する - Strategic Choice
package asakichy.第02章オブジェクトの生成と消滅; import static org.hamcrest.Matchers.*; import static org.junit.Assert.*; import org.junit.After; import org.junit.Before; import org.junit.Test; @SuppressWarnings("unused") public class 項目02数多くのコンストラクタパラメータに直面した時にはビルダーを検討する { @Test public void 問題点_コンストラクタパラメータの数が多いと使いにくい() throws Exception { /** 【詳細】 */ description.append(1).append("何番目が何のパラメータかわかりにくい。"); descrip
僕はアダム、シングルトン中毒から回復したんだ
プログラミングで使われるデザインパターンの一つにシングルトンというのがあります。ご存知の方も多いと思いますが覚えるととても便利でなんでもかんでもシングルトンにしたくなってしまう設計です。このシングルトンを使った設計の問題を訴えたAdamさんのブログが話題になっていました。 Adamさんによるとシングルトンのダメな所は下記のとおり。 依存関係を見えにくくし、コードが読みづらくなる。 ユニットテストを難しくする。外部から渡せないオブジェクトはモックにする事が難しい。 プログラムの再利用性が低下する。一度しか使わないからとシングルトンで作ってしまうと複数のユーザーから利用されるような場合に対応できなくなる。 スケーラビリティが低下する。 良いオブジェクト指向の設計とは言えない。 異論、反論を受付中ということでコメント欄も盛り上がっています。 食べると太るから食べ物は悪だ、みたいな話だ。 Eric
Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson | Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson | InformIT
Erich Gamma, Richard Helm, and Ralph Johnson talk to Larry O'Brien about Design Patterns, 15 years later. Larry O'Brien: 85,000 apps for the iPhone have been developed and deployed in the past year-and-change. One can write a globally-accessible "Hello, World! The time is X" Web page in just one line of PHP, for instance. "Designing object-oriented software is hard," are the first words of Design
Implementing the Observer Pattern with SplObserver and SplSubject
As PHP applications grow into complex object-oriented systems, developers look to create centralized components to execute repetitive tasks. These include logging, emailing, redirects, and more. The Observer pattern is a commonly used design pattern to hook such components into an application during runtime, thereby making them reusable. Since PHP 5.1, there are two interfaces built into the Stand
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
PHP5.3で継承して使うSingletonをちゃんとやる - 絶品ゆどうふのタレ
発端 02:51:51 (sotarok) で， hoge_klass::get_instance() も，同じように動くようにしたい，でも，hoge_klass には， get_instance を再実装したくないよね 略しすぎてなんだか分からない人のために言っとくと、まぁSingletonの実装ってメンドいから継承したいよねと。 昔、Objective-Cでもそれやったけど 継承して使えるSingletonクラス - ゆどうふろぐ PHP5.3で遅延静的束縛ができたから、継承できるSingletonを実装できるようになったから。 まぁあちこちサンプルあるけど、なんかcloneとかconstructとかちゃんとやって無いし。 で、まぁノリで書いてみたらfinalとかがcloneやconsructに付けられるという事実が分かって*1、なんか思ったよりきちんと重複を排除できる感じで、継承して
Observer pattern in PHP
I've recently pretty much fell in love with an observer design pattern. You can basically build the whole application on it using awesome power of event driven programming. What exactly is an observer pattern ? All the theory is accessible on Wikipedia. Basically we have an object you want to monitor ( observe ) for any changes. Most of the time this object just fires out events and we want to lis
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ダブル・ディスパッチ～ 典型的なオブジェクト指向プログラミング・イディオム ～
プロジェクト管理：再利用：【真実20】デザインパターン方式の再利用は実用的 - Strategic Choice
Command Invoker Pattern with the Open/Closed Principle
分離の原則 - Strategic Choice
Index of /content/a-caching-pattern-for-models/