오역(誤訳): 방석구

Spring Frameworkで理解するDI（1）
Spring Framework로 이해하는 DI(1)
DI：依存性の注入とは何か？
DI: 의존성 주입(Dependency Injection)이란 무엇인가?

컴포넌트component 지향 프로그래밍의 촉진

■ コンポーネントのメリット
■ 컴포넌트component의 메리트

　DIの主目的の1つはアプリケーションのコンポーネント化を促進することです。アプリケーションをコンポーネント化することで以下のようなメリットが得られます。
　DI의 주목적의 하나는 어플리케이션의 컴포넌트component화를 촉진하는 것입니다. 어플리케이션을 컴포넌트화 함으로써 다음과 같은 메리트를 얻을 수 있습니다.

• コンポーネント単位で機能を強化・改訂することができる
  컴포넌트component 단위로 기능을 강화 ・ 개정할 수 있습니다
• バグや故障を局所化できる
  버그bug나 장애를 국소화局所化 합니다
• ベンダ提供のコンポーネント等と付け替えることができる
  벤더vendor 제공의 컴포넌트component등과 교환이 가능합니다
• テストが容易になる
  테스트가 용이해집니다

参考：コンポーネントのメリットについては、「ソフトウェア開発4つの課題」（@IT FYI） に詳しいので参照してください。
참고: 컴포넌트component의 메리트에 대해서는 「소프트웨어 개발 4개의 과제」（@IT FYI）에서 상세히 다루므로 참조해주세요.

■ コンポーネント指向の実現性
■ 컴포넌트component 지향의 실현성

　コンポーネントはメリットが多いのですが、設計や実装は難しいといわれてきました。その理由は、多くのプロジェクトにとっての主目的がアプリケーションの開発であり、コンポーネント化は副産物という位置付けにあるためではないでしょうか。主目的のアプリケーション開発では疎結合など意識せずに設計や実装を行う方が簡単です。従って何の規定もなく設計や実装を行うと、疎結合やコンポーネント化にメリットがあると分かっていても結合度の高いプログラムを作ってしまいがちです。ところが、コンポーネントにしようとした機能の中に十分に疎結合化されていないオブジェクトが混入すると、部品に必要な情報（依存性）が多くなりコンポーネントとして切り出すことが難しくなってしまうのです。
　컴포넌트component는 메리트가 많지만, 설계나 구성은 어렵다고 알려져 왔습니다. 그 이유는 많은 프로젝트project에 있어서의 주목적이 어플리케이션 개발에 있어왔고, 컴포넌트component화는 단지 부산물副産物 이라는 생각이 있었기 때문이 아닐까요? 주목적인 어플리케이션 개발에서는 소결합 등을 의식하지 않고 설계나 구성을 실행하는 방법이 간단합니다. 따라서 어떤 규정도 없는 설계나 구성을 행하면, 소결합이나 컴포넌트component화에 메리트가 있다고 해도 결합도 높은 프로그램을 만들어버리기 십상입니다. 그러나, 컴포넌트component화 하려고 한 기능 중에 충분히 소결합화 되지 않은 오브젝트가 혼합된다면, 부품에 필요한 정보(의존성)가 증가되어 컴포넌트로서 독립적으로 잘라내기가 어렵게 됩니다.

