米持幸寿のJava Issue
フレームワークはシステム開発の必需品?
米持幸寿
日本アイ・ビー・エム
2002/2/26
フレームワークというと、さまざまな見方があると思う。現代のソフトウェア開発においてフレームワークは重要だ。今回はフレームワークについて考えよう。
◆何をフレームワークと呼ぶか◆
Javaはオブジェクト指向言語なので、APIなどを作るときにも単なるメソッドのセットではないことが多い。オブジェクト指向により、設計の良いAPIは以下のような特徴を持っている。
- 抽象化が進み、ライブラリが小さい
- 拡張性が高い
- アクセスしなければならないメソッド数が少ない
- 使い方が分かりやすい
まぁ、ほかにもあるだろうが、筆者はそう考えている(パフォーマンスが良いとかバグが少ない、というのはAPIの特徴ではなく、ソフトウェアの根本の問題なので、ここでは触れない)。
さて、このようなオブジェクト指向の設計が進むと、機能、役割別にライブラリが作られ、アプリケーションの中にもレイヤが出てくる。こういったレイヤ化がフレームワークの第一歩といえるのではないだろうか。
アプリケーション
|
フレームワーク
|
ライブラリ
|
ミドルウェア
|
オペレーティングシステム
|
フレームワークといったとき、その単位をどう考えるのかは人それぞれ違うようである。プログラミングモデルをフレームワークと呼ぶこともある。例えば、Swingをフレームワークと呼ぶ人もいるだろう。JavaBeansはどうだろうか。プログラミングモデルだけでなく、いくつかのツールライブラリを準備して、ある程度の使い方を決めているのが特徴だ。
もう少し大きなものもフレームワークと呼ばれることがある。J2EEをフレームワークと呼ぶことがある。これはかなり大きなフレームワークである。J2EEのようなフレームワークに準拠したサーバを、各ベンダが提供し、それに準拠したアプリケーションを準備することで、高い移植性が実現でき、アプリケーションの再利用が進む。
さらに、こういったフレームワークに準拠したアプリケーションを開発していても、もっと開発の生産性を上げたいと考える。そこで、よりアプリケーション寄りのフレームワークというものが登場する。アプリケーション・フレームワークは、業務パッケージを抽象化したものであったり、業務アプリケーションを作る場合のベースクラスなどを提供しているものであったりする。いくつかのソフトウェアベンダから、そういったフレームワークが提供されている。ミドルウェア上にフレームワークが構築されており、そのミドルウェアの開発製品で自動生成されるコードが、そのフレームワークで構築されている例は少なくない。フレームワークを利用することで、デザインパターンを取り入れやすくなるし、準備されたツール類で開発をある程度自動化することも可能だ。
◆フレームワークを利用するか検討しよう◆
いくつかのフレームワークを利用すると、開発生産性が向上し、出来合いのパッケージに含まれるライブラリを利用することで、性能が良く信頼性の高いアプリケーションが開発できる可能性がある。しかし、良いことばかりではない。
フレームワークを利用したアプリケーションは、通常、そのフレームワークに依存する。フレームワークは標準規約となっているものと、ベンダ独自のものがあるが、多くの場合、ミドルウェアなどがそれをサポートしていない限り利用できない。
フレームワークのうちのいくつかは長生きであるが、いくつかは消えていく運命にある。もし、アプリケーションがあるフレームワークに依存したものであり、ベンダがそのフレームワークを捨てたとき、そのアプリケーション自体が危機に遭遇することになる。これは望ましくないことだ。
ではフレームワークを採用するべきではないのだろうか? それはノーだ。フレームワークは、むしろ積極的に採用すべきだろう。重要なのは「単一のフレームワークに依存しない」ことだと筆者は考えている。アプリケーションやエンジニアのスキルを単一のフレームワークに統一させるのはコストを下げる面では有効だが、大きな危険をはらんでいることに気付いてほしい。
フレームワークが有効でなくなったとき、システムやエンジニアのスキルをどう生かせるか、最初から考えておくべきである。
◆どう使ったら効果的か?◆
冒頭で触れたように、フレームワークは「仕様」「ライブラリ」「ツール」などで構成されることが多い。これらを使ってアプリケーションを構築する際にはどうしたら効果的だろうか。
1.将来性を調査する
これは一番重要なことである。フレームワークは、1年でも長く生きながらえてほしいものだ。
2.依存しない設計を心掛ける
先に触れたように、いくつかのフレームワークは短命であったりする。その場合、アプリケーションを生き残らせられるかはデザインにかかっている。アプリケーションのコア部分、すなわちビジネスロジックを、うまくフレームワークから切り離すことを考えよう。多くの場合、ビジネスロジックの大部分はデータの操作と計算と判断だ。そういったことをフレームワークから切り離しておくことでビジネスロジックの寿命は大幅に長くできる。ただし、分離度を高めれば高めるほど、パフォーマンスが落ちるので、良いバランスの部分を探すのも重要だ(これについてはややこしいので、また別の機会に触れたいと思う)。
3.仕様をきちんと理解する
仕様をよく理解せずにフレームワークを利用すると失敗しやすい。そのフレームワークが想定している使い方とは違う使い方をしてしまうと、正しい性能も発揮できないし、開発効率も上がらないだろう。GUIを作るためのフレームワーク上でサーバ機能を実装すると、GUIのリソース不足などでサーバプログラムが不安定になることもある。それは間違った使い方だ。
4.ツールをうまく利用する
多くのフレームワークが、ライブラリと一緒にツールを提供している。ライブラリを単にJavaコードから呼び出すだけでなく、ツールを利用することで開発コストを大幅に削減できる。このとき、作ったコードのメンテナンス性、移植性、バージョンアップ時の移行の可否などは確認したい。
5.教育を行き届かせる
フレームワークは、「何らかの使い方」を想定しているものが多く、単なるプログラミングテクニックだけでは活用しきれない側面を持っている。フレームワークを採用するなら、きちんとした教育を受け、その使い方をマスターした人間がリーダーとして活動するのは非常に重要である。
◆プログラマーはどうするべきか◆
Javaプログラマーは、フレームワークを利用して開発することが日常茶飯事だろう。その場合、どう対処したらいいだろうか。
まず、フレームワークを利用する際、ツールの使い方やメソッドの呼び出し方を覚えないと開発作業ができない。このとき、表面的な使い方(どこをクリックするとか、何というメソッドを呼ぶとか)ということよりも、中の構造がどうなっていて、何が行われているかを理解したり、想像したりしながら使ってみよう。そうすることで、別のフレームワークを使ったときに受け入れやすくなるし、フレームワークのデザインを理解することによって、オブジェクト指向やコンポーネント指向のデザイン能力がますますアップする。フレームワークが独自に設計できるようになったとき、あなたはテクノロジ・アーキテクトとして世に知られることになるはずだ。
Index |
第1回
ソフトウェアの部品化は現実になる?(2000/12/19)
|
プロフィール |
米持幸寿 1987年、日本アイ・ビー・エム入社。 IBMメインフレームOSであるVSE、およびVM関連ソフトウェアプロダクト の保守、 システム無人化ソフトウェア開発を手がける。現在はJava、XML、EJBに関わるプロモーション活動を行っている。 [筆者執筆記事一覧] ・JavaとXMLはなぜ仲良し? ・Java Servlet徹底解説(JSPとの連携) ・Java Servlet徹底解説(EJBとの連携) |
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 (2017/5/9)
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か (2017/4/27)
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd+Elasticsearch+Kibanaで作るログ基盤の概要と構築方法 (2017/4/6)
ログ基盤を実現するFluentd+Elasticsearch+Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 (2017/4/3)
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
|
|