Discussion :

[Mindiell]

Bonjour à tou(te)s,

J'aimerai me rapprocher au maximum de la notion d'interface (existante en Java par exemple) en C++.

L'avantage que j'y vois étant que l'objet ne sait même pas que l'interface existe ou presque. On peut aussi avoir à modifier l'interface sans modifier l'objet lui-même.

Que penser des fonctions friend pour permettre ce genre de fonctionnalité ? J e trouve qu'utiliser l'héritage et le polymorphisme n'est pas identique à la notion d'interface et je souhaite plus avoir cette notion.

L'exemple type étant de permettre de sauver et charger des données de l'objet depuis n'importe quel support (fichiers, bases de donnée).

Merci d'avance,

[Nudger]

Bonjour,

L'interface en Java n'est rien d'autres qu'une classe ne contenant aucune implémentation et qui sera par la suite héritée.
Il me semble même que le mot clé "extends" est toléré pour implémenter une interface.

La notion en C++ qui s'en approche le plus, c'est les classes abstraites qui peuvent très bien ne contenir aucune implémentation.

[Mindiell]

Non, désolé. L'interface en Java permet d'utiliser un "truc" dont l'objet ne connait rien. L'héritage oblige à connaitre et être lié à la classe mère.

Mon objet n'a pas à connaitre l'interface, et je ne veux pas avoir à modifier l'objet si je dois modifier mon interface. Je veux conserver ces deux choses dans deux endroits bien distincts. D'où ma question à propos des fonctions amies...

[NeoKript]

Mon objet n'a pas à connaitre l'interface, et je ne veux pas avoir à modifier l'objet si je dois modifier mon interface.

Salut, je ne comprend pas trop ta question,
en Java quand tu modifie une interface, tu est bien obligé de modifier les classes qui l'implémente.

Enfin personnellement pour moi une interface en c++, c'est une classe abstraite contenant uniquement des méthodes virtuelles pures.

[dragonjoker59]

Si je me souviens bien les interfaces en Java ne permettent pas d'implémenter quoi que ce soit... Donc je ne comprends pas bien le "truc" que ton objet ne connaitrait pas. Peux tu nous montrer un bout de code Java montrant ce que tu voudrais reproduire en C++ ?

[Luc Hermitte]

Il y a emmêlage de pinceaux.
L'interface Java s'hérite et le truc qui s'en rapproche le plus est la classe abstraite dont toutes les fonctions sont virtuelles pures.
Mais on a mieux : le pattern NVI qui apporte la programmation par contrat aux interfaces (FAQ ?)

[Mindiell]

Hum...

Il semble que je me sois fourvoyé... En fait j'ai bossé sur un projet en java et le responsable nous avait fait utiliser un autre objet que le notre pour sauver/charger l'objet principal. Il a utilisé des interfaces, mais apparemment, c'était pas du tout lié à ce que je pensais.

En d'autres termes, il a simplement créé un objet "Loader" qui utilise l'objet à sauver et ses methodes Get/Set pour le sauver/charger. Je pensais qu'il accédait directement aux membres de l'objet.

Dans ce cas, je vais me faire un objet spécifique aussi et puis c'est tout. Merci à vous et désolé pour le dérangement. L'intérêt que j'y vois est de pouvoir modifier les méthodes de sauvegarde / chargement sans impacter l'objet lui-même.

PS: Désolé de ne pas être très clair, mais pour le moment, je suis assez dans le flou moi aussi

EDIT : Une classe amie serait la solution non ? Accéder aux données membres pour charger/sauver simplement, mais sans utiliser le même objet.

[Luc Hermitte]

boost.serialize est un bon ami.

[3DArchi]

Bonjour,
Pour compléter les réponses de Luc :
F.A.Q Mes fonctions virtuelles doivent-elles être publiques, protégées, ou privées ? Le pattern NVI.

Tutoriel Boost.Serialization : La sérialisation avec Boost par Pierre Schwartz

Ensuite, l'amitié est effectivement ce qui serait le moins intrusif il me semble (en tout cas, j'aurais tendance à préférer une amitié à un héritage artificiel d'une SuperInterface pour tous tes objets à sérialiser).