COBOLの考え方からJavaへ

今までIBMホスト畑で働いていたので、使用できる言語は
COBOLやPL/Iだけでしたが、今後の仕事の展開も考え
Javaを習得したいと思っています。

とりあえずJava言語の入門書を終えたので、
次は、以前新人のCOBOL研修用に作成した仕様書を
Javaで書きかえてみようと思いたったのですが・・・

できませんでした。。。
COBOLは、MAINルーチンをプログラムの主とし
個々の機能(FILEのREAD処理など)をそれぞれの
SUBルーチンで記述するといった構造的な作りになっています。



これをJavaにすると「FileのREAD処理」を1つのクラスとして考え、
「MAINルーチン的」な実行クラスから
「FileのREAD処理」クラスを呼ぶ（継承する）のか？
オブジェクト指向とは、もっと別のことではないか？

といったように、全然ちんぷんかんぷんな状況です。

みなさん、Javaでプログラムを記述するときは
どういったアルゴリズムを考えながら記述しているのでしょうか？
是非ともご教授ください。

また、COBOLには、誰がソースをみてもわかりやすいように
記述するなどの暗黙的な決まり(ネストは３回程度など)があるのですが、
Javaにもあるのでしょうか？

No.3 ベストアンサー 回答者： liar_adan 回答日時： 2004/09/17 20:28

COBOLの事はよく知らないので、自信なしとします。

「手続き型言語一般」と「オブジェクト指向言語であるJava」の対比と考えて話します。

すでにCOBOLで書いたプログラムをJavaに書き換えるという場合、
「オブジェクト指向」は考える必要がない・考えてしまうとできないと思います。

その場合、クラスはアプリケーション全体でひとつだけにして、
それぞれのサブルーチンをメソッド（staticメソッドで良い）にするといいでしょう。
オブジェクトの観点からは、上記のような書き方は「とんでもない」のですが、
移植の場合仕方ない方法であると思います。

お気付きの通り、「クラス」は「メインルーチン」とか
「READ処理」とかいったものではありません。
データと、それに付随する処理のかたまりです。
「このアプリケーションでは、どんなデータを扱うのか」
をまず考え、それらに対してクラスを設計していきます。

Javaなど、オブジェクト指向言語でプログラムを書くときには、
アルゴリズムのことは、考えません。
「どんなデータがあるか」「それに付随する処理は何か」をまず考えます。
実装段階でやっとアルゴリズムのことを考えます。

「オブジェクト指向」と「手続き型」では、得意とする粒度がちがうのです。
オブジェクト指向は大規模なシステムを組むのに向き、
手続き型は、行う作業そのものを考えます。

「オブジェクト指向」の根底には「擬人化」があると考えるとわかりやすいと思います。
ある処理を、仮に人間の組織が行うとしたら…と考えて、
「この情報はあの部署にある。処理するにはあの部署と
あの部署の強力を得て、
こういう作業をすればいいな…」
のように考えます。そして「部署」を「クラス」に置き換えます。

COBOL用の仕様書はオブジェクト指向プログラムにはならないと思います。
最初の発想が違います。
その際、手続き的な処理をそのままJavaに置き換えるほかありません。

Javaのコード規約としては、
Java2SDKドキュメントから辿れる
「Java プログラミング言語に関するコード規約」
というものがあります。
他にもいくつか、ローカルのコード規約はあります。

参考URL：http://java.sun.com/docs/codeconv/index.html

この回答へのお礼

>その場合、クラスはアプリケーション全体でひとつだけにして、
>それぞれのサブルーチンをメソッド（staticメソッドで良い）にするといいでしょう。

誠にその通りですね。目からうろこ状態です。
ありがとうございます。
一通り入門書を勉強したら、いろいろ機能を使わなきゃ！
といった観念になっていました。

しかし「COBOL用の仕様書」が「オブジェクト指向」の
プログラムにならないのは、いただけないですね。
ホストのＯＳに「Ｚ／ＯＳ」なるものがあります。
これはＪＡＶＡの使用が可能だそうです。
となると、今までＣＯＢＯＬで作成していたプログラムを
ＪＡＶＡに変えるといった仕事が発生するかもしれません。

ＩＭＳ／ＳＡＩＬに変わると言われる、
ＮｅＦＩＳ(金融統合パッケージ）も出たことだし。。。

お礼日時：2004/09/19 02:13

No.2 回答者： imogasi 回答日時： 2004/09/17 19:32

何十年も前のCOBOLしか知らないもので、情報技術受験のコボルの本などではあまり変ってないように見うけましたが、ACCEPTとDISPLAYしかなかったCOBOLは今は画面関係はどうなってますか。

ウィンドウズではホンとに多彩なことが出来ます。
私見では、JAVAなどは、GUI（画面関係、コントロールなど。ユーザーのマウスなどの反応で流れる処理が変る）と通信が前面にでて、バッチ処理の影が解説書上では薄い。
いままでバッチ処理を中心にやってきませんでしたか。
このリアルタイム処理的なGUIを処理することを考えると
どうしてもオブジェクト指向的なプログラムのメリットを
利用せざるを得なかったと思います。これが何のことを言っているのか、納得出来れば、JAVAなどの抵抗感が消えるかも知れないと思ってます。
数十のRESERVEDで済んでいたCOBOLと、処理ごとにクラスを調べないといけないJAVAでは、後退した感をもつと思いますが、それだけプログラムを細切れにして使えるように
なっていると思えばよいのかも。
ウィンドウズ時代になって、何しろ処理することが複雑になって、昔では夢のようなこ（一例で色が付くとか絵が動く）とが実現しているのですから。コボル懐かしやを乗りきってください。

No.1 回答者： wolfwood 回答日時： 2004/09/17 17:24

オブジェクト指向の設計方法としてはUMLが世界的に広まっています。

また、Javaの場合はクラスの仕組みなどを一定のパターンとしてまとめたデザインパターンというものがあります。
「UML」と「デザインパターン」というキーワードで検索すれば多くの情報が得られると思います。
参考書も沢山出てます。

学習に役立ちそうなサイトです。
http://www.atmarkit.co.jp/fjava/#0

>また、COBOLには、誰がソースをみてもわかりやすいように
>記述するなどの暗黙的な決まり(ネストは３回程度など)があるのですが、
>Javaにもあるのでしょうか？

COBOLにはデフォルトでそのような暗黙的な決まりがあるのですか？
COBOLは未経験なのですが、今までCやJavaを経験しましたが、開発の現場によって
コーディング規約があり、そこでネストの階層などは決められていました。
特に言語ごとでは決められてはいないと思います。

参考URL：http://www.atmarkit.co.jp/fjava/#0

この回答へのお礼

早速のご回答ありがとうございます。

「ＵＭＬ」「デザインパターン」ともに知りませんでした。勉強してみます。
しかし、覚えること勉強することが多いですね。
皆さんがスラスラコーディングしていると考えると驚嘆に値します。

ちなみに、もちろんＣＯＢＯＬもプロジェクトにより
ネストの数は変わります。(例が悪かったですね。）
Javaにおいて、『こういうコーディングは分かり難いからやめよう！みんなに笑われるよ。』
といった暗黙的な約束事はあるのでしょうか？

お礼日時：2004/09/17 18:09