タグ

DIに関するuronim1のブックマーク (18)

  • InfoQ: 依存性注入(DI)は成功したか?

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    InfoQ: 依存性注入(DI)は成功したか?
    uronim1
    uronim1 2007/12/22
  • C++ と DI - steps to phantasien t(2007-08-17)

    Java と DI (Dependency Injection) の世界から C++ に戻ってくると気が滅入る. すべてがくっついている. ああ... "Working Effectively With Legacy Code" に従ってバリバリと依存を引き剥がすことになるんだけれど, もうウンザリ. せめて新たに書くコードはレガシー風味とさよならしたい. DI したい. C++ にも少しは DI コンテナの実装がある. Autumn Framework とか. ただリフレクションのない C++ では DI コンテナを使う有難味が薄い. Autumn Framework のチュートリアルを見ると無力感に襲われる. 閉じた型システムの再発明. C++ の限界もあるだろうから, あまり責める気は起きない. COM のような既存のオブジェクトシステムに DI を載せることはできるかもしれない.

    uronim1
    uronim1 2007/08/18
  • DIxAOP時代のデザインパターンの検討 - レベルエンター山本大のブログ

    DIxAOP時代のDesign Patternについて記事のためにアイデアを絞っている。 その中で浮かんだパターンの1つ 「Implicit Interface Injection」パターンというのをご紹介。 対象とする問題 DIコンテナを使う場合「インターフェイスベースのプログラミングを行う」ことは1つの原則のようになっている。 インターフェイスベースプログラミングによって疎結合なモデルになる。これにより、再利用性と拡張性が向上する。 しかし、部品の再利用が主目的ではない企業システムの開発では、インターフェイスベースにすることのメリットよりも、開発の効率低下や、コードの追跡のしやすさの面でのデメリットの方が大きいと感じることが多い。 Implicit Interface Injection(暗黙のインターフェイスへの注入)パターンによる解決策 「Implicit Interface In

    DIxAOP時代のデザインパターンの検討 - レベルエンター山本大のブログ
    uronim1
    uronim1 2007/05/19
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • 【ハウツー】このバランス感覚、さすが - GoogleのDIフレームワーク"Guice"を使ってみる (1) Googleが開発したDI - Guiceとは (MYCOMジャーナル)

    Googleは3月8日(米国時間)、Guiceの初のメジャーリリースとなるGuice 1.0を公開した。GuiceはJavaで開発されたDI(Dependency Injection)フレームワーク。シンプルなアーキテクチャになっており、アノテーションやジェネリックを活用した開発が特徴。 Guiceが依存性注入できるのはコンストラクタ、フィールド、メソッドなど。セッターメソッドにかぎらず、複数の引数をとるメソッドに対しても適用できる。そのほかの特徴としてカスタムスコープ、環状依存への対応、スタティックメンバーのインジェクション対応、Spring Frameworkとの統合、AOP Allianceメソッドインターセプションなどがある。 Guiceはすでに数カ月にわたり、Googleにおけるミッションクリティカルアプリケーションにおいて採用されている。Google最大のアプリケーションである

  • google-guice - Google Code

    Put simply, Guice alleviates the need for factories and the use of new in your Java code. Think of Guice's @Inject as the new new. You will still need to write factories in some cases, but your code will not depend directly on them. Your code will be easier to change, unit test and reuse in other contexts. Guice embraces Java's type safe nature. You might think of Guice as filling in missing featu

    google-guice - Google Code
  • Yan - Home

    What is Yan? Yan container stands for Yet Another Non-intrusive container for object dependency injection. The core of Yan is a compact Java API with no dependency to any other lib. Around the tiny core, are services such as component monitoring, life cycle management, xml configuration etc. For xml configuration support, see Nuts. How is Yan similar to other IoC containers like PicoContainer and

    uronim1
    uronim1 2005/11/26
  • [ThinkIT] 第2回:DIxAOPコンテナの比較 (1/4)

    第2回ではPOJOでWebアプリケーションを実現するDIxAOPコンテナについて紹介します。今回紹介する「Seasar2」「Spring」「PicoContainer(NanoContainer)」「HiveMind」「Geronimo」の状況は表1のようになっています。 DIxAOPコンテナの位置づけは「第1回:Webアプリケーションフレームワークの比較」で紹介したように、オブジェクト間の依存性を解消するものです。これらのDIxAOPコンテナは、前回紹介したWebフレームワークや次回紹介するO/Rマッピングフレームワークとは少し異なっています。 DIxAOPコンテナは単体で使用することがあまりなく、既存のフレームワークと組み合わせて使用する場合か、ビジネスロジックをPOJOで開発してコンポーネントの再利用を考慮してシステム開発を行う場合の2点において威力を発揮します。 DIxAOPコンテ

    uronim1
    uronim1 2005/11/10
  • 特集「部品と部品の関係を切り離す」(1)

    図1●コンポーネント間の依存性 オブジェクトが他のオブジェクトを利用する場合,最も単純な方法がオブジェクトを生成したり,呼び出したりするコードを直接記述するやり方だ。これは,両者を結ぶ釘の頭が呼び出す側のオブジェクトに入り込んでいる状態と言える。利用される側のオブジェクトは釘から容易に抜けるが,頭が入っているオブジェクトの再利用は難しい。両方の釘を抜けるようにするには,何らかの媒介する仕組みが必要である。 図2●Dependency Injection(DI) JavaやC#には,クラスの階層構造と関係なく,共通のメソッドを定義するための「interface(インタフェース)」という仕組みがある。通常,あるインタフェース(interfaceX)を実装したオブジェクトを利用したいクラス(classA)は,そのインタフェースを実装したクラス(classB)を指定し,生成する必要がある(a)。こ

    特集「部品と部品の関係を切り離す」(1)
    uronim1
    uronim1 2005/08/25
  • IBM : The future of HTML, Part 1: WHATWG

    ワークプレイスを最適化し、虎ノ門に社を移転 日IBMは、2024年1月に、虎ノ門・神谷町エリアに事業所を新設し、そこに社を移転します。 ニュースリリース watsonx Graniteモデル・シリーズ、IBM watsonxモデル向けお客様保障の提供開始を発表 IBM TechXchange Conference Japan(2023年10月31日~11月1日) 無料評価版:エンタープライズ・グレードのAIモデルを構築 無料評価版:あらゆるデータを対象に、AIワークロードを拡張 SPSS Statisticsの年間サブスクリプション選択で10%割引 ストレージの構成比較から見積までを簡単に

    IBM : The future of HTML, Part 1: WHATWG
    uronim1
    uronim1 2005/08/25
  • Refactoring to DI

    Here is a fairly generic pattern for using refactoring to change an existing design with an embedded dependency into one that supports Dependency Injection (DI) for testing purposes.  In many ways, the code transformations I'll show below are similar to the ones in this article by Martin Fowler. Note: although I am a fanatical TDDer, I've not used that approach when designing this refactoring.  T

    uronim1
    uronim1 2005/08/21
  • TheServerSide | Your Java Community discussing server side development

    9 tips to improve Python performance Python performance gets a bad rap compared with languages such as Java. Use these tips to identify and fix problems in your Python code to tweak its performance. Idempotent HTTP methods and REST The Hypertext Transport Protocol requires all HTTP verbs to identify as idempotent or not. But what is an idempotent method, and how does idempotence apply to RESTful A

    uronim1
    uronim1 2005/07/06
  • http://blog.nikkeibp.co.jp/itpro/java/archives/2005/06/spring_framewor.html

  • 「従来のEJBは存在自体が間違いだった」,軽量コンテナ「Spring Framework」開発者のRod Johnson氏吠える:ITpro

    「従来のEJBは存在自体が間違いだった」,軽量コンテナ「Spring Framework」開発者のRod Johnson氏吠える 「エンティティBean(EJB:Enterprise JavaBeansに含まれるデータベース・アクセスのカプセル化機能)なんてないほうがよかった。エンティティBeanのせいで2~3年が無駄に失われてしまった」。現在,最も影響力のあるJava関連技術者の1人であるRod Johnson氏は,2005年6月21日に東京で開催された「JavaWorld DAY 2005」で,従来のJ2EE/EJBがいかに間違った存在だったかをとうとうと語った。「米国や英国で,新規のプロジェクトがエンティティBeanを採用したという話は,もはや1件も聞かない」。 Johnson氏は,広く使われている軽量コンテナ「Spring Framework」の開発者。J2EE開発者に大きな影響を

    「従来のEJBは存在自体が間違いだった」,軽量コンテナ「Spring Framework」開発者のRod Johnson氏吠える:ITpro
  • @IT:J2EE Watch [7]

    J2EE関連の最新トピックをわかりやすく解説 J2EE Watch [7] DIとAOPがサーバ・コンポーネント技術を変える スティルハウス 吉川和巳 2005/6/16 ■DIコンテナ=軽量コンテナ? 周知のとおり、DIコンテナとは、DI(Dependency Injection/依存性注入)の技法によりコンポーネント開発を一段と容易にするコンテナを指します。代表的なDIコンテナとしてはSpringやSeasarなどが有名です。これらのDIコンテナは、EJBのような「重量級のコンテナ」によるコンポーネント開発の困難さを打開するために生み出されたもので、しばしば「軽量コンテナ」と呼ばれます。 とはいえ最近では、EJB=重量コンテナ、DIコンテナ=軽量コンテナという単純な図式ではなくなりつつあります。例えば、標準化作業が大詰めを迎えているEJB 3.0では、DIの全面的な導入によって、EJB

    uronim1
    uronim1 2005/06/16
    EJB限定と思われませんように。
  • Ajax in Action

    News April 08, 2024 08 Apr'24 Worlds toughest core Java interview question The trickiest Java interview question ever asked? In five words or less, explain the red 'x' the Eclipse IDE displays at the end of the provided Java code snippet. March 04, 2024 04 Mar'24 Best crash course to learn Jenkins from scratch Need to learn Jenkins CI fast? This Jenkins tutorial will quickly get you up to speed on

  • Inversion of Control コンテナと Dependency Injection パターン

    以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 記事では、このパタ

  • http://blog.nikkeibp.co.jp/itpro/java/archives/2005/04/craig_mcclanaha.html

  • 1