SlideShare a Scribd company logo
1 of 70
依存関係逆転の原則
黒澤 慎太郎
自己紹介
省略
▸私が来た
前回までの話
某社の設計はこうす
ればいいんじゃない
?
私
ガンジーな私
で?コードは?
まさかり担いだKowillさん
まさかり担いだKOWILLさん
退路は
絶たれた
全部は勘弁してください
フレームワーク作るプロジェクトです?
▸全部やると、フレームワークを一つ作り直す巨大なプロジ
ェクトになる気がする
▸しかも旨味がなさそう
▸重要なところだけちょびっとやる
▸スキルアップに繋がるように汎用的にやる
▸本物のコードを持ち出すとコンプライアンス的にやばそう
なので脳内補完お願いします
依存関係逆転
の原則
BEFORE
アプリ作ってるとこんな依存関係になる
UI層
ロジック層
データアクセス層
AFTER
依存関係逆転の原則を適用
UI層
ロジック層
データアクセス層
なんということでしょう
依存関係逆転の原則
▸上位モジュールは下位モジュールに依存してはならない。
▸上位モジュールも下位モジュールも、抽象に依存するべき
。
▸抽象は、実装の詳細に依存してはならない。
▸実装の詳細が抽象に依存するべき。
なんのことだ
かわからない
さあ!
コードだ!
コードですよKOWILLさん
▸C#で書きました。
▸説明のため、非常に簡素です。
▸ロジック層とデータクセス層の間だけに原則を適用したサ
ンプルです。
人は誰もがプロトタイプ
サンプルプログラムについて
▸ユーザーの誕生日から、現在の年齢を計算するプログラム
▸ユーザの情報は、永続化して保存できる
原則適用前
適用前
メインルーチン
public void Main ()
{
var user = new User (DateTime.Now);
Console.WriteLine("あなたの年齢は " + user.Age.ToString() + " です。");
user.Save (user);
}
USER
USER CLASS
public class User
{
private DateTime _birthday;
public User (DateTime birthday)
{
_birthday = birthday;
}
public int Age{ get { GetAge (); } }
private int GetAge(){
// 計算
return 9; // 永遠の9歳
}
public void Save(){
var repogitory = new UserRepogitory ();
repogitory.Save (this);
}
}
REPOSITORY
USER REPOSITORY CLASS
public class UserRepogitory
{
public void Save(User user){
// Insert Database
}
}
データアクセスDLL
ロジックDLL
原則適用前
クラス図
USER
USER REPOSITORY
抽象に
依存する
データアクセスDLL
ロジックDLL
原則適用前
クラス図
USER
USER REPOSITORY
USER REPOSITORY
INTERFACE
インターフェース追加
USER REPOSITORY INTERFASE
public interface IUserRepogitory
{
void Save(User user);
}
インタフェースを使う
USER
public class User
{
private DateTime _birthday;
public User (DateTime birthday)
{
_birthday = birthday;
}
public int Age{ get { return GetAge (); } }
private int GetAge(){
// 計算
return 9; // 永遠の9歳
}
public void Save(){
IUserRepogitory repogitory = new UserRepogitory ();
repogitory.Save (this);
}
}
インタフェースを使う
USER
public class User
{
private DateTime _birthday;
public User (DateTime birthday)
{
_birthday = birthday;
}
public int Age{ get { return GetAge (); } }
private int GetAge(){
// 計算
return 9; // 永遠の9歳
}
public void Save(){
IUserRepogitory repogitory = new UserRepogitory ();
repogitory.Save (this);
}
}
あれ?結局UserRepogitoryに依存している?
データアクセスDLL
ロジックDLL
現在の依存関係
クラス図
USER
USER REPOSITORY
USER REPOSITORY
INTERFACE
依存性の注入
依存の話ばっかりだな
依存性の注入(DEPENDENCY INJECTION)
▸依存関係を、クラスやソースコードの外側から注入する
▸ソフトウェアパターン
依存性の注入
USER
public class User
{
private IUserRepogitory _repogitory;
private DateTime _birthday;
public User (DateTime birthday,IUserRepogitory repogitory)
{
_repogitory = repogitory;
_birthday = birthday;
}
public int Age{ get { return GetAge (); } }
private int GetAge(){
// 計算
return 9; // 永遠の9歳
}
public void Save(){
_repogitory.Save (this);
}
}
依存性の注入
USER
public class User
{
private IUserRepogitory _repogitory;
private DateTime _birthday;
public User (DateTime birthday,IUserRepogitory repogitory)
{
_repogitory = repogitory;
_birthday = birthday;
}
public int Age{ get { return GetAge (); } }
private int GetAge(){
// 計算
return 9; // 永遠の9歳
}
public void Save(){
_repogitory.Save (this);
}
}
フィールド変数にする
依存性の注入
USER
public class User
{
private IUserRepogitory _repogitory;
private DateTime _birthday;
public User (DateTime birthday,IUserRepogitory repogitory)
{
_repogitory = repogitory;
_birthday = birthday;
}
public int Age{ get { return GetAge (); } }
private int GetAge(){
// 計算
return 9; // 永遠の9歳
}
public void Save(){
_repogitory.Save (this);
}
}
コンストラクタで実装オブジェクトを受け取る
依存性の注入
USER
public class User
{
private IUserRepogitory _repogitory;
private DateTime _birthday;
public User (DateTime birthday,IUserRepogitory repogitory)
{
_repogitory = repogitory;
_birthday = birthday;
}
public int Age{ get { return GetAge (); } }
private int GetAge(){
// 計算
return 9; // 永遠の9歳
}
public void Save(){
_repogitory.Save (this);
}
}
フィールド変数に設定
データアクセスDLL
ロジックDLL
ちゃんとこうなりました
クラス図
USER
USER REPOSITORY
USER REPOSITORY
INTERFACE
なんということでしょう
依存関係逆転の原則
▸上位モジュールは下位モジュールに依存してはならない。
▸上位モジュールも下位モジュールも、抽象に依存するべき
。
▸抽象は、実装の詳細に依存してはならない。
▸実装の詳細が抽象に依存するべき。
達成!
下位モジュールから
上位モジュールに
依存する
データアクセスDLL
ロジックDLL
依存の方向
クラス図
USER
USER REPOSITORY
USER REPOSITORY
INTERFACE
現在は、上位から下位に依存している
データアクセスDLL
ロジックDLL
依存の方向
クラス図
USER
USER REPOSITORY
USER REPOSITORY
INTERFACE
インターフェースをロジック側でもつ
なんということでしょう
依存関係逆転の原則
▸上位モジュールは下位モジュールに依存してはならない。
▸上位モジュールも下位モジュールも、抽象に依存するべき
。
▸抽象は、実装の詳細に依存してはならない。
▸実装の詳細が抽象に依存するべき。
全部達成!
USERクラスは、
データアクセスと
どう紐づくのか
データアクセスDLL
ロジックDLL
依存の方向
クラス図
USER
USER REPOSITORY
USER REPOSITORY
INTERFACE
USERクラスは、データアクセスと完全に分離している
依存性の注入
USER
public class User
{
private IUserRepogitory _repogitory;
private DateTime _birthday;
public User (DateTime birthday,IUserRepogitory repogitory)
{
_repogitory = repogitory;
_birthday = birthday;
}
public int Age{ get { return GetAge (); } }
private int GetAge(){
// 計算
return 9; // 永遠の9歳
}
public void Save(){
_repogitory.Save (this);
}
}
誰がこのフィールド変数に実装オブジェクトを設定するのか
USERクラスは、
データアクセスを
知ってはいけない
依存性の注入を
もう一度見てみよう
依存の話をもう一度
依存性の注入(DEPENDENCY INJECTION)
▸依存関係を、クラスやソースコードの外側から注入する
▸ソフトウェアパターン
依存の話をもう一度
依存性の注入(DEPENDENCY INJECTION)
▸依存関係を、クラスやソースコードの外側から注入する
▸ソフトウェアパターン 外側とは何を指すのか?
依存性を注入する
方法は
幾つかある
ここでは
メインルーチンで
やってみよう
データアクセスDLL
ロジックDLL
依存の方向
クラス図
USER
USER REPOSITORY
USER REPOSITORY
INTERFACE
アプリケーションEXE
アプリは、ロジックとデータアクセスを両方とも知っている
例えば
メインルーチンで依存性注入の例
public void Main ()
{
var repogitory = new UserRepogitory ();
var user = new User (DateTime.Now, repogitory);
Console.WriteLine("あなたの年齢は " + user.Age.ToString() + " です。");
user.Save (user);
}
例えば
メインルーチンで依存性注入の例
public void Main ()
{
var repogitory = new UserRepogitory ();
var user = new User (DateTime.Now, repogitory);
Console.WriteLine("あなたの年齢は " + user.Age.ToString() + " です。");
user.Save (user);
}
どのデータアクセスを使うか
例えば
メインルーチンで依存性注入の例
public void Main ()
{
var repogitory = new UserRepogitory ();
var user = new User (DateTime.Now, repogitory);
Console.WriteLine("あなたの年齢は " + user.Age.ToString() + " です。");
user.Save (user);
}
USERクラスが使うデータアクセスを指定
例えば
メインルーチンで依存性注入の例
public void Main ()
{
var repogitory = new UserRepogitory ();
var user = new User (DateTime.Now, repogitory);
Console.WriteLine("あなたの年齢は " + user.Age.ToString() + " です。");
user.Save (user);
}
データアクセスを使ってオブジェクトを永続化
で、これが
何の役にたつ
?
例えばこういうとき
ロジックはそのままでデータストアが異なる
▸ロジックはそのまま使いたいが、データ保存が異なる複数
のアプリケーション
▸ちょっとしたロジック確認のため、データベースを用意す
るのはコストが高い
▸ユニットテストでデータベースを用意するのはコストが高
い
LOCAL SQLSERVER データアクセス
DLL
ロジックDLL
依存の方向
クラス図
アプリケーションEXE
アプリケーション2EXE
CLOUD SQLSERVER データアクセス
DLL
クラウドコンピューティング
アプリケーション2EXEのメインルーチン
public void Main ()
{
var repogitory = new UserRepogitoryCloud ();
var user = new User (DateTime.Now, repogitory);
Console.WriteLine("あなたの年齢は " + user.Age.ToString() + " です。");
user.Save (user);
}
別データベースへのアクセス
ここまで来てやっと恩恵を受けることができる
依存関係を排除した結果
▸全く同じアプリケーションで、様々な環境で動かせるアプ
リができる
▸例えば、
▸WindowsFormアプリケーション
▸ASP.NET MVCのWebサービス
▸Windows Phoneアプリ
まとめ
まとめ
依存関係逆転の原則
▸抽象度を高くする
▸モジュールの依存関係の方向は重要
▸適切なモジュール関係を作れば、データベースが異なるた
びにif文を入れる必要はない。
▸これはデータベースアクセスに限った話ではない
まとめ2
依存関係逆転の原則
▸if文がなくなるということはテストケースが少なくなる
▸if文ネストもなくなる
▸モジュールが別になるので修正時に影響度を調べる必要な
し
▸保守性の向上、開発の効率化などいいことづくめ?
いいことづく
めではない
まとめ3
依存関係逆転の原則
▸確実に複雑性は増す
▸複雑性を増してでも、データアクセスは依存を排除すべき
▸なんでもかんでもインタフェースで抽象化するとコードが
複雑化し、混沌となる
▸抽象度を上げる時は、必ず必要最小限にすること
ここでまでの話で、
原則・パターンの力が
わかっていただけたは
ず
力こそPOWER
ここまでの話
▸ここまでで、出てきたもの
▸依存性の注入パターン
▸依存関係逆転の原則
▸この例での中でも、はっきりと明記はしていないが、オブ
ジェクト指向における原則・パターンは他にも出てきてい
る
テキスト
大事な話
▸原則・パターンは、個々に適用するよりも組み合わせた方
が効果が高い
▸状況や要求に合わせて、適切な原則やパターンを組み合わ
せていく
▸その選択と決定に実力とセンスが出てくる
▸原則・パターンの知識量
▸実戦経験
知識を
つけていこう
凡人の
凡人による
凡人のための
デザインパターン
シリーズ化決定
凡人の、凡人による、ぼんじ(RY
▸次から、パターンを少しづつLTしていきます
▸まずはGofのパターンから
▸なぜこんな回りくどいかというと、「パターンを教科書的に覚えて
いっても使える知識になりにくい」から
▸特にGofのデザインパターンは本読んだだけって人がたくさんい
ると思います。
▸まずは、「パターンってこんなに凄いんだぜ!」ってやりたかった
。
その他お知らせ
技術書オンリーイベント
▸技術系書籍の同人イベント
▸https://techbookfest.github.io/
ご静聴
ありがとう
ございました

More Related Content

What's hot

ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったことドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと増田 亨
 
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのかDDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのかKoichiro Matsuoka
 
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門増田 亨
 
ドメイン駆動設計 分析しながら設計する
ドメイン駆動設計 分析しながら設計するドメイン駆動設計 分析しながら設計する
ドメイン駆動設計 分析しながら設計する増田 亨
 
DDD sample code explained in Java
DDD sample code explained in JavaDDD sample code explained in Java
DDD sample code explained in Java増田 亨
 
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース増田 亨
 
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture世界一わかりやすいClean Architecture
世界一わかりやすいClean ArchitectureAtsushi Nakamura
 
ドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDDドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDD増田 亨
 
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計増田 亨
 
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説増田 亨
 
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門増田 亨
 
ドメイン駆動設計 失敗したことと成功したこと
ドメイン駆動設計 失敗したことと成功したことドメイン駆動設計 失敗したことと成功したこと
ドメイン駆動設計 失敗したことと成功したことBIGLOBE Inc.
 
ドメイン駆動設計(DDD)の実践Part2
ドメイン駆動設計(DDD)の実践Part2ドメイン駆動設計(DDD)の実践Part2
ドメイン駆動設計(DDD)の実践Part2増田 亨
 
ドメインモデルの育て方
ドメインモデルの育て方ドメインモデルの育て方
ドメインモデルの育て方増田 亨
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪Takuto Wada
 
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)Koichiro Matsuoka
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」Takuto Wada
 
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話Koichiro Matsuoka
 
