jUnit
Java でテストをスクリプト化するために構築されたフレームワークを作成しています。
これはタスク ベースであり、各タスクは順番に実行されます。簡略化したビューを次に示します。
すべてのタスクが使用するインターフェースは次のようになります
public interface Task {
void run(Callback callback);
}
Callback
タスクが終了したことを実行者に伝える方法をタスクに提供するインターフェイスを使用します。
public interface Callback {
void done();
void failed(String wtf);
}
また、エグゼキューター、外部 (物理) インターフェース、および設定クラスへのインターフェースをユーザーに提供しています。私はこれをランタイム環境と呼び、抽象的に実装されています。
public abstract class RuntimeEnvironment {
void execute(Task task) { ... }
void schedule(Task task, long delay) { ... }
SomeExternalInterface external();
Settings settings();
}
whereSomeExternalInterface
とSettings
は、フレームワークと実装ユーザーの両方によって使用されるインターフェイスです。
threadPoolSize
フレームワークはfrom Settings
、および 'initialize()' と 'cleanUp()' from のようなメンバーを使用する場合があります。SomeExternalInterface
このクラスがタスクに渡される方法は、現在、実装するタスク クラスのコンストラクターを介して行われます。私はこれが好きではありません。Task
インターフェイスで RuntimeEnvironment を指定する場合と比較して、あいまいな API になります。
あなたが尋ねるタスクインターフェースにそれを追加してみませんか? お気に入り
public interface Task {
void run(Callback callback, RuntimeEnvironment runtime);
}
なぜなら、実行runtime.settings().getThreadPoolSize()
は問題ありません (インターフェイスで指定されているため) が、ユーザーが取得できるようにしたい場合、runtime.settings().getWonkyTimeUnit()
またはruntime.external().attemptToDefuseImminentExplotion()
それぞれのインターフェイスの実装で指定した場合はどうなるでしょうか? runtime.settings() は、実装クラスではなく、インターフェースを返します。
そう ...