構成ファイルを読み取り、構成ファイルで指定されたアプリケーション/プログラムを実行するツールを実装する必要があります。テスト用の一種の自動ランナー。それを行うプログラムを実装しましたが、依存関係の壁にぶつかりました。私の現在の設計では、ツールは構成ファイルを解析し、ProgramType のマップとジョブのリストを取得します。ProgramType に基づいて、Runner クラスが選択されて初期化されます。Runner クラスは Program src の一部です。
//this is just a pseudo code
pkg org.Tool
class Tool {
//after parsing
runJobs(map) {
if(map.get() == ProgramType)
org.Tool.JobStats = org.ProgramType.Runner.run(Job)
}
}
pkg org.ProgramType
class Runner {
org.Tool.JobStats run(Job) {
if(Job = "certain job")
return CertainJob.run(Job)
}
}
ツールをビルドするには、コンパイル済みの org.ProgramType.*; が必要です。ProgramType をビルドするには、org.Tool.Job と org.Tool.JobStats が必要です。私が作成した「依存地獄」は、明らかに非常に悪い設計です。私は単純に ProgramType jar を呼び出して JobStats を jobStats.txt ファイルに保存し、jar の実行が終了したら、ファイルを読み取って処理するという解決策を考えました。ジョブは多くの構成などで複数回実行でき、処理する *.txt ファイルが多くなるだけなので、このソリューションは受け入れられません。「部分コンパイル」ツール、ProgramType のコンパイル、Tool の再コンパイルなど、私の問題に対するコンパイル ソリューションを見たことがあると思います。しかし、私はそれを見つけることができません。また、「依存地獄」アンチパターンを取り除くのが賢明でしょう。したがって、「これをどのように設計する必要があったか」という私の質問。
(質問するだけでなくても、説明が明確であることを願っています)
解決した
コメント@aviadに書いたように、私は自分の問題を解決するためにデザインパターンを探していました。「依存性逆転原則」と呼ばれるものを見つけました。ここでは、パターンを説明する pdf ドキュメントをリンクしています。読む価値があります (http://www.objectmentor.com/resources/articles/dip.pdf) (別の良い説明http://java.dzone.com/articles/fun -モジュール)。ご協力いただきありがとうございます(あなたが推奨するフレームワークが本当に気に入りました)。