ちいさなオブジェクトでドメインモデルを組み立てる
ちいさなオブジェクトでドメインモデルを組み立てるちいさなオブジェクトでドメインモデルを組み立てる
ちいさなオブジェクトでドメインモデルを組み立てる増田 亨
 
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?実践的な設計って、なんだろう?
実践的な設計って、なんだろう?増田 亨
 

What's hot (20)

ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったことドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
 
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのかDDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
 
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
 
ドメイン駆動設計 分析しながら設計する
ドメイン駆動設計 分析しながら設計するドメイン駆動設計 分析しながら設計する
ドメイン駆動設計 分析しながら設計する
 
DDD sample code explained in Java
DDD sample code explained in JavaDDD sample code explained in Java
DDD sample code explained in Java
 
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
 
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
 
ドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDDドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDD
 
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
 
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
 
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
 
ドメイン駆動設計 失敗したことと成功したこと
ドメイン駆動設計 失敗したことと成功したことドメイン駆動設計 失敗したことと成功したこと
ドメイン駆動設計 失敗したことと成功したこと
 
ドメイン駆動設計(DDD)の実践Part2
ドメイン駆動設計(DDD)の実践Part2ドメイン駆動設計(DDD)の実践Part2
ドメイン駆動設計(DDD)の実践Part2
 
