오역(誤訳): 방석구

Spring Frameworkで理解するDI（2）
Spring Framework로 이해하는 DI(2)
Springフレームワークの設計思想とAOP
Spring Framework의 설계 사상과 AOP

クロノス
크로노스(Kronos)
야마모토 다이(山本大)
2005/11/23

　前回「DI：依存性の注入とは何か？」では、Springフレームワークの簡単なサンプルを通じて「Dependency Injection（依存性の注入、以下DI）」とは何かを解説しました。しかし前回の内容では、Springフレームワークの中核機能の一部分を説明したにすぎません。Springフレームワークはさまざまな機能を提供するフレームワークです。今回はSpringフレームワークの設計思想と、その思想を特徴付ける機能のいくつかを紹介し、Springフレームワークがどのようなフレームワークなのかを紹介します。
　전회「DI: 의존성 주입Dependency Injection이란 무엇인가?」에 서는, Spring Framework의 간단한 샘플을 통해서 「Dependency Injection(의존성 주입, 이하 DI)」이란 무엇인가를 설명했습니다. 그렇지만 전회 내용은 Spring Framework의 핵심 기능 중 일부분에 지나지 않았습니다. Spring Framework는 다양한 기능을 제공하는 Framework입니다. 금회에서는 Spring Framework의 설계 사상과, 그 사상을 특정 짓는 기능 몇 개를 소개하고, Spring Framework이 어떤 Framework인지 소개합니다.

Spring Framework의 설계 사상

　Springフレームワークの設計思想は、（いまやJavaアーキテクトたちの必読の書といってよい）ロッド・ジョンソン氏の著書『Expert One-on-one J2EE Design and Development（邦題：実践J2EEシステムデザイン）』を読むことで知ることができます。この著書の中でロッド・ジョンソン氏が提案した「IoC（Inversion Of Control）」というデザインパターンが名前を変えて、DIと呼ばれるようになりました。
　Spring Framework의 설계 사상은, (바야흐로 Java Architect들의 필독서라고 해도 좋은) Rod Johnson씨의 저서『Expert One-on-one J2EE Design and Development(일본 제목: 실천 J2EE System Design実践J2EEシステムデザイン)』에도 잘 나타나 있습니다. 이 저서 중에 Rod Johnson씨가 제안한「제어 역행IoC(Inversion Of Control)」라는 design pattern의 이름이 변해서, DI라 불리게 되었습니다.

　そもそもフレームワークとは、特定の領域の問題を解決するための基盤を提供するものです。例えば有名なStrutsならば「画面と画面遷移とビジネスロジックの結び付け（MVC）」を対象領域として扱いますし、以前に連載記事「Hibernateで理解するO／Rマッピング」で紹介したHibernateであれば「リレーショナルデータベースとオブジェクトの結び付け（O／Rマッピング）」を対象領域としています。
　원래 Framework는 특정 영역의 문제를 해결하기 위한 기반을 제공하는 것이었습니다. 예를 들어 유명한 Struts라면「화면과 화면전이 그리고 business logic의 연결(MVC)」을 대상영역으로서 처리하고, 이전의 연재기사「Hibernate로 이해하는 O/R 매핑mapping」 에서 소개한 Hibernate에서라면「relational database와 object의 연결(O/R 매핑mapping)」을 대상영역으로 합니다.

　Springフレームワークも特定の対象領域を扱うフレームワークですが、ほかのフレームワークとは少し違った対象領域を扱っています。Springフレームワークの設計思想と対象領域を知るためには、まずフレームワークという概念について詳しく考える必要があります。
　Spring Framework도 특정 대상영역을 처리하는 Framework이지만, 다른 Framework와는 조금은 다른 대상영역을 처리합니다. Spring Framework의 설계 사상과 대상영역을 알기 위해서는, 우선 Framework라는 개념에 대해서 상세히 생각해볼 필요가 있습니다.

Framework가 제공하는「틀」과「infrastructure」

　フレームワークとは直訳すれば「枠組み」ですが、プログラミングのためのフレームワークには、その名前どおりの「枠組み」という役割以外にも「インフラストラクチャを提供する」という役割があります。フレームワークが担うこれら2つの役割を明確にしていくと、Springフレームワークの対象領域が見えてきます。
　Framework를 직역하면 「틀」이 되지만, 프로그래밍에서의 Framework는 그 이름대로 「틀」이라는 본연의 역할 외에도 「infrastructure를 제공한다」라는 역할이 있습니다. Framework가 맡고 있는 이들 2개의 역할을 명확하게 한다면, Spring Framework의 대상 범위를 쉽게 이해할 수 있습니다.

■ フレームワークが提供する「枠組み」とは
■ Framework가 제공하는「틀」이란

