序文
以前仕事中に書いたブログ投稿の一部がブログに同期されませんでした。この記事は、読者にインスピレーションを与えることを目的として、1 年以上前に書かれた可能性があります。
複数のゲームのデータ背景を共有し、異なる設定を通じて異なるゲームや環境を区別します。を指定して、どの設定セットを読み取るかを決定しますapplication.properties。spring.profiles.active
たとえば、コード名 sfish という prd 環境に公開する必要がある場合は、それを選択できspring.profiles.active=sfishlyprd、設定ファイルは resource/config 下有application-sfishlyprd.properites` にあります。
ファイルはゲーム ID によって区別されます。
gameid=sfishlyprd
文章
元のスケジュールされたタスクにはクラスが 1 つだけあり、このクラスには多数のメソッドがあり、各メソッドは特定のプロジェクトに属します。次に、次のようなロジックで判断します。
最適化のために私が行った最初のステップは、プロジェクトごとにメソッドを分類することであり、独自のクラスは対応するプロジェクトに対応します。に似ている：
これは単なる論理的な分割であり、実際の動作には大きな影響はありません。つまり、現在の Sfish プロジェクトであっても、lytj プロジェクトのスケジュールされたタスクは引き続き実行されます。
SpringBoot のスケジュールされたタスクはオペレーティング システムのスレッドにマップされて実行されるため、さらなる最適化を実行する必要があります。
- まず、親クラスを定義し、これらのプロジェクトのプラン クラスがこの親クラスを継承できるようにします。
public class GameSchedule {
}
public class SfishSchedule extends GameSchedule{
}
@ComponetSpringBoot がこれらのクラスを自動的にロードしないように、これらのプロジェクト プラン クラスをコメント化します。
- 構成クラスを作成します。ロジックは、現在のプロジェクトの構成ファイルを読み取ってゲーム ID を取得し、そのゲーム ID を使用してどのサブクラスを有効にするかを決定することです。現在スケジュールされているタスクはすべて特定のプロジェクト用です。将来的に公開タスクが存在する場合は、GameSchedule クラスにメソッドを直接追加できます。
@Configuration
public class ScheduleConfig {
@Value("${gameid}")
private String gameid;
@Bean
public GameSchedule createSchedule(){
if (gameid.startsWith("sfish") || gameid.startsWith("zfsfish")) {
return new SfishSchedule();
} else if (gameid.startsWith("lytj")) {
return new LytjSchedule();
}
return new GameSchedule();
}
}
将来的に新しいメソッドを追加するときに、ゲーム ID の判定を記述する必要がなくなりました。
振り返って
上記の設定クラスのコードはさらに最適化できるようですが、その前提として、さまざまなゲーム ID の名前を統一するか、新しい属性を使用してそれらを区別する必要があります。たとえば、lytj を解析した後、それを見つけて、見つけて、LytjSchedule次に、リフレクションをsfish使用してSfishSchedule、関連するクラスをインスタンス化します。