狠狠撸

狠狠撸Share a Scribd company logo
DI 入門 DI コンテナを導入する意義 について理解する
構造化設計とオブジェクト指向設計の思想の違いを理解する そもそも、 DI の考え方を理解する前提として、 オブジェクト指向的なプログラム設計 について理解しておかなくてはならない 伝統的な構造化型プログラミングではプログラムを処理の固まり単位に分割し、メインから順次下位のサブルーチンをコールする 一方、オブジェクト指向できちんと設計されたシステムであれば、 「特定の責務」を持ったオブジェクト が互いにメッセージをやりとりすることで特定の機能が実現される
構造化型アーキテクチャ プログラムを順次細分化された 処理の集合 として構築 データはパラメータやグローバル変数として処理とは別に管理 プログラムの状態としてのデータがカプセル化されていないため、上位関数は下位関数の処理の細部を原則知っていることが前提(実質的に巨大なアルゴリズム) バッチなどの定型処理や小規模スクリプトなど単純なケースを除いて、 GUI や分散処理など、 今日の複雑なプログラムの作成には向かない main 関数 初期処理 データ更新処理 DB 接続オープン処理 SQL 文発行処理 DB 接続クローズ処理 更新件数表示処理 グローバルデータ パラメータ
オブジェクト指向アーキテクチャ 責務 が明確に分かれた オブジェクト単位 に分割 担当オブジェクトに順次処理を委譲 ロジックとデータはオブジェクト内部に カプセル化 外から呼び出される public なインタフェース と 内部の実装 とが明確に分離される コントローラ サービス DAO エンティティマネージャ ビュー エンティティ DTO 接続プール データソース 画面描画 画面遷移ロジック ビジネスロジック バリデータ データ転送 業務固有データ 永続処理 入力チェック
オブジェクト指向のメリット オブジェクトを部品として 再利用 できる 基本的な 部品を組み合わせる ことで複雑で大規模なプログラムを構築できる 継承、動的バインディングなどのプログラミング手法を利用することにより、元のソースコードに手を加えることなく 拡張可能なフレームワーク を構築できる もともとは GUI やシミュレーションなどごく限られた目的に利用されていたが、最近ではスクリプト言語などを含めてあらゆる分野でオブジェクト技術がとりれられるようになってきている
オブジェクト指向プログラミングの基本的な手順 個々のオブジェクトが保持するデータの内容( フィールド )や振る舞い( メソッド )を クラス として定義する( クラス図 を使ってモデリング) クラスを インスタンス化 することでオブジェクトをメモリ上に生成する 生成したオブジェクトに メッセージ を投げる (public メソッドを呼び出す)ことで特定の処理の実行を依頼する あるオブジェクトは通常は 別のオブジェクトと連携 して 特定の責務を実行 する( シーケンス図 を使ってモデリング)
オブジェクトが「使える」ように するまでに必要な準備 OOP では、いったん必要なオブジェクトの生成が行われれば、責務を持ったオブジェクトに単にメッセージ(メソッド)を呼び出すだけなので非常に簡単だが。。。 あるオブジェクトが適切に動作するためには、すべて依存オブジェクトが生成され、適切に初期化されてされている必要がある 以上の問題点は OOP の最初の説明では無視されることが多いが、実際にモックなしで JUnit を書いてみれば、その大変さが実感できる
オブジェクト生成のプログラミングは意外に奥が深い Java では単に new 演算子を使ってオブジェクトが生成できると教わるが。。。 実際のアプリケーション設計では、オブジェクト生成に関して以下のような問題を考慮しなくてはならない 課題1:オブジェクト間の複雑な依存関係の適切な初期化 依存オブジェクトのまたその先の依存オブジェクトを正しい順序で初期化する必要性 課題2:設定情報や DB 接続など、グローバルに共通のオブジェクトを共有する必要性 課題3:テスト容易性や拡張性を向上させるため、オブジェクト同士がインタフェースのみに依存するようにする必要性
課題1:複雑な依存関係の初期化 コントローラが動作するためには、サービスが、サービスが動作するためには DAO がという具合に依存するオブジェクトを適切な順序で生成、初期化しておく必要がある 業務ロジック中で Java の new を直接使って初期化処理をハードコードすると、以下のような問題点がある オブジェクトの関連を拡張したり、変更したりすることが難しくなる オブジェクトの準備のための配管コードが多数を占めるようになり、本質的に重要な業務処理の記述が埋もれてしまう
伝統的な解決策: 手製ファクトリの利用 DI 発明以前は、 デザインパターン を駆使することで、生成ロジックを「 ファクトリ 」と呼ばれる特定のクラスやメソッドにカプセル化する 有名な GoF のデザインパターンの中でもオブジェクトの生成は重要なテーマの一つ Factory Method パターン 抽象メソッドにより実際の生成対象のオブジェクトをサブクラスで決める Abstract Factory パターン 関連するオブジェクトの生成を抽象化するインタフェースを定義する Protytype パターン 雛型となるオブジェクトをクローンすることで個別のインスタンスを生成する
手製ファクトリ利用の問題点 デザインパターンなどの考え方を利用できるとはいえ、プロジェクトごとに独自にファクトリを設計するのは敷居が高い 業務ロジック意外に、ファクトリや付随するインタフェースなどたくさん書かなくてはならない
課題2:グローバルにオブジェクトを共有 システムの中では使うたびに new するのではなく、特定のオブジェクトをグローバルに共有したいことが多い 共有化したいオブジェクトの例 毎回生成するのが重たいリソースオブジェクト DB やメッセージキューに対する接続先 O/R マップ FW のコンテキストファクトリ リモートサービスに対する参照 ログ出力先 共通情報 システム設定プロパティ エラーメッセージ文字列リソース システムステータス
伝統的な解決策: 独自 Singleton パターンの利用 グローバル情報のアクセスのために、独自に Singleton デザインパターンや Service Locator パターンを利用する public class AppConfig { private  static  final INSTANCE= new AppConfig(); public  static  AppConfig getInstance() { return INSTANCE; }     //  コンストラクタを隠蔽 private  AppConfig () {} … } public class SomeServiceImpl { public void userAppConfig() { int val =  AppConfig.getInstance() .getSomeProperty(); } } Static メソッド経由で、特定のインスタンスを共有
Singleton パターンは 大部分はアンチパターン? GoF の本来の Singleton パターンは「 唯一のオブジェクトに限定 」というのがもともとの使用目的という思想だったが、たいていは グローバル変数の代用 として 気軽に利用され過ぎる傾向 がある Singleton パターンは static メソッドに依存しているため、単体試験の際にモックのメソッドに置き換えて試験することが難しい 特に、 データソースや EJB 参照の取得を Singleton を使って実装すると呼び出し側のプログラムが JNDI などコンテナ環境に依存するため、単体テストが非常に難しくなる
課題3:オブジェクト同士がインタフェースのみに依存するようにする オブジェクト指向プログラミングの最も重要な設計方針 「実装ではなく、インタフェースに対してプログラミングすべし」 依存元が依存先オブジェクトの実装ではなくインタフェースのみに依存することで以下のメリットが得られる 共通のインタフェースを実装した別のサブクラスに 実装を自由に置き換えられる ( Strategy 、 Command 、 State など大部分のデザインパターンの基礎原理) 対象オブジェクトをラップすることで 容易に機能を拡張できる (  Proxy 、  Decorator パターン)
Strategy パターンの例
Proxy パターンの例
IF のみに依存するコードを書くことは実は結構難しい 単にインタフェース型を定義して、 implements すればよいわけでない! インタフェースに対して new を呼び出すことはできないため、結局 new をハードコードしたら特定の具象サブクラスに依存してしまう public class CustomerService { private CustomerDao customerDao =  new JpaCustomerDao(); } 直接 new したら、結局インタフェース型のフィールドを宣言している意味がなくなる!!
課題 1 ~ 3 すべてに対する解決策? Dependency Injection Dependency Injection( 依存性の注入) 従来はアプリケーションごとに独自のファクトリやシングルトンを駆使して設計していたため、正しく設計するためには相当敷居が高かった 一方、 DI では DI コンテナフレームワークが汎用のファクトリとして機能する DI によりオブジェクトの生成や依存関係の設定が自動化されるため、プログラム中では生成済みのオブジェクトを使えばよい 結果として、インタフェースのみに依存するプログラムを作成することが非常に簡単になる
伝統的な setter インジェクション Spring FW では伝統的に setter メソッドを使って依存オブジェクトを設定する public class CustomerService { private CustomerDao customerDao; public void setCustomerDao( CustomerDao customerDao) { this.customerDao = customerDao; }  } <bean id=“customerService&quot; class=“…CustomerImpl”> <property name=“customerDao“ ref=“customerDao”/> </bean> XML ファイル中でセッターに対応するプロパティに依存関係をインジェクションする
Java コードが XML に移動しただけでは? オブジェクト生成、関連付けの Java コードは不要になった一方で、 XML の設定ファイルに生成に必要なメタ情報を記述する必要がある 確かに XML を含めた全体のコード量は変わらないが、以下の点で多大なメリットがある サービスや接続ファクトリなどのオブジェクトを簡単に共有できる インタフェースのみに依存するようにすることが簡単に実現できる 通常はサービスや DAO など粒度の大きなコンポーネントのみを DI 管理する(newの使用をすべて禁止するわけではない!)
設定ファイルを少なくする工夫 ?アノテーションインジェクション 以前から「自動ワイヤリング機能」といって同一の型あるいは Bean 名の一致により自動インジェクションする機能はあったが、一致ロジックが固定的なため、実際使える場面は限定的 Spring2.5 ではアノテーションを使った自動インジェクション機能がサポートされる public class CustomerService { @Autowired   private CustomerDao customerDao; }
アノテーションインジェクションは JavaEE 標準でも採用されている @EJB?EJB 参照をインジェクション @Resource? データソースなどのリソースをインジェクション @PersistenceContext?JPA のエンティティマネージャをインジェクション DI スタイルプログラミング技法の発見は、 Java プログラミングの世界では OO 自体の発見と同じくらい重要な出来事であり、「パラダイムシフト」と呼んでいる人もいるくらいである。 最近はさまざまな FW や標準仕様が DI の考え方を採用している。
DI コンテナのその他の便利機能 オブジェクト生成スコープの調整機能 デフォルトでは DI コンテナで生成されるインスタンスは宣言につき 1 個( Singleton ) 毎回生成( Protytype )、 Web リクエストごとに生成、セッションごとに生成などに変更可 オブジェクトライフサイクルコールバック 生成時、廃棄時に特定の処理を記述 AOP 機能との連携 プロキシ生成機能 ロードタイムウィービング機能
他のソリューションと比較して Spring FW の優れている点 Web 層、サービス層、 DAO 層すべてにわたって共通フォーマット設定ファイル、共通の IF が利用できるため、設計に統一感が出る 世界中で利用実績のあるデファクトスタンダード 今のところ、 JDK1.4 や EJB2.0 などのレガシー技術を見捨てていないため、幅広いプロジェクトで活用できる (Seam や Seasar などの tiger や JavaEE5 前提の FW と対照的)
Ad

Recommended

顿滨(依存性注入)について
顿滨(依存性注入)について
Yui Ito
?
笔辞蝉迟驳谤别厂蚕尝でスケールアウト
笔辞蝉迟驳谤别厂蚕尝でスケールアウト
Masahiko Sawada
?
Alpine linuxを触ってみよう
Alpine linuxを触ってみよう
Ryo Adachi
?
摆顿尝轮読会闭础濒辫丑补厂迟补谤とその関连技术
摆顿尝轮読会闭础濒辫丑补厂迟补谤とその関连技术
Deep Learning JP
?
贬础环境构筑のベスト?プラクティス
贬础环境构筑のベスト?プラクティス
EnterpriseDB
?
はじめよう骋颈迟
はじめよう骋颈迟
techscore
?
颁++の迟别尘辫濒补迟别特殊化的なことを颁#でやった话
颁++の迟别尘辫濒补迟别特殊化的なことを颁#でやった话
Atsushi Kambara
?
Microsoft License の基本
Microsoft License の基本
祥子 松山
?
コンテナネットワーキング(颁狈滨)最前线
コンテナネットワーキング(颁狈滨)最前线
Motonori Shindo
?
QGISプログラミング入門 FOSS4G 2013 Hokkaido
QGISプログラミング入門 FOSS4G 2013 Hokkaido
Kosuke Asahi
?
いつやるの?骋颈迟入门
いつやるの?骋颈迟入门
Masakazu Matsushita
?
搁别蝉狈别迟の仕组み
搁别蝉狈别迟の仕组み
Kota Nagasato
?
骋颈迟贬耻产の使い方
骋颈迟贬耻产の使い方
Atelier Frameworks
?
【DL輪読会】AUTOGT: AUTOMATED GRAPH TRANSFORMER ARCHITECTURE SEARCH
【DL輪読会】AUTOGT: AUTOMATED GRAPH TRANSFORMER ARCHITECTURE SEARCH
Deep Learning JP
?
贵笔骋础のトレンドをまとめてみた
贵笔骋础のトレンドをまとめてみた
Takefumi MIYOSHI
?
鲍贰4ディープラーニングってやつでなんとかして!环境构筑编(笔测迟丑辞苍3+罢别苍蝉辞谤贵濒辞飞)
鲍贰4ディープラーニングってやつでなんとかして!环境构筑编(笔测迟丑辞苍3+罢别苍蝉辞谤贵濒辞飞)
エピック?ゲームズ?ジャパン Epic Games Japan
?
第22回オープンデータトーク 地理データ形式のこれから
第22回オープンデータトーク 地理データ形式のこれから
IWASAKI NOBUSUKE
?
狈辞诲别-谤别诲+闯厂翱狈补迟补で蹿耻苍肠迟颈辞苍地狱からの卒业
狈辞诲别-谤别诲+闯厂翱狈补迟补で蹿耻苍肠迟颈辞苍地狱からの卒业
kazuhiro harada
?
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
NTT DATA Technology & Innovation
?
罢翱笔笔贰搁厂の开発も出来ちゃう痴厂颁辞诲别のビルド&デバッグ使いこなし术
罢翱笔笔贰搁厂の开発も出来ちゃう痴厂颁辞诲别のビルド&デバッグ使いこなし术
Hiroaki Nagashima
?
ガイデットフィルタとその周辺
ガイデットフィルタとその周辺
Norishige Fukushima
?
使ってみませんか?辫驳冲丑颈苍迟冲辫濒补苍
使ってみませんか?辫驳冲丑颈苍迟冲辫濒补苍
NTT DATA OSS Professional Services
?
础苍诲谤辞颈诲组込み开発基础コース 础谤尘补诲颈濒濒辞-440编
础苍诲谤辞颈诲组込み开発基础コース 础谤尘补诲颈濒濒辞-440编
OESF Education
?
Jetson TK1でSemi-Global Matching
Jetson TK1でSemi-Global Matching
Ryo Sakamoto
?
叁次元表现まとめ(深层学习を中心に)
叁次元表现まとめ(深层学习を中心に)
Tomohiro Motoda
?
グラフと木
グラフと木
京大 マイコンクラブ
?
罢谤补苍蝉蹿辞谤尘别谤を雰囲気で理解する
罢谤补苍蝉蹿辞谤尘别谤を雰囲気で理解する
AtsukiYamaguchi1
?
Creating and Using Links between Data Objects
Creating and Using Links between Data Objects
Mitsuo Yamamoto
?
2010 icse-an analysis of the variability in forty preprocessor-based software...
2010 icse-an analysis of the variability in forty preprocessor-based software...
n-yuki
?

More Related Content

What's hot (20)

コンテナネットワーキング(颁狈滨)最前线
コンテナネットワーキング(颁狈滨)最前线
Motonori Shindo
?
QGISプログラミング入門 FOSS4G 2013 Hokkaido
QGISプログラミング入門 FOSS4G 2013 Hokkaido
Kosuke Asahi
?
いつやるの?骋颈迟入门
いつやるの?骋颈迟入门
Masakazu Matsushita
?
搁别蝉狈别迟の仕组み
搁别蝉狈别迟の仕组み
Kota Nagasato
?
骋颈迟贬耻产の使い方
骋颈迟贬耻产の使い方
Atelier Frameworks
?
【DL輪読会】AUTOGT: AUTOMATED GRAPH TRANSFORMER ARCHITECTURE SEARCH
【DL輪読会】AUTOGT: AUTOMATED GRAPH TRANSFORMER ARCHITECTURE SEARCH
Deep Learning JP
?
贵笔骋础のトレンドをまとめてみた
贵笔骋础のトレンドをまとめてみた
Takefumi MIYOSHI
?
鲍贰4ディープラーニングってやつでなんとかして!环境构筑编(笔测迟丑辞苍3+罢别苍蝉辞谤贵濒辞飞)
鲍贰4ディープラーニングってやつでなんとかして!环境构筑编(笔测迟丑辞苍3+罢别苍蝉辞谤贵濒辞飞)
エピック?ゲームズ?ジャパン Epic Games Japan
?
第22回オープンデータトーク 地理データ形式のこれから
第22回オープンデータトーク 地理データ形式のこれから
IWASAKI NOBUSUKE
?
狈辞诲别-谤别诲+闯厂翱狈补迟补で蹿耻苍肠迟颈辞苍地狱からの卒业
狈辞诲别-谤别诲+闯厂翱狈补迟补で蹿耻苍肠迟颈辞苍地狱からの卒业
kazuhiro harada
?
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
NTT DATA Technology & Innovation
?
罢翱笔笔贰搁厂の开発も出来ちゃう痴厂颁辞诲别のビルド&デバッグ使いこなし术
罢翱笔笔贰搁厂の开発も出来ちゃう痴厂颁辞诲别のビルド&デバッグ使いこなし术
Hiroaki Nagashima
?
ガイデットフィルタとその周辺
ガイデットフィルタとその周辺
Norishige Fukushima
?
使ってみませんか?辫驳冲丑颈苍迟冲辫濒补苍
使ってみませんか?辫驳冲丑颈苍迟冲辫濒补苍
NTT DATA OSS Professional Services
?
础苍诲谤辞颈诲组込み开発基础コース 础谤尘补诲颈濒濒辞-440编
础苍诲谤辞颈诲组込み开発基础コース 础谤尘补诲颈濒濒辞-440编
OESF Education
?
Jetson TK1でSemi-Global Matching
Jetson TK1でSemi-Global Matching
Ryo Sakamoto
?
叁次元表现まとめ(深层学习を中心に)
叁次元表现まとめ(深层学习を中心に)
Tomohiro Motoda
?
グラフと木
グラフと木
京大 マイコンクラブ
?
罢谤补苍蝉蹿辞谤尘别谤を雰囲気で理解する
罢谤补苍蝉蹿辞谤尘别谤を雰囲気で理解する
AtsukiYamaguchi1
?
コンテナネットワーキング(颁狈滨)最前线
コンテナネットワーキング(颁狈滨)最前线
Motonori Shindo
?
QGISプログラミング入門 FOSS4G 2013 Hokkaido
QGISプログラミング入門 FOSS4G 2013 Hokkaido
Kosuke Asahi
?
搁别蝉狈别迟の仕组み
搁别蝉狈别迟の仕组み
Kota Nagasato
?
【DL輪読会】AUTOGT: AUTOMATED GRAPH TRANSFORMER ARCHITECTURE SEARCH
【DL輪読会】AUTOGT: AUTOMATED GRAPH TRANSFORMER ARCHITECTURE SEARCH
Deep Learning JP
?
贵笔骋础のトレンドをまとめてみた
贵笔骋础のトレンドをまとめてみた
Takefumi MIYOSHI
?
鲍贰4ディープラーニングってやつでなんとかして!环境构筑编(笔测迟丑辞苍3+罢别苍蝉辞谤贵濒辞飞)
鲍贰4ディープラーニングってやつでなんとかして!环境构筑编(笔测迟丑辞苍3+罢别苍蝉辞谤贵濒辞飞)
エピック?ゲームズ?ジャパン Epic Games Japan
?
第22回オープンデータトーク 地理データ形式のこれから
第22回オープンデータトーク 地理データ形式のこれから
IWASAKI NOBUSUKE
?
狈辞诲别-谤别诲+闯厂翱狈补迟补で蹿耻苍肠迟颈辞苍地狱からの卒业
狈辞诲别-谤别诲+闯厂翱狈补迟补で蹿耻苍肠迟颈辞苍地狱からの卒业
kazuhiro harada
?
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
NTT DATA Technology & Innovation
?
罢翱笔笔贰搁厂の开発も出来ちゃう痴厂颁辞诲别のビルド&デバッグ使いこなし术
罢翱笔笔贰搁厂の开発も出来ちゃう痴厂颁辞诲别のビルド&デバッグ使いこなし术
Hiroaki Nagashima
?
ガイデットフィルタとその周辺
ガイデットフィルタとその周辺
Norishige Fukushima
?
础苍诲谤辞颈诲组込み开発基础コース 础谤尘补诲颈濒濒辞-440编
础苍诲谤辞颈诲组込み开発基础コース 础谤尘补诲颈濒濒辞-440编
OESF Education
?
Jetson TK1でSemi-Global Matching
Jetson TK1でSemi-Global Matching
Ryo Sakamoto
?
叁次元表现まとめ(深层学习を中心に)
叁次元表现まとめ(深层学习を中心に)
Tomohiro Motoda
?
罢谤补苍蝉蹿辞谤尘别谤を雰囲気で理解する
罢谤补苍蝉蹿辞谤尘别谤を雰囲気で理解する
AtsukiYamaguchi1
?

Similar to 顿颈入门 (20)

Creating and Using Links between Data Objects
Creating and Using Links between Data Objects
Mitsuo Yamamoto
?
2010 icse-an analysis of the variability in forty preprocessor-based software...
2010 icse-an analysis of the variability in forty preprocessor-based software...
n-yuki
?
オブジェクト指向入门6
オブジェクト指向入门6
Kenta Hattori
?
贬辞飞迟辞よいデザイン
贬辞飞迟辞よいデザイン
Hiroki Yagita
?
「モダンな」可视化アプリケーション开発とはどのようなものか?
「モダンな」可视化アプリケーション开発とはどのようなものか?
Keiichiro Ono
?
第2回肠#画像処理讲习
第2回肠#画像処理讲习
Koshiro Miyauchi
?
オブジェクト指向最强
オブジェクト指向最强
haganemetal
?
Linked Open Dataで市民協働と情報技術者をつなげる試み
Linked Open Dataで市民協働と情報技術者をつなげる試み
Shun Shiramatsu
?
CMSI計算科学技術特論C (2015) 可読性と性能の両立を目指して
CMSI計算科学技術特論C (2015) 可読性と性能の両立を目指して
Computational Materials Science Initiative
?
Object oriented
Object oriented
Toru Takefusa
?
顿箩补苍驳辞とは
顿箩补苍驳辞とは
Gomamatsu
?
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer
増田 亨
?
「解説資料」ViTPose: Simple Vision Transformer Baselines for Human Pose Estimation
「解説資料」ViTPose: Simple Vision Transformer Baselines for Human Pose Estimation
Takumi Ohkuma
?
【DL輪読会】ViTPose: Simple Vision Transformer Baselines for Human Pose Estimation
【DL輪読会】ViTPose: Simple Vision Transformer Baselines for Human Pose Estimation
Deep Learning JP
?
第1回 モデリング勉強会
第1回 モデリング勉強会
hakoika-itwg
?
オブジェクト指向の设计と実装の学び方のコツ
オブジェクト指向の设计と実装の学び方のコツ
増田 亨
?
設計/ドメイン設計(4) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第26回】
設計/ドメイン設計(4) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第26回】
Tomoharu ASAMI
?
【DL輪読会】論文解説:Offline Reinforcement Learning as One Big Sequence Modeling Problem
【DL輪読会】論文解説:Offline Reinforcement Learning as One Big Sequence Modeling Problem
Deep Learning JP
?
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes ?PFN、ヤフー?
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes ?PFN、ヤフー?
Preferred Networks
?
分析モデル 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第44回】
分析モデル 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第44回】
Tomoharu ASAMI
?
Creating and Using Links between Data Objects
Creating and Using Links between Data Objects
Mitsuo Yamamoto
?
2010 icse-an analysis of the variability in forty preprocessor-based software...
2010 icse-an analysis of the variability in forty preprocessor-based software...
n-yuki
?
オブジェクト指向入门6
オブジェクト指向入门6
Kenta Hattori
?
贬辞飞迟辞よいデザイン
贬辞飞迟辞よいデザイン
Hiroki Yagita
?
「モダンな」可视化アプリケーション开発とはどのようなものか?
「モダンな」可视化アプリケーション开発とはどのようなものか?
Keiichiro Ono
?
第2回肠#画像処理讲习
第2回肠#画像処理讲习
Koshiro Miyauchi
?
オブジェクト指向最强
オブジェクト指向最强
haganemetal
?
Linked Open Dataで市民協働と情報技術者をつなげる試み
Linked Open Dataで市民協働と情報技術者をつなげる試み
Shun Shiramatsu
?
顿箩补苍驳辞とは
顿箩补苍驳辞とは
Gomamatsu
?
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer
増田 亨
?
「解説資料」ViTPose: Simple Vision Transformer Baselines for Human Pose Estimation
「解説資料」ViTPose: Simple Vision Transformer Baselines for Human Pose Estimation
Takumi Ohkuma
?
【DL輪読会】ViTPose: Simple Vision Transformer Baselines for Human Pose Estimation
【DL輪読会】ViTPose: Simple Vision Transformer Baselines for Human Pose Estimation
Deep Learning JP
?
第1回 モデリング勉強会
第1回 モデリング勉強会
hakoika-itwg
?
オブジェクト指向の设计と実装の学び方のコツ
オブジェクト指向の设计と実装の学び方のコツ
増田 亨
?
設計/ドメイン設計(4) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第26回】
設計/ドメイン設計(4) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第26回】
Tomoharu ASAMI
?
【DL輪読会】論文解説:Offline Reinforcement Learning as One Big Sequence Modeling Problem
【DL輪読会】論文解説:Offline Reinforcement Learning as One Big Sequence Modeling Problem
Deep Learning JP
?
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes ?PFN、ヤフー?
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes ?PFN、ヤフー?
Preferred Networks
?
分析モデル 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第44回】
分析モデル 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第44回】
Tomoharu ASAMI
?
Ad

顿颈入门

  • 1. DI 入門 DI コンテナを導入する意義 について理解する
  • 2. 構造化設計とオブジェクト指向設計の思想の違いを理解する そもそも、 DI の考え方を理解する前提として、 オブジェクト指向的なプログラム設計 について理解しておかなくてはならない 伝統的な構造化型プログラミングではプログラムを処理の固まり単位に分割し、メインから順次下位のサブルーチンをコールする 一方、オブジェクト指向できちんと設計されたシステムであれば、 「特定の責務」を持ったオブジェクト が互いにメッセージをやりとりすることで特定の機能が実現される
  • 3. 構造化型アーキテクチャ プログラムを順次細分化された 処理の集合 として構築 データはパラメータやグローバル変数として処理とは別に管理 プログラムの状態としてのデータがカプセル化されていないため、上位関数は下位関数の処理の細部を原則知っていることが前提(実質的に巨大なアルゴリズム) バッチなどの定型処理や小規模スクリプトなど単純なケースを除いて、 GUI や分散処理など、 今日の複雑なプログラムの作成には向かない main 関数 初期処理 データ更新処理 DB 接続オープン処理 SQL 文発行処理 DB 接続クローズ処理 更新件数表示処理 グローバルデータ パラメータ
  • 4. オブジェクト指向アーキテクチャ 責務 が明確に分かれた オブジェクト単位 に分割 担当オブジェクトに順次処理を委譲 ロジックとデータはオブジェクト内部に カプセル化 外から呼び出される public なインタフェース と 内部の実装 とが明確に分離される コントローラ サービス DAO エンティティマネージャ ビュー エンティティ DTO 接続プール データソース 画面描画 画面遷移ロジック ビジネスロジック バリデータ データ転送 業務固有データ 永続処理 入力チェック
  • 5. オブジェクト指向のメリット オブジェクトを部品として 再利用 できる 基本的な 部品を組み合わせる ことで複雑で大規模なプログラムを構築できる 継承、動的バインディングなどのプログラミング手法を利用することにより、元のソースコードに手を加えることなく 拡張可能なフレームワーク を構築できる もともとは GUI やシミュレーションなどごく限られた目的に利用されていたが、最近ではスクリプト言語などを含めてあらゆる分野でオブジェクト技術がとりれられるようになってきている
  • 6. オブジェクト指向プログラミングの基本的な手順 個々のオブジェクトが保持するデータの内容( フィールド )や振る舞い( メソッド )を クラス として定義する( クラス図 を使ってモデリング) クラスを インスタンス化 することでオブジェクトをメモリ上に生成する 生成したオブジェクトに メッセージ を投げる (public メソッドを呼び出す)ことで特定の処理の実行を依頼する あるオブジェクトは通常は 別のオブジェクトと連携 して 特定の責務を実行 する( シーケンス図 を使ってモデリング)
  • 7. オブジェクトが「使える」ように するまでに必要な準備 OOP では、いったん必要なオブジェクトの生成が行われれば、責務を持ったオブジェクトに単にメッセージ(メソッド)を呼び出すだけなので非常に簡単だが。。。 あるオブジェクトが適切に動作するためには、すべて依存オブジェクトが生成され、適切に初期化されてされている必要がある 以上の問題点は OOP の最初の説明では無視されることが多いが、実際にモックなしで JUnit を書いてみれば、その大変さが実感できる
  • 8. オブジェクト生成のプログラミングは意外に奥が深い Java では単に new 演算子を使ってオブジェクトが生成できると教わるが。。。 実際のアプリケーション設計では、オブジェクト生成に関して以下のような問題を考慮しなくてはならない 課題1:オブジェクト間の複雑な依存関係の適切な初期化 依存オブジェクトのまたその先の依存オブジェクトを正しい順序で初期化する必要性 課題2:設定情報や DB 接続など、グローバルに共通のオブジェクトを共有する必要性 課題3:テスト容易性や拡張性を向上させるため、オブジェクト同士がインタフェースのみに依存するようにする必要性
  • 9. 課題1:複雑な依存関係の初期化 コントローラが動作するためには、サービスが、サービスが動作するためには DAO がという具合に依存するオブジェクトを適切な順序で生成、初期化しておく必要がある 業務ロジック中で Java の new を直接使って初期化処理をハードコードすると、以下のような問題点がある オブジェクトの関連を拡張したり、変更したりすることが難しくなる オブジェクトの準備のための配管コードが多数を占めるようになり、本質的に重要な業務処理の記述が埋もれてしまう
  • 10. 伝統的な解決策: 手製ファクトリの利用 DI 発明以前は、 デザインパターン を駆使することで、生成ロジックを「 ファクトリ 」と呼ばれる特定のクラスやメソッドにカプセル化する 有名な GoF のデザインパターンの中でもオブジェクトの生成は重要なテーマの一つ Factory Method パターン 抽象メソッドにより実際の生成対象のオブジェクトをサブクラスで決める Abstract Factory パターン 関連するオブジェクトの生成を抽象化するインタフェースを定義する Protytype パターン 雛型となるオブジェクトをクローンすることで個別のインスタンスを生成する
  • 12. 課題2:グローバルにオブジェクトを共有 システムの中では使うたびに new するのではなく、特定のオブジェクトをグローバルに共有したいことが多い 共有化したいオブジェクトの例 毎回生成するのが重たいリソースオブジェクト DB やメッセージキューに対する接続先 O/R マップ FW のコンテキストファクトリ リモートサービスに対する参照 ログ出力先 共通情報 システム設定プロパティ エラーメッセージ文字列リソース システムステータス
  • 13. 伝統的な解決策: 独自 Singleton パターンの利用 グローバル情報のアクセスのために、独自に Singleton デザインパターンや Service Locator パターンを利用する public class AppConfig { private static final INSTANCE= new AppConfig(); public static AppConfig getInstance() { return INSTANCE; }    // コンストラクタを隠蔽 private AppConfig () {} … } public class SomeServiceImpl { public void userAppConfig() { int val = AppConfig.getInstance() .getSomeProperty(); } } Static メソッド経由で、特定のインスタンスを共有
  • 14. Singleton パターンは 大部分はアンチパターン? GoF の本来の Singleton パターンは「 唯一のオブジェクトに限定 」というのがもともとの使用目的という思想だったが、たいていは グローバル変数の代用 として 気軽に利用され過ぎる傾向 がある Singleton パターンは static メソッドに依存しているため、単体試験の際にモックのメソッドに置き換えて試験することが難しい 特に、 データソースや EJB 参照の取得を Singleton を使って実装すると呼び出し側のプログラムが JNDI などコンテナ環境に依存するため、単体テストが非常に難しくなる
  • 15. 課題3:オブジェクト同士がインタフェースのみに依存するようにする オブジェクト指向プログラミングの最も重要な設計方針 「実装ではなく、インタフェースに対してプログラミングすべし」 依存元が依存先オブジェクトの実装ではなくインタフェースのみに依存することで以下のメリットが得られる 共通のインタフェースを実装した別のサブクラスに 実装を自由に置き換えられる ( Strategy 、 Command 、 State など大部分のデザインパターンの基礎原理) 対象オブジェクトをラップすることで 容易に機能を拡張できる ( Proxy 、 Decorator パターン)
  • 18. IF のみに依存するコードを書くことは実は結構難しい 単にインタフェース型を定義して、 implements すればよいわけでない! インタフェースに対して new を呼び出すことはできないため、結局 new をハードコードしたら特定の具象サブクラスに依存してしまう public class CustomerService { private CustomerDao customerDao = new JpaCustomerDao(); } 直接 new したら、結局インタフェース型のフィールドを宣言している意味がなくなる!!
  • 19. 課題 1 ~ 3 すべてに対する解決策? Dependency Injection Dependency Injection( 依存性の注入) 従来はアプリケーションごとに独自のファクトリやシングルトンを駆使して設計していたため、正しく設計するためには相当敷居が高かった 一方、 DI では DI コンテナフレームワークが汎用のファクトリとして機能する DI によりオブジェクトの生成や依存関係の設定が自動化されるため、プログラム中では生成済みのオブジェクトを使えばよい 結果として、インタフェースのみに依存するプログラムを作成することが非常に簡単になる
  • 20. 伝統的な setter インジェクション Spring FW では伝統的に setter メソッドを使って依存オブジェクトを設定する public class CustomerService { private CustomerDao customerDao; public void setCustomerDao( CustomerDao customerDao) { this.customerDao = customerDao; } } <bean id=“customerService&quot; class=“…CustomerImpl”> <property name=“customerDao“ ref=“customerDao”/> </bean> XML ファイル中でセッターに対応するプロパティに依存関係をインジェクションする
  • 21. Java コードが XML に移動しただけでは? オブジェクト生成、関連付けの Java コードは不要になった一方で、 XML の設定ファイルに生成に必要なメタ情報を記述する必要がある 確かに XML を含めた全体のコード量は変わらないが、以下の点で多大なメリットがある サービスや接続ファクトリなどのオブジェクトを簡単に共有できる インタフェースのみに依存するようにすることが簡単に実現できる 通常はサービスや DAO など粒度の大きなコンポーネントのみを DI 管理する(newの使用をすべて禁止するわけではない!)
  • 22. 設定ファイルを少なくする工夫 ?アノテーションインジェクション 以前から「自動ワイヤリング機能」といって同一の型あるいは Bean 名の一致により自動インジェクションする機能はあったが、一致ロジックが固定的なため、実際使える場面は限定的 Spring2.5 ではアノテーションを使った自動インジェクション機能がサポートされる public class CustomerService { @Autowired private CustomerDao customerDao; }
  • 23. アノテーションインジェクションは JavaEE 標準でも採用されている @EJB?EJB 参照をインジェクション @Resource? データソースなどのリソースをインジェクション @PersistenceContext?JPA のエンティティマネージャをインジェクション DI スタイルプログラミング技法の発見は、 Java プログラミングの世界では OO 自体の発見と同じくらい重要な出来事であり、「パラダイムシフト」と呼んでいる人もいるくらいである。 最近はさまざまな FW や標準仕様が DI の考え方を採用している。
  • 24. DI コンテナのその他の便利機能 オブジェクト生成スコープの調整機能 デフォルトでは DI コンテナで生成されるインスタンスは宣言につき 1 個( Singleton ) 毎回生成( Protytype )、 Web リクエストごとに生成、セッションごとに生成などに変更可 オブジェクトライフサイクルコールバック 生成時、廃棄時に特定の処理を記述 AOP 機能との連携 プロキシ生成機能 ロードタイムウィービング機能
  • 25. 他のソリューションと比較して Spring FW の優れている点 Web 層、サービス層、 DAO 層すべてにわたって共通フォーマット設定ファイル、共通の IF が利用できるため、設計に統一感が出る 世界中で利用実績のあるデファクトスタンダード 今のところ、 JDK1.4 や EJB2.0 などのレガシー技術を見捨てていないため、幅広いプロジェクトで活用できる (Seam や Seasar などの tiger や JavaEE5 前提の FW と対照的)