2

Java を使用して JCL を生成しています。データ定義ステートメントを追加する方法は 4 つあります。1 つは char、1 つは文字列、1 つは (文字列の) 配列を受け入れ、もう 1 つは 2 番目のパラメーターに何もありません。

public void addDD (String label, char classChar) //Generates: SYSIN DD SYSOUT=[classChar]
public void addDD (String label, String dataset) //Generates: SYSIN DD DSN=[dataset]
public void addDD (String label) //Generates: SYSIN DD DUMMY
public void addDD (String label, String datasets[]) //Generates: SYSIN DD *
                                                    // DSN=[datasets[0]],
                                                    // DSN=[datasets[1]]

私が懸念しているのは、これらのメソッドが異なるパラメーター タイプを受け入れるだけではないということです。タイプによってメソッド全体が変わります。文字列の場合は「DSN=」が必要です。char の場合は、「SYSOUT=」が必要です。同時に、これらのシナリオごとに異なるメソッド名を使用することをクライアントに心配させたくありません。

私の現在の設計は悪い習慣と見なされますか、それとも良いと見なされますか?

4

4 に答える 4

0

あなたがやっていることは非常に危険です - の呼び出し元がaddDD(String, char)javadocs を読んで、代わりに使用すべきではないことを理解することを当てにしていaddDD(String, String)ます。

オプション 1 : メソッドの名前を変更します:addDDSysout()などaddDDDsn()。

オプション 2 : これらすべてを 1 つのメソッドだけで実装します。

addDD(String label, String... args)

そして、スローされたものをすべて処理できることを確認してください-引数に文字列がない、単一の文字列、複数の文字列、単一の文字など。

于 2013-10-28T19:49:05.537 に答える
0

これらのことはしばしば好みの問題であることに同意しなければなりません。しかし、他の応答者が JCL DD ステートメントの重要性を理解していたかどうかはわかりません。あなたの問題のドメインに基づいて、私は彼らに同意しないからです。

私はあなたのデザインが好きです。別のメソッド名を思いとどまらせます。それは基本的に TSO が FILE(xxx) と DSN(xxx) で行ったことであり、私はいつもそれが嫌いでした。メソッドは入力リーダー ストリームで異なる「結果」を生成しますが、これらの違いは JCL の構文によって強制されます。より具体的に言うと、彼らは異なることをしません。基本的に、データ ソース/シンクをバッチ ジョブに宣言しています。ユーザーにそれを行うための 4 つの異なる方法を学ばせてはなりません。

于 2013-10-28T20:53:47.387 に答える