　それならばまず初めにコンポーネントを開発し、その後にコンポーネントを使ったアプリケーションを開発すればよいと考えるかもしれません。しかし、コンポーネントそのものの開発を行う場合にも、設計の段階で「使い勝手」と「利用価値」の両面でパフォーマンスの高いコンポーネントを作成しておくことは難しい作業です。具体的な利用方法や要求があいまいな状態でコンポーネントを設計すると、必要以上に機能を盛り込んだコンポーネントとなってしまうか、必要な機能が含まれていないコンポーネントなどを作ってしまいがちです。せっかく手間を掛けたのに、結果としてあまり利用価値がないコンポーネントを作ってしまうのでは意味が半減してしまいます。
　그렇다면 처음부터 컴포넌트component를 개발하고, 그 후에 컴포넌트component를 사용하는 어플리케이션을 개발하면 좋지 않느냐고 생각할지도 모릅니다. 하지만, 컴포넌트component 그 자체를 개발하는 경우에도, 설계의 단계에서「사용하기 편리한 정도」와「이용가치」 양면에서 performance 높은 컴포넌트component를 작성해두는 것은 어려운 작업입니다. 구체적인 이용방법이나 요구가 분명하지 않은 상태에서 컴포넌트component를 설계하면, 필요이상의 기능을 담은 컴포넌트component가 되거나, 필요한 기능이 포함되지 않은 컴포넌트component 를 만들어버리기 십상입니다. 모처럼 공들였는데, 결과적으로 그다지 이용가치가 없는 컴포넌트component를 만들었기 때문에 그 의미는 반감 되어 버립니다.

　こういったことを考えてみると何もないところからコンポーネントを作り出すよりも、アプリケーションの実装中または実装後に部品の価値が評価され、コンポーネント化されるというプロセスを経る方が自然な流れだといえるのではないでしょうか。以前から「コンポーネント指向」というプログラムの作り方にメリットがあることはいわれていましたが、こういった理由から機能のコンポーネント化の実現性はあまり高くないのが現実でした。
　이러한 경우를 생각해보면 무無에서 컴포넌트component를 구현하는 것보다, 어플리케이션 구현 중 또는 구현 후에 부품의 가치가 평가되어, 컴포넌트화 되는 프로세스process를 거치 것이 자연스러운 흐름이라고 말할 수 있습니다. 이전부터「컴포넌트component 지향」이라는 프로그램program 구현에 메리트가 있다곤 했지만, 이러한 이유에서 기능의 컴포넌트화의 실현성은 그다지 높지 않은 것이 현실이었습니다.

■ DIによるコンポーネント化の促進
■ DI에 의한 컴포넌트화component 촉진

　通常、十分な疎結合を実現するためにはアプリケーション全体が互いの依存性を気にしながら設計・実装されなくてはなりません。そこでDIをフレームワークとして使用することで、アプリケーションが強制的に疎結合の意識された構造となるのです。よって、アプリケーションの実装後に、利用価値の高い部品をコンポーネントとして抽出することも容易になります。つまりDIを導入することで、無理をすることなく自然な流れでアプリケーションをコンポーネント化することができるのです。
　통상, 충분한 소결합을 실현하기 위해서는 어플리케이션 전체가 상호 의존성을 신경 쓰면서 설계 ・ 구현되지 않으면 안됩니다. 거기에 DI를 Framework로서 사용하는 것으로, 어플리케이션이 강제적으로 소결합의 의식된 구조가 됩니다. 그러므로, 어플리케이션의 구현 후에, 이용가치가 높은 부품을 컴포넌트component로서 추출하는 것이 용이해집니다. 요컨대 DI를 도입하는 것으로, 무리 없이 자연스럽게 어플리케이션을 컴포넌트화 할 수 있는 것입니다.

　こうして出来上がったアプリケーションはコンポーネント指向のメリットを受けることができるため、当然カスタマイズや追加開発に強いものになります。しかし、それよりもむしろDIによるコンポーネント化の一番のメリットは「開発中」に表れます。特に仕様変更やバグの修正で影響範囲を限定できるというところに大きなメリットを感じることになるでしょう。ぜひとも一度DIを利用し、仕様を変更させるという経験をしてみてください。その影響範囲の狭さに驚きを感じるはずです。仕様変更の依頼にYESと答えることが病みつきになるかもしれません。また、単体テストのためにモックオブジェクト（テスト用のダミーオブジェクト）を入れ替える作業は、設定ファイルを入れ替えるだけで済んでしまいます。
　이렇게 구현된 어플리케이션은 컴포넌트component 지향의 메리트를 가질 수 있기 때문에, 당연히 (1) 커스터마이즈customize나 추가개발에 강해집니다. 그러나, 그보다도 오히려 DI에 의한 컴포넌트화의 최고 메리트는「개발중」에 나타납니다. 특히 (2) 사양변경이나 버그 수정에서 영향범위를 한정시킬 수 있다는 점은 커다란 메리트입니다. 꼭 한번 DI를 사용해, 사양을 변경하는 경험을 해보세요. 그 영향범위의 좁음에 놀라움을 느끼게 될 것입니다. 사양변경 의뢰에 YES라고 답하는 것이 습관이 될지도 모릅니다. 또한, (3) 단위 테스트를 위해 mock object(테스트용 더미 오브젝트)를 교체하는 작업은, 설정 파일을 교체하는 것만으로 완료됩니다.

