Ce pattern est très couramment employé car il permet de construire dans une classe abstraite une logique d’exécution non finalisé que devront définir les classes filles
public abstract class AbstractCommand {Ainsi par exemple, dans le cas de cet exemple, toutes les commandes dérivant la classe abstraite devront se conformer a définir les trois méthode precond, execute et postcond, celle-ci étant orchestrées de façon standard pour toutes les commande par la méthode operate.
protected abstract void precond();
protected abstract void execute();
protected abstract void postcond();
public final void operate()
{
this.precond();
this.execute();
this.postcond();
}
}
Cet exemple soufre évidement d'une trivialité sans nom, et ne retranscrit pas complétement l’intérêt de ce pattern très puissant mais l'on peut facilement imaginé que dans la classe abstraite certain comportement soit inconnu et que l'on préfère déléguer aux classes filles la responsabilité de remplir les trous.
A noter que pour contraindre l'utilisation de la méthode operate, on définira les 3 méthodes abstraites a protected et la méthode operate a final.
public class MaCommande extends AbstractCommand {
@Override
protected void precond() {
System.out.println("precond");
}
@Override
protected void execute() {
System.out.println("execute");
}
@Override
protected void postcond() {
System.out.println("postcond");
}
}
Aucun commentaire:
Enregistrer un commentaire