ドメインモデルの育て方
ドメインモデルの育て方ドメインモデルの育て方
ドメインモデルの育て方
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪
 
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
 
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
 
ちいさなオブジェクトでドメインモデルを組み立てる
ちいさなオブジェクトでドメインモデルを組み立てるちいさなオブジェクトでドメインモデルを組み立てる
ちいさなオブジェクトでドメインモデルを組み立てる
 
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
 

Similar to 20160526 依存関係逆転の原則

Tokyo GTUG Bootcamp2010
Tokyo GTUG Bootcamp2010Tokyo GTUG Bootcamp2010
Tokyo GTUG Bootcamp2010Takashi EGAWA
 
iPhoneアプリ開発の歩き方〜Swift編〜
iPhoneアプリ開発の歩き方〜Swift編〜iPhoneアプリ開発の歩き方〜Swift編〜
iPhoneアプリ開発の歩き方〜Swift編〜Yusuke SAITO
 
goog.ui.Component のはぐれかた
goog.ui.Component のはぐれかたgoog.ui.Component のはぐれかた
goog.ui.Component のはぐれかたSoichi Takamura
 
1.29.user,user,user
1.29.user,user,user1.29.user,user,user
1.29.user,user,userTonny Xu
 
Roslyn による Visual Studio のアドイン
Roslyn による Visual Studio のアドインRoslyn による Visual Studio のアドイン
Roslyn による Visual Studio のアドインFujio Kojima
 
