DIコンテナーの採用は一種の代償行動なのかも知れません

| コメント(0)

前の記事の論旨が微妙に(かなり?)飛躍していることに気付いたので補足しておきます。

まず、DIパターンやDIコンテナーを使うことの目的は、直接的には、モジュール間(より具体的には、例えばドメインモデルとORMというようなレイヤー間)の結合性を疎にすることです。

「Mooseのアトリビュートへ依存オブジェクトを持たせることでも疎結合に出来る」というdannさんの指摘(DIとは何か 番外編 - DIコンテナを使わずにModelのTestabilityを高める方法)が一つの具体例ですが、元々Perlは(動的言語であるので)イントロスペクション(オブジェクトの中身を実行時に参照すること)のみならず実行時のDI自体はお手の物です。従って、DIがなければ死にそうなくらい大変かというと、必ずしもその通りではありません。

ただ、あまり根を詰めずとも試験容易性(テスタビリティー)の向上という利益が得られるという点で、DIコンテナーのお世話になる費用対効果が大きいと判断しました。私は怠け者なのです。

さらに、DI採用によって将来的に(今回は使用を一旦留保した)新進気鋭のモジュールに切り替え易くするという狙いもあります。これは「新進気鋭のモジュールを活用する実装を一旦断念して、定番のモジュールを活用することにした」という自分自身の負い目に対する代償行動のようですが、これこそが今回DIコンテナーのお世話になることに決めた最大の理由だと自己分析しています。

ということで、何故突然DIコンテナーを実用してみようかと思ったのか、その辺りの事情についての補足でした。前段と後段の内容の結節点となるこの補足がないと、何が何だか分かりませんでしたね。補足があっても寝不足気味なので変なことを書いているおそれがありますが。

コメントする

筆者"Gardejo"について

  • Twitter: @gardejo
  • GitHub: gardejo
  • CodeRepos: gardejo
  • CPAN: MORIYA

このサイトについて

Eorzea System Worksは、架空のシステム開発結社です。

FF14.name (FinalFantasyXIV.name)では、アヴァター(プレイヤーキャラクター)の管理システムやイベント出欠・リマインダシステムや、リンクシェル(LS)運営・管理システムやDKPシステムなどを設計・開発・公開する予定です。

関連サイト

関連サイトでは、他にもFF14に関連するサイトをいくつか紹介しています。

リンク, トラックバック歓迎

このブログへのリンク(どのページでも構いません)やトラックバックを歓迎します。

設計・開発・運用の参考にさせていただきますので、コメントもお気軽にお寄せください!

個別の記事に対するご意見などのほか、目安箱もご用意しています。

このブログ記事について

このページは、Gardejoが2009年10月22日 01:24に書いたブログ記事です。

ひとつ前のブログ記事は「開発近況: モジュール群を冒険から安定へ (でもDIコンテナーに着目中)」です。

次のブログ記事は「ORMスキーマとドメインモデルを統合する方法・分離する方法」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

2014年2月

            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28  

やや真面目なサイト