- - PR -
バッチをオブジェクト指向で設計
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-02-26 10:55
こんにちは。
私は今、Javaでバッチ処理 （ファイルを入出力するJavaアプリケーションという意味で）を書いています。 せっかくなのでオブジェクト指向を最大限に利用しようと バッチ処理を抽象化して ・コントローラー：各クラスを生成し、入力→ロジック→出力の順に呼び出す。 ・入力 ：ファイルを読み込みデータを生成しコントローラーへ戻す ・ロジック ：コントローラーから渡されたデータをもとに何らかの処理をして結果を コントローラーへ戻す ・出力 ：コントローラーから渡されたデータをもとにファイルへ書き込む ・データ ：インターフェースデータの型を規定 のような抽象クラスに分割しました。 責務が分かれているので実装するのは楽なのですが なんだかまどるっこしい感じがします。 そのまま手続き型的に書いたほうがやりたいことがすぐできるのでは？と 思ったりもします。 バッチをオブジェクト指向で設計することについて みなさんはどんな意見をお持ちなのでしょうか？ | ||||||||||||
|
投稿日時: 2004-02-26 11:31
バッチ処理であっても、オブジェクト指向を使うことに何の問題も無いと思います。 最初はちょっとまだるっこしい感じがあるかも知れません。 なので、最初だけで終わってしまう、使い捨てのプログラムでしたら無理にオブジェクト指向でやろうとするのは無駄な手間かなとは思います。 ただ、「(ロジック部分が違うだけの)似たようなバッチを今後も作るであろう」ですとか、「今はファイルのみの入出力だが、将来的にはネットワーク経由になるかも知れない」といった場合には、今回まだるっこしい思いをしただけの(もしくはそれ以上の)恩恵があるのではないかと思います。 抽象化をきっちり行えば行っただけの恩恵がある「かも」知れませんが、あくまで潜在的な要素ですので、最終的には自分のバランス感覚と相談して「適当なレベル」までで止めておく方が無難かと思います。 | ||||||||||||
|
投稿日時: 2004-02-26 11:52
"バランス感覚"って大事ですよね。 そういえば、ラクダ本にこんな一節がありました。
耳が痛いですなぁ。 ついでにもう一つラクダ本から。僕の好きな言葉を。
至言。 [ メッセージ編集済み 編集者: サ 編集日時 2004-02-26 11:56 ] | ||||||||||||
|
投稿日時: 2004-02-26 12:47
良いんじゃないでしょうか。 特に、ファイル入力、処理、ファイル出力という流れの場合、入出力するファイルの 形式が複数あるだけでこのようなデザインの利点が活かせると思いますよ。 確かに、使い捨てのプログラムでまでオブジェクト指向でデザインするのはやり過ぎ (というかコストと結果の兼ね合いから無駄)であると感じますが、部分的にでも 再利用の可能性があるならば有効だと思います。 あと、必要であればバッチだろうと積極的にオブジェクト指向でデザインするという 姿勢を貫けば、自然とデザインセンスが向上するので良いのではないでしょうか。 あまりバッチだとかWebだとかそういったことに捉われず、対コストでトレードオフを 考えた時にオブジェクト指向デザインが有効かどうかを考慮した方が良いのではないか と思います。 | ||||||||||||
|
投稿日時: 2004-02-26 13:13
私は、基幹業務アプリのＳＥで運用サポートまでしています。
バッチ処理を多用している人間の発言として受けとめて下さい。 個人で、手続言語のバッチ処理テンプレートを持っていますが、 現在、オブジェクト指向（正確に言うとオブ言語）で一番作成したい箇所です。 このテンプレートは 「入力部」、「処理部」、「出力部」、「バックアップ部」、「エラー処理部」の ５つの構成で成り立っており、中間ワークＤＢで各構成の情報連携をしています。 例えば、 外部インタフェース入力は、 「入力部」、「処理部」、「バックアップ部」、「エラー処理部」の流れ 外部インタフェース出力は、 「処理部」、「出力部」、「バックアップ部」、（偶に）「エラー処理部」の流れ 更新処理は、 「処理部」、「エラー処理部」の流れ としています そして別途、上位のテンプレートが存在し 「送信部」、「受信部」、「ファイル存在による自動稼動（完全受信を検知）」、 「ジョブログ記述部」 を実装しています。テンプレートを分けているのは、運用監視ツールの存在や ファイル転送ツールに依存する為です。 また、バッチ処理の機能要件として 「バックアップ」、「障害処理」、「エラーログ」、「実行ログ」、 「再実行機能」、「エラー通知」 は全て基本機能として用意していますし、大半は基本機能のままで承認されます。 手続言語ですが、ブロック単位で構成していますので、オブジェクト指向チックに なっています。ただ、チックなのです．． 本当に、これがオブジェクト指向言語で作れたらな、、、 
特にバッチ処理（外部インタフェースは特に）は、 「業務要件」の側面により安易に見受けられる傾向が強く、 「機能要件」を軽視しがちで、運用で多々問題が発生する場所ですので変更（改良）が 容易に出来る構成だと、運用も面倒みている私としては、嬉しいです！ 
| ||||||||||||
|
投稿日時: 2004-02-26 13:33
そうでしょうね、きっと。 ただ、今回の題では単に「バッチ」という表現しかされていないので、私には判断でき ません。（単にオブジェクト指向で作成しちゃいけないか？と言われると、「いいよ」 という回答なんですがね。） また、バッチと言っても、 ・処理に時間がかかるから夜間にというような、業務・機能豊富なバッチ ・日次、月次等の区切りでシステム的な切り替えを行う為のバッチ ・バックアップ等保守がらみのバッチ ・ファイルの入出力・集配信等、他システムとの連携のバッチ 等、機能や目的がいろいろありまして、複雑な処理があるなら良いのですが、 個人的言うと、バックアップやDB更新、ファイルの入出力等であれば、何も オブジェクト指向というより、JAVAで書かなくても．．．と思いますけどね。 （すぐに簡単な方に逃げたがる私なので．．．） | ||||||||||||
|
投稿日時: 2004-02-26 14:11
unibon です。こんにちわ。
これらを拝見して思うのは、具体的なビジネスロジック・ビジネスルールの記述がなく、そのためアプリケーションの設計というよりも、アプリケーションのフレームワークの設計になっているのではないでしょうか。そして、バッチ主体のフレームワークって、結局はファイルを読んで加工して吐き出すだけなので、その存在意義が薄いように感じます。 | ||||||||||||
|
投稿日時: 2004-02-26 15:40
みなさんコメントありがとうございます。
バッチをオブジェクト指向でつくるのは多態性を利用して変更に耐えうるように したい場合は意味があるけれど、使い捨ての場合や単純な機能ならあまり意味がない ということですね。 unibon さんからご指摘あったように問題提起は実はバッチのアプリケーションの設計という よりバッチのフレームワークの可否についてでした。 私は３年ほどCOBOLで金融系システムを開発していましたが １年程前からJava系の仕事に変わりオブジェクト指向を学びました。 学んだあと、今までCOBOLで作っていたシステムをJava+オブジェクト指向で 作れるだろうかと考えるようになりました。 そんなところにバッチフレームワークの話に携わるようになり バッチ処理をオブジェクト指向でフレームワーク化できるかに興味があるのです。 Web処理はstrutsのようなフレームワークを使うことによって 開発者は必要な部分だけ実装するだけで簡単に(？)システムを作成できる。 それと同じようなことがバッチ処理に対してできるのではないかと思っています。 意味があるかどうかはその機能の豊富さによるかもしれません。 ・トランザクション制御 ・入力→ロジック→出力の呼び出し ・ファイルレコードとオブジェクトの相互変換 フレームワークとしてこんな機能があると思います。 ほかにどんな機能があればフレームワークの存在意義が出てくると思いますか？ [ メッセージ編集済み 編集者: キラ 編集日時 2004-02-26 15:45 ] [ メッセージ編集済み 編集者: キラ 編集日時 2004-02-27 11:46 ] | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。