MVPパターンによる設計アプローチ「あなたのアプリ報連相できてますか」
MVPパターンによる設計アプローチ「あなたのアプリ報連相できてますか」MVPパターンによる設計アプローチ「あなたのアプリ報連相できてますか」
MVPパターンによる設計アプローチ「あなたのアプリ報連相できてますか」U-dai Yokoyama
 
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)NTT DATA Technology & Innovation
 
2010/8/27 TechEd2010 ライトニングトーク
2010/8/27 TechEd2010 ライトニングトーク2010/8/27 TechEd2010 ライトニングトーク
2010/8/27 TechEd2010 ライトニングトークSunao Tomita
 
Mashup Caravan in オープンソースカンファレンス2011 Hiroshima: infoScoop OpenSource
Mashup Caravan in オープンソースカンファレンス2011 Hiroshima: infoScoop OpenSourceMashup Caravan in オープンソースカンファレンス2011 Hiroshima: infoScoop OpenSource
Mashup Caravan in オープンソースカンファレンス2011 Hiroshima: infoScoop OpenSourcecmutoh
 
GroovyなAndroidテスト #atest_hack
GroovyなAndroidテスト #atest_hackGroovyなAndroidテスト #atest_hack
GroovyなAndroidテスト #atest_hackTakahiro Yoshimura
 
