9

いくつかの検証を得たと考えてください。これらの検証は、検査対象のオブジェクトが特定のタイプである場合にのみ有効になります。switch-statement よりも責任の連鎖を使用するのはなぜですか?

責任の連鎖の例

public class Executor {

@Inject
private ValidatorFactory validatorFactory;

public void execute(Konfiguration konfig) {
    List<Statement> statements = konfig.getStatements();
    AbstractValidator validator = validatorFactory.create();
    for (Statement statement : statements) {
        if (validator.validate(statement.getType())) {
            crudService.execute(statement.getSql());
        }
    }
}

validatorFactory は Validators のチェーンを作成します。1つのバリデータは次のようになります

public class AddPrimaryKeyValidator extends AbstractValidator {

@Override
public boolean validate(Statement statement) {
    if (SqlType.ADD_PK.getTyp().equals(statement.getType())) {
        return doesTableAndPrimaryKeyExist(statement.getTabName());
    }
    return successor.validate(statement);
}

switch ステートメントを使用した例

public void execute(Konfiguration konfig) {
    List<Statement> statements = konfig.getStatements();
    for (Statement statement : statements) {
        switch (statement.getType()) {
        case "ADD_PK":
            if (doesTableAndPrimaryKeyExist(statement.getTabName())) {
                frepCrudService.execute(statement.getSql());
            }
            // more cases
        }
    }
}
4

2 に答える 2

8

責任の連鎖では、発信者の前で誰が何をするかを知る必要がないからです。チェーン内のコードをいつ実行するかを決定するロジックはユーザーが所有し、残りのコードはそれを無視できます。これにより、特定のロジックを適切な場所にカプセル化できます。サーブレット フィルターはこの良い例です。

于 2015-10-19T14:55:16.200 に答える
0

一連の責任を使用する奇妙な理由のように見えます。あなたは基本的に、ifステートメントの動的リストを作成するためだけにチェーンを構築していますが、ステートメントごとに1つのバリデーターでチェーンの初期化をハードコーディングしたと確信しているため、おそらく動的ではありません。

責任の連鎖は、これに適したパターンではないと思います。代わりに if ステートメントをポリモーフィズムに置き換える必要があります。

たとえば、特殊なStatementクラスがある場合は、statement.validate(). Statement必要がない場合は、それ自体を検証する必要はありません。内部で使用するバリデーターを認識し、検証を委任することができます。

特殊なステートメント クラスがない場合は、チェーン全体を構築する代わりに、ファクトリに適切なバリデータをすぐに要求できます。

于 2015-10-20T05:15:44.523 に答える