【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)」、「プレゼンテーションモデル」、
クロージャデザインパターン (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
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
ハタさんのブログ : PHP開発者のためのデザインパターン。の閑話
はてなのPHP keywordを付けているところを眺めていたら、僕と同じようにデザインパターンを実践している人がいた。参考にしよう ref - ルーで一気にクマー デザパタについては以前「デザパタ本には載らないデザパタ」にも書いたことあったけど、GoFとかJ2EEとかPofEAA(これはちょっと大きいか)で色んなパターンが転がってるけど、実際にやっていることは、「同じような実装を2度も書きたくない」から、書きやすく整理する手法をパターンっていってるんだなーと思う。 んで、ここはid:shimookaが上手いことまとめてくれていて、突き詰めれば勝手にデザパタされるんじゃないかと。 (中略) 僕なんかは、もともとjavaで一定のプログラミング設計(?)とかインタフェースについて見てきた(Seasar含めて)からinterfaceみたいなものが大好きなんだけど、んなもんいらん！実装クラスだけで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロジェクト管理：再利用：【真実20】デザインパターン方式の再利用は実用的 - Strategic Choice