OnActivityResult - おまえら!もうonActivityResultでswitchとif書く時代は終わりだぞ!
OnActivityResult - おまえら!もうonActivityResultでswitchとif書く時代は終わりだぞ!OnActivityResult - おまえら!もうonActivityResultでswitchとif書く時代は終わりだぞ!
OnActivityResult - おまえら!もうonActivityResultでswitchとif書く時代は終わりだぞ!Shinobu Okano
 
20130924 Picomon CRH勉強会
20130924 Picomon CRH勉強会20130924 Picomon CRH勉強会
20130924 Picomon CRH勉強会Yukihiro Kitazawa
 

Similar to 20160526 依存関係逆転の原則 (14)

Tokyo GTUG Bootcamp2010
Tokyo GTUG Bootcamp2010Tokyo GTUG Bootcamp2010
Tokyo GTUG Bootcamp2010
 
AndroidでDIxAOP
AndroidでDIxAOPAndroidでDIxAOP
AndroidでDIxAOP
 
iPhoneアプリ開発の歩き方〜Swift編〜
iPhoneアプリ開発の歩き方〜Swift編〜iPhoneアプリ開発の歩き方〜Swift編〜
iPhoneアプリ開発の歩き方〜Swift編〜
 
goog.ui.Component のはぐれかた
goog.ui.Component のはぐれかたgoog.ui.Component のはぐれかた
goog.ui.Component のはぐれかた
 
1.29.user,user,user
1.29.user,user,user1.29.user,user,user
1.29.user,user,user
 
Roslyn による Visual Studio のアドイン
Roslyn による Visual Studio のアドインRoslyn による Visual Studio のアドイン
Roslyn による Visual Studio のアドイン
 
MVPパターンによる設計アプローチ「あなたのアプリ報連相できてますか」
MVPパターンによる設計アプローチ「あなたのアプリ報連相できてますか」MVPパターンによる設計アプローチ「あなたのアプリ報連相できてますか」
MVPパターンによる設計アプローチ「あなたのアプリ報連相できてますか」
 
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
 
2010/8/27 TechEd2010 ライトニングトーク
2010/8/27 TechEd2010 ライトニングトーク2010/8/27 TechEd2010 ライトニングトーク
2010/8/27 TechEd2010 ライトニングトーク
 
Mashup Caravan in オープンソースカンファレンス2011 Hiroshima: infoScoop OpenSource
Mashup Caravan in オープンソースカンファレンス2011 Hiroshima: infoScoop OpenSourceMashup Caravan in オープンソースカンファレンス2011 Hiroshima: infoScoop OpenSource
Mashup Caravan in オープンソースカンファレンス2011 Hiroshima: infoScoop OpenSource
 
GroovyなAndroidテスト #atest_hack
GroovyなAndroidテスト #atest_hackGroovyなAndroidテスト #atest_hack
GroovyなAndroidテスト #atest_hack
 
Dotnetconf2017
Dotnetconf2017Dotnetconf2017
Dotnetconf2017
 
OnActivityResult - おまえら!もうonActivityResultでswitchとif書く時代は終わりだぞ!
OnActivityResult - おまえら!もうonActivityResultでswitchとif書く時代は終わりだぞ!OnActivityResult - おまえら!もうonActivityResultでswitchとif書く時代は終わりだぞ!
OnActivityResult - おまえら!もうonActivityResultでswitchとif書く時代は終わりだぞ!
 
20130924 Picomon CRH勉強会
20130924 Picomon CRH勉強会20130924 Picomon CRH勉強会
20130924 Picomon CRH勉強会
 

20160526 依存関係逆転の原則