　プログラムはコンピュータの上では「何でもできる魔法の道具」ですが、ある程度大きなプログラムになると、その自由さ故にそれぞれの部分がばらばらな構造で出来上がってしまいます。複数の人数で構築する企業アプリケーションになればなおさらです。当然、こういった問題は開発チームのリーダーによる管理やプログラミング時のルールによって解決することもできるのですが、属人的な管理では大変な労力が掛かってしまいます。そこでフレームワークがもたらす「枠組み」が効力を発揮するのです。フレームワークの流儀にのっとってプログラミングすることで、統一されたアーキテクチャを持ったアプリケーションを作ることができるようになります。これが、フレームワークが持つ「枠組み」という役割です。
　프로그램은 컴퓨터 상에서는 무엇이라도 가능하게 하는 마법의 도구이지만, 어느 정도 규모의 프로그램이 되면, 그 자유로움으로 인해 각 부분이 흩뿌려진 구조로 만들어지게 됩니다. 다수의 인원으로 구축된 기업 어플리케이션이라면 더욱 그렇습니다. 당연히, 이러한 문제는 개발팀 리더에 의한 관리나 프로그래밍 시 룰에 의해서 해결할 수도 있지만, 속인적属人的 관리는 많은 노력을 요합니다. 그런 까닭으로 Framework의 「틀」이 효력을 발휘하는 것입니다. Framework 방식에 따라 프로그래밍 하는 것으로, 통일된 architecture를 가진 어플리케이션을 만들 수 있게 됩니다. 이것이 Framework이 가진「틀」의 역할입니다.

■ フレームワークが提供する「インフラストラクチャ」とは
■ Framework가 제공하는「infrastructure」란

　フレームワークがプログラミングに与えるメリットには、アプリケーションの構造に一貫性を与える「枠組み」という役割以外にも、開発を効率化するための「インフラストラクチャ」という役割があります。
　Framework가 가지는 메리트에는, 어플리케이션 구조에 일관성을 제공하는「틀」이라는 역할 이외에도, 개발을 효율화하기 위한 「infrastructure」라는 역할이 있습니다.

　インフラストラクチャ（インフラ）とは、基盤となる設備や構造のことを指します。例えば社会のインフラストラクチャといえば「電気・ガス・水道・鉄道・道路」などの社会生活の基盤となる設備や構造をいいます。社会にはインフラストラクチャが存在することで、われわれは自分自身の活動目的である「生活」や「仕事」、「遊び」などに専念することができます。
　Infrastructure(인프라)란 기반이 되는 설비나 구조를 가리킵니다. 예를 들어 사회 infrastructure라고 하면 「전기 ・ 가스 ・ 수도 ・ 철도 ・ 도로」등 사회생활의 기반이 되는 설비나 구조를 말합니다. 사회에서 infrastructure가 존재하는 것으로, 우리들은 자기자신의 「생활」이나 「일」, 「여행」등에 전념할 수 있습니다.

　プログラミングフレームワークでも同じことがいえます。つまりフレームワークという「インフラストラクチャ」が存在することでプログラマーは本来の目的であるビジネスロジックの開発に専念することができるのです。
　프로그래밍 Framework에서도 이와 동일하게 말할 수 있습니다. 요컨대 Framework라는 infrastructure가 존재하는 것으로 프로그래머는 본래의 목적인 business logic 개발에 전념할 수 있는 것입니다.

　例えば、Servlet（を含むJ2EE）というフレームワークがなかったらどうなるでしょうか。Webアプリケーションを作るのに、Http用のポートを監視したり、Httpリクエスト情報をプログラミングしやすいように加工したり、Httpへのレスポンスを書き込んだりと、本来実現したい目的以外のプログラミングに手間取ってしまうことになります。
　예를 들면, Servlet을 포함한 J2EE Framework가 없다면 어떻게 될까요? Web 어플리케이션을 만드는데, Http용 포트를 감시하거나, Http request 정보를 프로그래밍해 쉽게 가공하거나, Http로의 response를 기입하려면, 본래 실현하려는 목적 이외의 프로그래밍에 수고를 들이게 됩니다.

프로젝트 고유의 infrastructure 구축을 제공

　ServletやStruts、 Hibernateのようなインフラストラクチャは、多くのプロジェクトで必要となる汎用的な機能を提供するものですが、個別の開発プロジェクトが用意すべきインフラストラクチャも存在します。例えばビジネスロジックがかかわる処理やプロジェクト固有のアーキテクチャに密接に関係する以下のような処理は、インフラストラクチャとして多くのプロジェクトで必要となる処理でありながら、汎用のフレームワークを組み立てにくい処理です。
　Servlet나 Struts, Hibernate 같은 infrastructure는 많은 프로젝트에서 필요한 범용적인 기능을 제공하지만, 개별적인 개발 프로젝트가 준비해야 할 infrastructure도 존재합니다. 예를 들어 business logic이 관여하는 처리나 프로젝트 고유의 architecture에 밀접하게 관여하는 아래와 같은 처리는 infrastructure로서 많은 프로젝트에서 필요한 처리이지만, 범용 Framework로 구성하기는 어려운 처리입니다.

