final n'est pas acceptable quand on veut du non-virtual uniquement
Mais donne le ton exemple ! C'est quoi ton problème, tu n'as pas d'exemple, c'est ça ? Par ce que franchement, je ne vois pas de problème lié à final/virtual (éventuellement aux différences de sémantique entre les privates et bien entendu en raison de l'absence d'héritage multiple).
Tu as bien dit au départ : "les fonctions automatiquement virtuelles : impossible de faire de la vérif de pré/post condition derrière l'interface, qui est l'endroit où les faire (ça ne doit pas être laissé à la classe qui implémente)."
Voici donc un exemple en Java. Bidule est une "interface" dans laquelle on implémente les pré/post condition.
public abstract class Bidule {
protected abstract void versionInterne();
public final void versionExterne() {
// précondition
versionInterne();
// postcondition
}
}
Truc est une implémentation de l'interface.
public class Truc extends Bidule {
protected void versionInterne() {
System.out.println("Et hop");
}
}
Quelles sont les différences avec un design pattern équivalent en C++ :
1) pas d'héritage multiple, donc des limitations pratiques du schéma en Java : je suis d'accord, l'héritage multiple apporte beaucoup sur ce genre d'exemple
2) il est impossible de mettre versionInterne en private en Java : soit, c'est une limitation, mais personnellement elle ne me choque pas plus que ça.
Tu en trouveras sûrement d'autres, mais je ne vois toujours pas en quoi avoir des fonctions virtuelles par défaut pose un problème sur cet exemple. Et je maintiens qu'il n'y pas de différences importantes entre final/virtual. Ce que tu as mentionné plus haut (le fait qu'on puisse redéfinir une fonction même si elle n'est pas marquée virtual en C++) est une différence factuelle, mais elle permet de telles horreurs sémantiques en C++ que tout programmeur qui se respecte devrait l'oublier.
[^] # Re: Des utilisateurs heureux de Java
Posté par boubou . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 3.
Mais donne le ton exemple ! C'est quoi ton problème, tu n'as pas d'exemple, c'est ça ? Par ce que franchement, je ne vois pas de problème lié à final/virtual (éventuellement aux différences de sémantique entre les privates et bien entendu en raison de l'absence d'héritage multiple).
Tu as bien dit au départ : "les fonctions automatiquement virtuelles : impossible de faire de la vérif de pré/post condition derrière l'interface, qui est l'endroit où les faire (ça ne doit pas être laissé à la classe qui implémente)."
Voici donc un exemple en Java. Bidule est une "interface" dans laquelle on implémente les pré/post condition.
Truc est une implémentation de l'interface.
Quelles sont les différences avec un design pattern équivalent en C++ :
1) pas d'héritage multiple, donc des limitations pratiques du schéma en Java : je suis d'accord, l'héritage multiple apporte beaucoup sur ce genre d'exemple
2) il est impossible de mettre versionInterne en private en Java : soit, c'est une limitation, mais personnellement elle ne me choque pas plus que ça.
Tu en trouveras sûrement d'autres, mais je ne vois toujours pas en quoi avoir des fonctions virtuelles par défaut pose un problème sur cet exemple. Et je maintiens qu'il n'y pas de différences importantes entre final/virtual. Ce que tu as mentionné plus haut (le fait qu'on puisse redéfinir une fonction même si elle n'est pas marquée virtual en C++) est une différence factuelle, mais elle permet de telles horreurs sémantiques en C++ que tout programmeur qui se respecte devrait l'oublier.