Et comment fais-tu en Java instancier une interface ?
Avec une interface sur une fabrique ? ;-)
C'est beaucoup de travail pour quelque chose qui marche de soi en C++ (et en Ada). Surtout quand on pense à quel point c'est essentiel dans la gestion des projets d'une taille importante.
Là, je ne te suis pas. Pour moi c'est exactement identique qu'en C++. Peut être bien (et même certainement) que dans les applis auxquelles je me suis trouvé confronté, on fait du C++ comme on fait du Java mais la fabrique est un modèle courant pour instancier et c'est même pour ainsi dire le seul modèle dans le cas d'une famille d'objets "entité" implémentant la même interface.
La fabrique est un modèle courant en C++. On s'en sert quand on a besoin d'une fabrique. Pas, en revanche, pour contourner les faiblesses du langage.
D'après mes expériences avec le Java, les interfaces (au sens du langage Java) sont quasiment inutilisable ; il faut prèsque toujours une classe abstraite, ne serait-ce que pour définir le contrat, et du coup, on perd la possibilité >> > Pas compris. De quel contrat parles-tu ? Garantir des >> > pré/post-conditions sur un membre de l'interface ?
Tout à fait. En C++, en général, quand on a besoin d'un contrat (ce qui est assez courant pour les classes d'entité), les fonctions publiques ne sont pas virtuelles ; elles vérifient le contrat, en renvoyant à des fonctions privées virtuelles pour l'exécution. En Java, déjà, les fonctions privées ne peuvent pas être virtuelles (or qu'elles représentent environ les deux tiers de mes fonctions virtuelles ne C++), je suis obligé à me rabattre sur des fonctions protégées. Et des vérifications, c'est du code ; c'est donc interdit dans une interface.
Cette technique ne me parait ni plus ni moins qu'une possibilité parmi d'autres de workaround pour ces contrats non supportés par le langage, aussi bien en C++ qu'en Java.
Le problème en Java, c'est que cette technique exige des fonctions virtuelles privées. Et si on veut de l'héritage multiple des interfaces, on ne peut pas pas l'avoir si l'« interface » est implémentée au moyen d'une classe abstraite.
En ce qui me concerne, je me contente d'assertions aux endroits où il y a effectivement besoin d'être sûr qu'un certain état est atteint, ce qui d'ailleurs me semble souvent plus parlant en termes de code. Par exemple une postcondition dans le code de l'appelant ou une précondition en tête de l'implémentation.
Le problème, c'est que les post- et les pré-conditions doivent être définies par l'interface.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Olivier Azeau wrote:
James Kanze wrote:
Olivier Azeau wrote:
James Kanze wrote:
Et comment fais-tu en Java instancier une interface ?
Avec une interface sur une fabrique ? ;-)
C'est beaucoup de travail pour quelque chose qui marche de
soi en C++ (et en Ada). Surtout quand on pense à quel point
c'est essentiel dans la gestion des projets d'une taille
importante.
Là, je ne te suis pas. Pour moi c'est exactement identique
qu'en C++. Peut être bien (et même certainement) que dans les
applis auxquelles je me suis trouvé confronté, on fait du C++
comme on fait du Java mais la fabrique est un modèle courant
pour instancier et c'est même pour ainsi dire le seul modèle
dans le cas d'une famille d'objets "entité" implémentant la
même interface.
La fabrique est un modèle courant en C++. On s'en sert quand on
a besoin d'une fabrique. Pas, en revanche, pour contourner les
faiblesses du langage.
D'après mes expériences avec le Java, les interfaces (au
sens du langage Java) sont quasiment inutilisable ; il
faut prèsque toujours une classe abstraite, ne serait-ce
que pour définir le contrat, et du coup, on perd la
possibilité >> > Pas compris. De quel contrat parles-tu ?
Garantir des >> > pré/post-conditions sur un membre de
l'interface ?
Tout à fait. En C++, en général, quand on a besoin d'un
contrat (ce qui est assez courant pour les classes d'entité),
les fonctions publiques ne sont pas virtuelles ; elles
vérifient le contrat, en renvoyant à des fonctions privées
virtuelles pour l'exécution. En Java, déjà, les fonctions
privées ne peuvent pas être virtuelles (or qu'elles
représentent environ les deux tiers de mes fonctions
virtuelles ne C++), je suis obligé à me rabattre sur des
fonctions protégées. Et des vérifications, c'est du code ;
c'est donc interdit dans une interface.
Cette technique ne me parait ni plus ni moins qu'une
possibilité parmi d'autres de workaround pour ces contrats non
supportés par le langage, aussi bien en C++ qu'en Java.
Le problème en Java, c'est que cette technique exige des
fonctions virtuelles privées. Et si on veut de l'héritage
multiple des interfaces, on ne peut pas pas l'avoir si
l'« interface » est implémentée au moyen d'une classe abstraite.
En ce qui me concerne, je me contente d'assertions aux
endroits où il y a effectivement besoin d'être sûr qu'un
certain état est atteint, ce qui d'ailleurs me semble souvent
plus parlant en termes de code. Par exemple une postcondition
dans le code de l'appelant ou une précondition en tête de
l'implémentation.
Le problème, c'est que les post- et les pré-conditions doivent
être définies par l'interface.
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Et comment fais-tu en Java instancier une interface ?
Avec une interface sur une fabrique ? ;-)
C'est beaucoup de travail pour quelque chose qui marche de soi en C++ (et en Ada). Surtout quand on pense à quel point c'est essentiel dans la gestion des projets d'une taille importante.
Là, je ne te suis pas. Pour moi c'est exactement identique qu'en C++. Peut être bien (et même certainement) que dans les applis auxquelles je me suis trouvé confronté, on fait du C++ comme on fait du Java mais la fabrique est un modèle courant pour instancier et c'est même pour ainsi dire le seul modèle dans le cas d'une famille d'objets "entité" implémentant la même interface.
La fabrique est un modèle courant en C++. On s'en sert quand on a besoin d'une fabrique. Pas, en revanche, pour contourner les faiblesses du langage.
D'après mes expériences avec le Java, les interfaces (au sens du langage Java) sont quasiment inutilisable ; il faut prèsque toujours une classe abstraite, ne serait-ce que pour définir le contrat, et du coup, on perd la possibilité >> > Pas compris. De quel contrat parles-tu ? Garantir des >> > pré/post-conditions sur un membre de l'interface ?
Tout à fait. En C++, en général, quand on a besoin d'un contrat (ce qui est assez courant pour les classes d'entité), les fonctions publiques ne sont pas virtuelles ; elles vérifient le contrat, en renvoyant à des fonctions privées virtuelles pour l'exécution. En Java, déjà, les fonctions privées ne peuvent pas être virtuelles (or qu'elles représentent environ les deux tiers de mes fonctions virtuelles ne C++), je suis obligé à me rabattre sur des fonctions protégées. Et des vérifications, c'est du code ; c'est donc interdit dans une interface.
Cette technique ne me parait ni plus ni moins qu'une possibilité parmi d'autres de workaround pour ces contrats non supportés par le langage, aussi bien en C++ qu'en Java.
Le problème en Java, c'est que cette technique exige des fonctions virtuelles privées. Et si on veut de l'héritage multiple des interfaces, on ne peut pas pas l'avoir si l'« interface » est implémentée au moyen d'une classe abstraite.
En ce qui me concerne, je me contente d'assertions aux endroits où il y a effectivement besoin d'être sûr qu'un certain état est atteint, ce qui d'ailleurs me semble souvent plus parlant en termes de code. Par exemple une postcondition dans le code de l'appelant ou une précondition en tête de l'implémentation.
Le problème, c'est que les post- et les pré-conditions doivent être définies par l'interface.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Loïc Joly
Ce qui est certain, quelles que soient les motivations pour retirer ou ajouter telle ou telle chose dans le langage, c'est que plus on peut simplifier le contenu des fichiers utilisés en #include, plus on gagne en abstraction (tout en gardant bien évidemment une maitrîse maximale sur la granularité des unités de compilation : il ne s'agit pas d'être obligé de mettre toutes les classes dans un seul fichier).
Je ne suis pas certain : Par exemple, pouvoir spécifier un contrat d'une fonction, ou un concept auquel doit répondre un argument template sont deux actions qui iraient à mon avis vers une meilleurs abstraction tout en complexifiant l'écriture de l'interface publique d'un module par rapport à la situation actuelle.
-- Loïc
Ce qui est certain, quelles que soient les motivations pour retirer ou
ajouter telle ou telle chose dans le langage, c'est que plus on peut
simplifier le contenu des fichiers utilisés en #include, plus on gagne
en abstraction (tout en gardant bien évidemment une maitrîse maximale
sur la granularité des unités de compilation : il ne s'agit pas d'être
obligé de mettre toutes les classes dans un seul fichier).
Je ne suis pas certain : Par exemple, pouvoir spécifier un contrat d'une
fonction, ou un concept auquel doit répondre un argument template sont
deux actions qui iraient à mon avis vers une meilleurs abstraction tout
en complexifiant l'écriture de l'interface publique d'un module par
rapport à la situation actuelle.
Ce qui est certain, quelles que soient les motivations pour retirer ou ajouter telle ou telle chose dans le langage, c'est que plus on peut simplifier le contenu des fichiers utilisés en #include, plus on gagne en abstraction (tout en gardant bien évidemment une maitrîse maximale sur la granularité des unités de compilation : il ne s'agit pas d'être obligé de mettre toutes les classes dans un seul fichier).
Je ne suis pas certain : Par exemple, pouvoir spécifier un contrat d'une fonction, ou un concept auquel doit répondre un argument template sont deux actions qui iraient à mon avis vers une meilleurs abstraction tout en complexifiant l'écriture de l'interface publique d'un module par rapport à la situation actuelle.
-- Loïc
Marc Boyer
Gabriel Dos Reis wrote:
Marc Boyer writes: [SNIP]
| Sauf qu'il sert | 1) d'interface au module (permet la compilation du code l'utilisant) | 2) de documentation d'utilisation | | Java a supprimé 1) en forçant la compilation d'une unité | avant de pouvoir l'utiliser ailleurs et 2) en imposant JavaDoc.
oui mais personne ne m'a expliqué ces suppressions imposent un niveau d'abstraction plus élevé.
Moi non plus. Ce que je sais pas contre, c'est que ça me complique le codage avec mon Xemacs, et me pousserais à devoir faire un upgrade de mon installation, voire un basculement à Eclipse (et donc un upgrade de ma CPU, de ma mémoire, et peut-être du reste de la machine tant qu'à y être).
| Est-ce que ce sont des bons choix ? Ca se discute...
Comme chez Jean-Luc ?
Non, comme sur fclc en ce moment ("Le C comme premier langage", <d1pcfl$fvn$).
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Gabriel Dos Reis wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
[SNIP]
| Sauf qu'il sert
| 1) d'interface au module (permet la compilation du code l'utilisant)
| 2) de documentation d'utilisation
|
| Java a supprimé 1) en forçant la compilation d'une unité
| avant de pouvoir l'utiliser ailleurs et 2) en imposant JavaDoc.
oui mais personne ne m'a expliqué ces suppressions imposent un niveau
d'abstraction plus élevé.
Moi non plus.
Ce que je sais pas contre, c'est que ça me complique le codage
avec mon Xemacs, et me pousserais à devoir faire un upgrade
de mon installation, voire un basculement à Eclipse (et donc
un upgrade de ma CPU, de ma mémoire, et peut-être du reste
de la machine tant qu'à y être).
| Est-ce que ce sont des bons choix ? Ca se discute...
Comme chez Jean-Luc ?
Non, comme sur fclc en ce moment ("Le C comme premier langage",
<d1pcfl$fvn$2@news.cict.fr>).
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
| Sauf qu'il sert | 1) d'interface au module (permet la compilation du code l'utilisant) | 2) de documentation d'utilisation | | Java a supprimé 1) en forçant la compilation d'une unité | avant de pouvoir l'utiliser ailleurs et 2) en imposant JavaDoc.
oui mais personne ne m'a expliqué ces suppressions imposent un niveau d'abstraction plus élevé.
Moi non plus. Ce que je sais pas contre, c'est que ça me complique le codage avec mon Xemacs, et me pousserais à devoir faire un upgrade de mon installation, voire un basculement à Eclipse (et donc un upgrade de ma CPU, de ma mémoire, et peut-être du reste de la machine tant qu'à y être).
| Est-ce que ce sont des bons choix ? Ca se discute...
Comme chez Jean-Luc ?
Non, comme sur fclc en ce moment ("Le C comme premier langage", <d1pcfl$fvn$).
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