• 重要なビジネスロジックでの処理結果を追跡するための詳細なログを書き出す
  중요한 business logic 처리결과를 추적하기 위한 상세한 로그를 작성한다.
• 特定のタイミング、特定のルールで、オブジェクトをキャッシュする
  특정 타이밍, 특정 룰, 오브젝트를 cache한다.
• 特定のユーザー以外は、オブジェクトのメソッドを呼び出せないようにする
  특정 유저 이외에는 오브젝트 method를 호출할 수 없도록 한다.

　こういった問題を解決するために、J2EEを使ったシステム開発では「J2EE」や「オープンソースのフレームワーク」をベースに、それぞれの開発プロジェクトで必要なインフラストラクチャを構築して開発を効率化するといったことが、しばしば行われます。開発プロジェクト固有のインフラストラクチャがあればアーキテクチャの管理が一元化でき、アプリケーションの強化や改修をより柔軟に行うことができます。
　이러한 문제를 해결하기 위해, J2EE를 사용한 시스템 개발은「J2EE」 나「open source Framework」를 베이스로, 각각의 개발 프로젝트에 필요한 infrastructure를 구축해 개발을 효율화하는 일이 종종 있습니다. 개발 프로젝트 고유의 infrastructure가 존재한다면 architecture 관리를 일원화할 수 있어, 어플리케이션의 강화나 수정을 보다 유연하게 할 수 있습니다.

　Springフレームワークが対象とする領域は、このようなプロジェクト固有の「インフラストラクチャ」を構築することだといえます。
　Spring Framework가 대상으로 하는 영역은 이와 같은 프로젝트 고유의「infrastructure」를 구축하는 것이라고 말할 수 있습니다.

　Springフレームワークは、柔軟なインフラストラクチャを構築できることを目指して作られています。以下の章ではSpringフレームワークが、柔軟なインフラストラクチャのためにどういった機能を提供しているかということを説明していきます。
　Spring Framework는 유연한 infrastructure 구축을 지향해서 만들어졌습니다. 이하 장에서는 Spring Framework가 유연한 infrastructure를 위해서 어떠한 기능을 제공하고 있는지를 설명하겠습니다.

「ポイント」
「포인트」
Springフレームワークが対象とする領域は、プロジェクト固有の「インフラストラクチャ」を構築することです。
Spring Framework가 대상으로 하는 영역은 프로젝트 고유의「infrastructure」를 구축하는 것이다.

애스펙트aspect 지향 프로그래밍(AOP)은 기능을 삽입하는 방식?

　もしも読者がAOPの初心者でAOPの概念についてまだ理解できていないならば、（最初のうちは）以下のように「割り切って」理解してしまうことをおススメします。
　만약 독자가 ① AOP 초심자로 AOP의 개념에 대해서 미처 이해하지 못하고 있다면, (얼마 동안은) 다음과 같이 대략적으로 이해할 것을 추천합니다.

주(註): ① AOP(Aspect Oriented Programming). AOP는 로깅과 같은 공통 기능은 여러 클래스에 퍼져 있기 쉽다는 단점에 착안, 이와 같은 횡단적 관심사Cross-Cutting Concerns를 한 곳에서 처리할 수 있도록 해준다. 유명한 Java용 AOP 툴로는 AspectJ와 Hibernate AOP가 있다. 둘 모두 이클립스 용 플러그인이 있기 때문에 편리하게 사용할 수 있다. (인사이트 – 앤드류 헌트, 데이비드 토머스의 『실용주의 프로그래머The Pragmatic Programmer』 8. 직교성에서 발췌)

「ポイント」
「포인트」
AOPとは作り上げたオブジェクト群に対して「機能を挿入する（織り込む）」ことができるアーキテクチャである。
AOP라는 것은 이미 완성한 오브젝트 군에「기능을 삽입」 할 수 있는 아키텍처architecture이다.

　つまり、作成したオブジェクト群に対して「アトヅケ」で機能や処理を挿入することができる仕組みだと考えてください。
　요컨대, 작성한 오브젝트 군에 추가적으로 기능이나 처리를 삽입할 수 있는 방식이라고 생각해주세요.