　これらのメリットは体感してみなければ分からないものですので、これ以上は詳しく解説しませんが、実際にDIを使ってアプリケーションを開発してみると期待以上の効果を感じることができると思います。そこで次回は、Springを使ったサンプルアプリケーションを作りながら「設定を利用から分離する」ことのメリットを体感し、さらにSpringの各種機能やほかのオープンソースツールとの組み合わせ方などを紹介していくことにします。
　이들 메리트는 체감해보지 않으면 알 수 없는 것이기 때문에, 이 이상은 상세히 설명하지 않겠지만, 실제로 DI를 사용해 어플리케이션을 개발해보면 기대이상의 효과를 느낄 수 있다고 생각합니다. 다음 회에서는, Spring을 사용한 샘플 어플리케이션을 작성하면서「설정을 사용으로부터 분리한다」는 메리트를 체감하고, Spring의 각종기능이나 그 밖의 오픈 소스open source 툴과의 조합법 등을 소개해 나가겠습니다.

마치며

　DIは、オブジェクトを構成するために必要なほかのオブジェクトとの関係を外部設定に分離することで、アプリケーションをコンポーネントの集合として組み立てるためのデザインパターンです。そして、DIフレームワークを利用することで容易にアプリケーションのコンポーネント化を促進することができ、コンポーネント化によって開発中や開発後の仕様変更やデバッグにも強いアーキテクチャを構築することができます。
　DI 는, 오브젝트를 구성하기 위해서 필요한 다른 오브젝트와의 관계를 외부설정으로 분리하는 것으로, 어플리케이션을 컴포넌트component 집합으로서 구성하기 위한 디자인 패턴design pattern입니다. 그리고, DI Framework를 사용하는 것으로 손쉽게 어플리케이션의 컴포넌트화를 추진할 수 있고, 컴포넌트화에 의해서 개발 중이나 개발후의 사양변경이나 디버그에도 강한 아키텍처architecture를 구축할 수 있습니다.

筆者プロフィール
필자 프로파일
山本 大（やまもと だい）
야마모토 다이山本大
株式会社クロノスに勤務するITアーキテクト。甲南大学 経営学部 卒業。J2EE、.NETにこだわらずベストソリューションを提供できるマルチプラットフォームアーキテクトを目指す。『XMLマスター教科書 プロフェッショナル』（翔泳社）や雑誌などで執筆活動も行っている。
주식회사 크로노스Kronos에 종사중인 IT 아키텍트Architect. 코-난대학甲南大学 경영학부経営学部 졸업. J2EE, .NET에 국한되지 않는 베스트 솔루션solution을 제공할 수 있는 멀티 플랫폼multi-platform 아키텍트Architect를 지향한다.『XML 마스터 교과서 프로페셔널(XMLマスター教科書 プロフェッショナル)』（쇼에이샤翔泳社）나 잡지 등에 집필활동도 하고 있다.

Spring Framework로 이해하는 DI Back number
제1회 DI: 의존성 주입Dependency Injection이란 무엇인가?
제2회 Spring Framework의 설계 사상과 AOP
제3회 Spring AOP 샘플 어플리케이션으로 이해하는 AOP
최종회 왜 DI 컨테이너container를 사용해야 하는가

원문 출처
@IT Java Solution