Comments
Description
Transcript
NetCOBOL for .NET 基本編
第2章 プログラムを作る前に NetCOBOL for .NETのプログラムの話に入る前に、オブジェクト指 向について説明しておきましょう。オブジェクト指向といっても、考え 方を細かく説明するつもりはありません。また、.NETのプログラムを 作るのに、細かな定義まで理解する必要はありません。しかし、クラス の考え方は知っておく必要があります。そして、クラスを使用すること のメリットも押さえておきましょう。 クラスのメリットとして、「データの隠蔽化」とか「再利用性の向 上」ということがいわれます。手続き型COBOLプログラマーである皆 さんがそのような説明を聞くと、「サブルーチンではなぜだめなのか な？どう違うのかな？」という疑問が浮かんできませんか。なぜサブル ーチンが考え出されたのか、サブルーチンにできないことは何なのか、 クラスの理解を助けるために、サブルーチンとクラスを比較しながら見 ていきましょう。 9 Copyright 2006-2009 FUJITSU LIMITED 2.1 サブルーチンとクラス 2.1 サブルーチンとクラス プログラミング言語の歴史の中で、サブルーチンという考え方は機械 語の時代から存在しました。類似した処理があるのなら、それを一箇所 にまとめてモジュール化し、必要であれば、そのモジュールを呼び出し て使用するというものです。これにより、同じコーディングを何回も書 くような、プログラム作成負荷を軽減させようという狙いがありました。 最初はプログラム作成負荷軽減という目的だったサブルーチンが、プ ログラムのわかりやすさという観点で語られ始めたのは、エズガー・ダ イクストラ氏の提唱した構造化プログラミングからになります。構造化 プログラミングとは、プログラムを「モジュール」という単位に分割し、 それらを個々のサブルーチンとして独立させ、以下の基本となる３つの アルゴリズム (連続、分岐、反復) により、サブルーチンや命令を組み 合わせてプログラムを作成しようというものです (図2-1-1) 。構造化プ ログラミングにより、プログラムのわかりやすさが大きく向上したとい われます。 図2-1-1 構造化プログラミングにより、プログラムのわかりやすさは向上しま したが、保守という観点で考えるとまだ十分ではありません。１つのサ ブルーチンを修正することで、そのサブルーチンを使用するプログラム にまで影響が及んでは困ってしまいます。保守性を高めるためには、サ ブルーチンの修正が他のプログラムに影響を及ぼさないように、サブル ーチンの独立性が高くなければなりません。そのためには、モジュール 結合度を弱くすることが重要になります。そこで、サブルーチン作成時 に次のような点に留意して、結合度を弱くして作成する必要があります。 10 Copyright 2006-2009 FUJITSU LIMITED 2.1 サブルーチンとクラス ・ 他のプログラムとの共通領域をできるだけ利用しない ・ データ量は必要最小限度にとどめる ・ １つのモジュールは、固有の１つの機能を持つ 作業負荷軽減 作業負荷軽減 作業負荷軽減 わかりやすさの向上 モジュール化 わかりやすさの向上 保守性の向上 構造化プログラミング 独立性を高める サブルーチン化の目的の変遷 図2-1-2 このようなサブルーチンを作成することにより、作業負荷軽減やわか りやすさの向上だけでなく、保守性の向上も望めるようになります(図 2-1-2)。そして、その発展系がクラスを使用したオブジェクト指向プロ グラミングです。これにより、さらなる「保守性の向上」や 「データ の隠蔽化」、「再利用性の向上」などが図られたといわれます。 しかし、手続き型COBOLプログラマーにとっては、今ひとつピンと こないところがあります。サブルーチンの独立性を高めていくと、サブ ルーチンで「データの隠蔽化」は実現できそうな気がしませんか。その データへのアクセスは、そのサブルーチンしかできないようにして、そ のデータに関する処理ロジックをその中に閉じた形で持たせてやればよ いわけです。「保守性」に関しても、そのデータに関する処理はこのサ ブルーチンに閉じているわけですから、他のプログラムへ影響を及ぼさ ず、問題ないように思えます。もちろん再利用性も向上しそうです。 「じゃあ、クラスのメリットって何？」と、改めて問いたくなってしま います。しかし、クラスには、サブルーチンでは持ち得ない大きなメリ ットがあるのです。 11 Copyright 2006-2009 FUJITSU LIMITED 2.2 クラスのメリット 2.2 クラスのメリット 最初にお話ししたように、NetCOBOL for .NETのプログラムを作る のに細かい定義を全て理解する必要はありません。ただし、クラスを利 用することにより、サブルーチンでは実現できないメリットを享受でき、 それを利用してプログラミングする、ということを理解しておいてくだ さい。では、クラスにできてサブルーチンにできないこと、そしてクラ スのメリットとは何でしょう。これについては、考え方など本質的なと ころでの比較が必要なのでしょうが、今回は3点だけあげておきます。 ( 1 ) イ ンスタンスの生成(クラスのインスタンス化) オ ブ ジ ェ ク ト 指 向 は 「 モ ノ 」 に 例 え ら れ ま す 。 よ く 「 ”人 ” が ク ラ ス で”山田さん”がインスタンス」という説明がありますね。クラスが種類 でインスタンスが実体というわけです。イメージとしては正しいのです が、これがプログラムにどのように関係してくるのか、なかなか掴めま せん。 コンピュータの世界では、クラスとは、手続きを含んだ定義情報と考 えてください。クラスの中に、データや、クラスの持つ機能(手続き)を 定義します。オブジェクト指向プログラミングでは、クラスに対して処 理を依頼することで処理を実行していくのですが、定義情報だけでは処 理を実行することができません。クラスの持つ機能を使えるようにする には、メモリ上にクラスの実体を作ってやらなければなりません。メモ リ上に定義情報をロードして、実行可能状態としてやるわけです。これ を「インスタンス化」といいます (図2-2-1) 。 メモリ クラス ロード インスタンス化 されたクラス インスタンス化 定義 実体 実行できない 実行可能 図2-2-1 12 Copyright 2006-2009 FUJITSU LIMITED 2.2 クラスのメリット インスタンス化したクラスに対して処理を依頼することで、初めて機 能の実行が可能になります。サブルーチンでもメモリ上にロードすると いう意味では同じですが、クラスと大きな違いがあります。「オブジェ クト指向は”モノ”に例えられます。」と書きましたが、”モノ”はいくつ も作ることができます。つまり、１つのクラスからメモリ上に実体をい くつでも作ることができるのです。サブルーチンではこれは不可能です。 具体的なイメージで説明しましょう。 商品マスタファイル読み込み処理を考えてみます。まずサブルーチン で考えてみましょう。このような処理のサブルーチンは、次のように作 成 し ま す (図 2 - 2 - 2 ) 。 商品マスタファイル読み込みサブルーチン * 商品マスタ定義 * PROCEDURE DIVISION. OPEN 商品マスタファイル. メインプログラム ・ ・ CALL 商品マスタファイル 読み込みサブルーチン. READ 商品マスタレコード. CLOSE 商品マスタファイル. ・ ・ ・ 図2-2-2 簡単なプログラムですね。では、システムの運用上、商品マスタが2 個必要になったとしたらどうしますか。サブルーチンを次のように修正 す る は ず で す ( 図 2 - 2 -3 ) 。 13 Copyright 2006-2009 FUJITSU LIMITED 2.2 クラスのメリット 処理対象が増加するとプログラムの修正が必要 商品マスタファイル読み込みサブルーチン * 商品マスタ1の定義 商品マスタ2の定義 * PROCEDURE DIVISION. OPEN 商品マスタファイル1. OPEN 商品マスタファイル2. メインプログラム ・ ・ CALL 商品マスタファイル 読み込みサブルーチン. ・ ・ ・ READ 商品マスタレコード1. READ 商品マスタレコード2. CLOSE 商品マスタファイル1. CLOSE 商品マスタファイル2. 図2-2-3 では、3個だったら、4個だったら・・・。ファイルを増やすごとにプ ログラムの修正が発生します。では、クラスだったらどうなるでしょう。 商品マスタ領域 OPEN処理 READ処理 メモリ 実行可能商品マスタ１ 読み込みクラス 実行可能商品マスタ2 読み込みクラス CLOSE処理 実行可能商品マスタ3 読み込みクラス クラス定義は ひとつ 複数生成することでクラスの修正不要 読み込みクラス イ ンスタ ンス化 商品マスタ クラスの実体は、複数作成可能 図2-2-4 14 Copyright 2006-2009 FUJITSU LIMITED 2.2 クラスのメリット クラスでは、図2-2-4のように実行可能なクラスの実体を複数作るこ とによって、前述の条件に対応できるのです。クラス定義自体は、複数 のファイルを意識する必要はありません。「商品マスタ1」などのファ イル名を与えてメモリ上に複数の実体を作ってやれば、複数マスタの読 み込みが可能というわけです。クラスの実体は、メモリや処理能力が許 す限りいくつも作ることができます。 つまり、サブルーチンで複数のファイルを対象とする処理を作成する 場合には、何らかの形でコーディングに反映しなければならないのに対 し、クラスは、そのような意識をせずに作成し、使うことができるので す。この「いくつも作ることができる」という特徴は、再利用性の向上 に大きく寄与します。 (2) 継承 NetCOBOL for .NETのプログラミングのために「継承」の概念も覚 えておいてください。これも手続き型のCOBOLでは、実現できない機 能の１つです。サブルーチンと比較して説明していきましょう。従業員 の給与計算のサブルーチンを例として考えます。従業員には、一般従業 員、管理職、役員の区分があるとします。給与の計算は、一般従業員が 基 本 給 + 残 業 代 、 管 理 職 が 基 本 給 + 管 理 職 手 当 て 、 役 員 は 基 本 給 +役 員 報 酬の計算で行われます。算出区分を設定して、１本のサブルーチンに全 ての機能を持たせるという方法もありますが、ここではサブルーチンの 独立性を高めるために、3本のサブルーチンを作成したとします。 一般従業員給与計算 管理職給与計算 役員給与計算 サブルーチン サブルーチン サブルーチン * * 基本給算出処理 * * 共通処理 * 基本給算出処理 基本給算出処理 * * * * 残業代算出処理 管理職手当て算出処理 役員報酬算出処理 * * * * * * 基本給＋残業代算出処理 基本給＋管理職手当て 算出処理 基本給＋役員報酬 算出処理 独自処理 独自処理 独自処理 図2-2-5 15 Copyright 2006-2009 FUJITSU LIMITED 2.2 クラスのメリット 図2-2-5のように、共通である基本給算出処理が3本とも必要となり、 コーディングの重複が発生しています。この部分に修正が発生すると、 全てのサブルーチンに影響が及び、保守が大変です。これが、クラスの 継承を利用すると次のようになります。 従業員クラスに共通部ロジックである基本給算出ルーチンを持たせま す。そして、この従業員クラスを親クラスとして、その子クラスを一般 従業員クラス、管理職クラス、役員クラスと３つのクラスを作成すると、 親クラスの基本給算出ルーチンをコーディングしなくても、全ての子ク ラスに引き継ぐことが可能になります。この機能を「継承」といいます。 結果的に子クラスの方では独自部分のコーディングだけで済んでしまい ます。このようなコーディングを差分コーディングと呼びます(図2-2-6)。 まさに親クラスが持つ機能と子クラスが必要な機能との差分のみのコー ディングで済んでしまうわけです。保守も楽になりますね。継承とは、 「親クラスの性質を子クラスが全て受け継ぐ」ことなのです。本書で扱 うコーディングで差分コーディングを行うわけではありませんが、クラ スを使用するうえで必要な知識ですので覚えておいてください。 親クラス 従業員クラス 一般従業員オブジェクト 基本給算出 基本給算出 一般従業員クラス 残業代算出 管理職手当て算出 差分コーディング 子クラス 管理職クラス インスタンス化 継承 残業代算出 管理職オブジェクト 基本給算出 管理職手当て算出 役員オブジェクト 基本給算出 役員クラス 役員報酬算出 役員報酬算出 図2-2-6 ( 3 ) 標 準で提供 サブルーチンでは、自分のプロジェクトや会社で作ったプログラムの 再利用は可能ですね。では、他社のサブルーチンの再利用は可能でしょ うか。世の中で広く利用されているサブルーチンライブラリといえるも のがあるでしょうか。再利用性が向上したと言っても、組織内での再利 16 Copyright 2006-2009 FUJITSU LIMITED 2.2 クラスのメリット 用に閉じた場合が多いようです。これに対してクラスはクラスライブラ リとして、多くのクラスが言語などに標準で添付される形で提供されま す。NetCOBOL for .NETでも、Javaなどと同様に多くのクラスが提供 されています。サブルーチンはその機能を使用することしかできません が、クラスではそのクラスを使用するだけでなく、「継承」を利用して 機能を引き継いだり、追加・変更したりして使用することも可能です。 提供されているクラスライブラリを使用することにより、新たにプログ ラムを作ることなく、多様な機能を実現できることになるのです。 17 Copyright 2006-2009 FUJITSU LIMITED ◇MEMO◇ 18 Copyright 2006-2009 FUJITSU LIMITED