　一般的には、AOPは「横断的関心事の分離（Separation Of Cross-Cutting Concerns）」を行うものだといわれています。この「関心事」とは大ざっぱにいうと「ひとまとまりの処理」であり、また「横断的」とは「複数のモジュールに散在する状態」を指します。つまり「横断的関心事の分離」という言葉は、本来1カ所で定義されるべき「ひとまとまりの処理」が複数のモジュールにまたがって存在している状態であるため、それらの処理を抜き出して別途定義するべきであることを表しています。
　일반적으로 AOP는「② 횡단적 관심사의 분리(Separation Of Cross-Cutting Concerns)」를 실행하는 것으로 알려져 있습니다. 이 「관심사」라는 것을 대략적으로 말하면「공통 기능의 처리」이고, 또한 「횡단적」이라는 것은 복수의 모듈에 산재해있는 상태를 가리킵니다. 즉, 「횡 단적 관심사의 분리(Separation Of Cross-Cutting Concerns)」라는 것은 본래 한 개소에서 정의 되어야 할 공통 기능의 처리가 – OOP의 특징을 최대한 끌어 올린다 해도 – 복수의 모듈에 걸쳐서 존재하고 있기 때문에, 그들의 처리를 추출해서 별도로 정의해야 한다는 것입니다.

주(註): ② 왠지 의문이 다발적으로 발생하는 횡단적 관심사의 분리(Separation Of Cross-Cutting Concerns)에 대한 친절한 설명은「객체지향을 넘어 관점지향으로 AOP」중 “AOP의 필요성” 단락을 참조하세요.

　しかし、実際にこれからAOPを使ってプログラミングをしようとする開発者にとっては、この抽象的な言葉から「どう使って」「どのようなメリットを生み出すことができるのか」をイメージすることは難しいでしょう。
　그러나, 실제로 지금부터 AOP를 사용해서 프로그래밍 하려는 개발자에게는, 이러한 추상적인 말로부터「어떻게 사용하는지」「어떠한 메리트를 창출할 것인가」를 이미지화 하기는 어려울 것입니다.

　「横断的関心事の分離」という言葉が理解しづらい理由は、「プログラミングという視点」と「分析という視点」の違いにあるのではないでしょうか。「横断的関心事の分離」という言葉は、「分析的」な視点で語られた言葉です。「分析」という行為では、すでに存在するものを「発見、定義し、分類する」という作業を行います。それに対して、「プログラミング」という行為は「存在しないものを作り上げる」作業を行います。AOPを初めて扱う人がいきなり分析的な観点でAOPに取り組むことはまれであり、たいていはプログラミングのフレームワークとしてAOPを扱います。そのためAOPの「横断的関心事の分離」という言葉を理解しづらく感じてしまうのです。
　「횡단적 관심사의 분리(Separation Of Cross-Cutting Concerns)」라는 말을 이해하기 어려운 까닭은「프로그래밍 시점」과 「분석 시점」의 차이에 있는 것은 아닐까요? 「횡단적 관심사의 분리」라는 말은 분석적 시점에서 이야기하는 단어입니다. 「분석」은 이미 존재하는 것을「발견하고 정의해서 분류」하는 작업을 말합니다. 그에 반해「프로그래밍」은 「존재하지 않는 것을 만들어내는」작업을 수행합니다. AOP를 처음 접하는 사람이 돌연 분석적인 관점에서 AOP에 몰두하는 것은 드문 일이고, 대개는 프로그래밍 Framework로서 AOP를 접합니다. 그렇기 때문에 AOP의「횡단적 관심사의 분리」라는 말을 이해하기가 어렵게 느껴지는 것입니다.

　しかし、「アスペクト指向」という概念は、プログラミングのみならず、アスペクト指向「分析」やアスペクト指向「設計」なども含んだ幅広い概念です。そのため、「横断的関心事の分離」といった抽象的な言葉を使わなくては、アスペクト指向の幅広い概念を（正確に）いい表せないのです。
　그러나, 「애스펙트aspect 지향」이란 개념은 프로그래밍뿐만 아니라, 애스펙트aspect 지향 분석이나 애스펙트aspect 지향 설계 등도 포함된 광범위한 개념입니다. 이러한 이유로「횡단적 관심사의 분리」라는 추상적인 단어를 사용하지 않고서는 애스펙트aspect 지향의 광범위한 개념을 정확하게 표현할 수 없는 것입니다.

　AOPについて、さらに詳細が知りたいという読者は、＠ITの連載記事「アスペクト指向のバリエーション解説」を参照してください。
　AOP에 대해서는 보다 상세히 알고 싶은 독자는 @IT연재기사「애스펙트aspect 지향 Variation 해설」을 참조해주세요.

　次回は、Springを使ったAOPのサンプルを作成して具体的にAOPを理解していきましょう。
　다음 회에서는 Spring을 사용한 AOP 샘플을 작성해서 구체적으로 AOP를 이해해봅시다.

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

원문 출처
@IT Java Solution