だからここに私のプロジェクトがあります:
複数の製品バージョンのいくつかのテスト タイプのテスト データを表示するための中央インターフェイス/ダッシュボードを構築しています。私たちは大規模な製品で TestNG を使用しており、十分なテストが作成されていませんが、それは別のトピックの議論です。ディレクトリ構造は次のようになります。
ファイルシステム/productVersion+testType/uniqueDateAndBuildID/testng-results.xml
その results.xml ファイルには、ファイルシステムディレクトリに対応する子テストタグを持つタグが含まれており、実際のテストケースの結果 (合格、不合格など) を含む xml ファイルに対応しています。
制御の流れ: クライアントはメイン ページにアクセスします --> サーバーはプロパティ ファイルを開きます --> サーバーは Web サーバー プロパティ (ローカルで作業している場合は Websphere または Tomcat) をチェックします --> サーバーはそれに基づいて一連の定数を設定します。定数には、ルート ファイルシステム ディレクトリ、ファイル システム セパレータ (翻訳)、「類似タイプ (異なるプラットフォームでも基本的に同じテスト)」、および追加するベース URL が含まれます。--> 次に、サーバーはプロパティ ファイルをさらに読み取り、すべての XML 処理を行います。結果は ObjectOutputStream を使用してファイルシステムだけでなくメモリにもキャッシュされます。--> 結果の大きなリストがクライアントに返され、UI の処理/表示が行われます。
ここで問題が発生します。共有フォルダーにあるにもかかわらず、これらのグローバル変数 (Globals クラスに含まれている/設定されている...悪いことは知っています:-/) にアクセスできません。なぜプロパティを再度ロードできないのか疑問に思っているなら、それはクライアントが File() を含まない GWT 化された Javascript だからです。したがって、私の次の考えは、上位レベルの Java の読み取りを少し行った後、おそらく Globals シングルトン オブジェクトを使用してそれを戻すことでした..しかし、それは不可能ではないにしても、同じくらい悪いようです。 ここでの提案は素晴らしいでしょう。
このすべてがかなり緊密に結合されており、以前の Java 教育ではまだ理解できていませんでした。これは開発者がチェックするための単なる内部ポータルであるため、実際にコードをテストする意味はないようです。正しく表示され、適切にログに記録され、エラーを適切に処理する限り、そうですか? 全体として、クラスは 15 未満なので、大したことではないと思います。リファクタリングしてすべてをクリーンアップして「より良いJava」にするか、すべてをコメントして制御の流れを明確に描写するか、それとも小さいのであまり心配しないでください。将来、物事を設計する前にもっと考えなければならないことはわかっていますが、Java を始めてから触れてきた高度な Java 原則の多くについては本当に知りませんでした。
少し考えた後、編集して、可能な回避策を思いつきました。結果のリストだけを返す代わりに、グローバルの「ヘッダー」オブジェクトを含む他のカスタム リストの実装を返してはどうですか? 状態を維持できました。