Java et C++

Arnaud Debaene

31/07/2003 à 18:49

Vincent wrote:

"Arnaud Debaene" wrote in message
news:<3f26ac6e$0$1932$...

D'abord je trouve qu'il s'agit plus de classe abstraites que
d'interfaces.
Syntaxiquement ce sont des classes abstraites, sémantiquement ce sont des

interfaces (elles n'implémentent pas elles-même la fonctionnalité).

En java tu as plusieurs solutions (toutes relativement
lourdes) je vais faire la plus légère mais la moins réutilisable, il
faut externaliser les branchement dans une classe abstraite si cette
combinaison de classes mères doit être utilisé souvent...

interface i1
{
float f1(int param);
}
abstarct class ca1 implements i1
{
public final float f1(int param)
{
//préconditions
float resultat=do_f1(param);
//postconditions
return resultat;
}
protected float do_f1(int param);
};

interface i2
{
float f2(int param);
}
abstarct class ca2 implements i2
{
public final float f2(int param)
{
//préconditions
float resultat=do_f2(param);
//postconditions
return resultat;
}
protected float do_f2(int param);
};

/*ça c'est la méhtode rapide on hérite d'une et on implemente
l'interface de l'autre et on en dérive en interne la classe
abstraite...
ça n'est clairement pas la méthode la plus lisible ou la plus
élégante, mais c'est la plus courte...
*/

class MaClasseUtilisateur extends public CA1 implements I2
{

//class interne implementant i2
protected class I2InternImpl extends CA2
{
protected int do_f2(char param) { // implémentation };
}

public final float f2(int param)
{
I2InternImpl.f2();
}

protected float do_f1(int param) { // implémentation };
};

Ta solution marche effectivement, mais elle pose un gros problème : tu fais
confiance à l'utilisateur de ta bibliothèque pour implémenter (en tou cas en
partie) la fonctionnalité de pré/postconditions. C'est une erreur au niveau
de la séparation des responsabilités entre les différentes parties du code :
en clair, c'est un faute d'encapsulation et tu es obliger de révéler à
l'utilisateur une partie de l'implémentation de ta bibliothèque, alors qu'il
ne devrait avoir connaissance que de I1 et de I2. C'est ce genre de choses
qui rend Java difficile à utiliser pour de gros projets où l'encapsulation
est fondamentale.

Arnaud

Vincent wrote:

"Arnaud Debaene" <adebaene@club-internet.fr> wrote in message
news:<3f26ac6e$0$1932$626a54ce@news.free.fr>...

D'abord je trouve qu'il s'agit plus de classe abstraites que
d'interfaces.
Syntaxiquement ce sont des classes abstraites, sémantiquement ce sont des

interfaces (elles n'implémentent pas elles-même la fonctionnalité).

En java tu as plusieurs solutions (toutes relativement
lourdes) je vais faire la plus légère mais la moins réutilisable, il
faut externaliser les branchement dans une classe abstraite si cette
combinaison de classes mères doit être utilisé souvent...

interface i1
{
float f1(int param);
}
abstarct class ca1 implements i1
{
public final float f1(int param)
{
//préconditions
float resultat=do_f1(param);
//postconditions
return resultat;
}
protected float do_f1(int param);
};

interface i2
{
float f2(int param);
}
abstarct class ca2 implements i2
{
public final float f2(int param)
{
//préconditions
float resultat=do_f2(param);
//postconditions
return resultat;
}
protected float do_f2(int param);
};

/*ça c'est la méhtode rapide on hérite d'une et on implemente
l'interface de l'autre et on en dérive en interne la classe
abstraite...
ça n'est clairement pas la méthode la plus lisible ou la plus
élégante, mais c'est la plus courte...
*/

class MaClasseUtilisateur extends public CA1 implements I2
{

//class interne implementant i2
protected class I2InternImpl extends CA2
{
protected int do_f2(char param) { // implémentation };
}

public final float f2(int param)
{
I2InternImpl.f2();
}

protected float do_f1(int param) { // implémentation };
};

Ta solution marche effectivement, mais elle pose un gros problème : tu fais
confiance à l'utilisateur de ta bibliothèque pour implémenter (en tou cas en
partie) la fonctionnalité de pré/postconditions. C'est une erreur au niveau
de la séparation des responsabilités entre les différentes parties du code :
en clair, c'est un faute d'encapsulation et tu es obliger de révéler à
l'utilisateur une partie de l'implémentation de ta bibliothèque, alors qu'il
ne devrait avoir connaissance que de I1 et de I2. C'est ce genre de choses
qui rend Java difficile à utiliser pour de gros projets où l'encapsulation
est fondamentale.

Arnaud

Vous avez filtré cet utilisateur ! Consultez son message

Vincent wrote:

"Arnaud Debaene" wrote in message
news:<3f26ac6e$0$1932$...

D'abord je trouve qu'il s'agit plus de classe abstraites que
d'interfaces.
Syntaxiquement ce sont des classes abstraites, sémantiquement ce sont des

interfaces (elles n'implémentent pas elles-même la fonctionnalité).

En java tu as plusieurs solutions (toutes relativement
lourdes) je vais faire la plus légère mais la moins réutilisable, il
faut externaliser les branchement dans une classe abstraite si cette
combinaison de classes mères doit être utilisé souvent...

interface i1
{
float f1(int param);
}
abstarct class ca1 implements i1
{
public final float f1(int param)
{
//préconditions
float resultat=do_f1(param);
//postconditions
return resultat;
}
protected float do_f1(int param);
};

interface i2
{
float f2(int param);
}
abstarct class ca2 implements i2
{
public final float f2(int param)
{
//préconditions
float resultat=do_f2(param);
//postconditions
return resultat;
}
protected float do_f2(int param);
};

/*ça c'est la méhtode rapide on hérite d'une et on implemente
l'interface de l'autre et on en dérive en interne la classe
abstraite...
ça n'est clairement pas la méthode la plus lisible ou la plus
élégante, mais c'est la plus courte...
*/

class MaClasseUtilisateur extends public CA1 implements I2
{

//class interne implementant i2
protected class I2InternImpl extends CA2
{
protected int do_f2(char param) { // implémentation };
}

public final float f2(int param)
{
I2InternImpl.f2();
}

protected float do_f1(int param) { // implémentation };
};

Ta solution marche effectivement, mais elle pose un gros problème : tu fais
confiance à l'utilisateur de ta bibliothèque pour implémenter (en tou cas en
partie) la fonctionnalité de pré/postconditions. C'est une erreur au niveau
de la séparation des responsabilités entre les différentes parties du code :
en clair, c'est un faute d'encapsulation et tu es obliger de révéler à
l'utilisateur une partie de l'implémentation de ta bibliothèque, alors qu'il
ne devrait avoir connaissance que de I1 et de I2. C'est ce genre de choses
qui rend Java difficile à utiliser pour de gros projets où l'encapsulation
est fondamentale.

Arnaud

Loïc Joly

31/07/2003 à 18:52

Vincent wrote:

Ce que je dis c'est que les templates sont certes utiles, mais que ça
n'est pas utiliser (sauf domaine très particulier) au point que ça
constitue une différence d'importance pour le choix d'un langage par
un quasi-débutant en programmation et débutant en conception qui aura
déjà bien de la peine à utiliser correctement les concepts objets
avant que les templates débarquent dans Java...

J'estime (et ne suis pas le seul) que pour apprendre le C++, il faut
utiliser des templates AVANT que d'apprendre à construire ses propres
classes (dès qu'on parle de structures de données comme tableaux ou
listes, en fait). L'utilisation de templates n'est pas du tout
accessoire en C++ moderne.

Effectivement, les utilisations avancées ou la création de ses propres
templates me semblent plus destinées à quelqu'un ayant déjà une certaine
habitude.

--
Loïc

Fabien LE LEZ

31/07/2003 à 20:51

On 31 Jul 2003 02:47:18 -0700, (Vincent) wrote:

Content-Type: text/plain; charset=KOI8-R

Oula... c'est quoi ce truc ? En tout cas, les accents ne passent pas
du tout :-(

--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html

vclassine

01/08/2003 à 08:32

Fabien LE LEZ wrote in message news:...

On 31 Jul 2003 02:47:18 -0700, (Vincent) wrote:

Content-Type: text/plain; charset=KOI8-R

Oula... c'est quoi ce truc ? En tout cas, les accents ne passent pas
du tout :-(

Curieux... Je poste toujours depuis google, si ça change c'est que
leur serveur merde (et ça ne serait pas la premièer fois).

vclassine

01/08/2003 à 08:44

D'abord je trouve qu'il s'agit plus de classe abstraites que
d'interfaces.
Syntaxiquement ce sont des classes abstraites, sémantiquement ce sont des

interfaces (elles n'implémentent pas elles-même la fonctionnalité).
Pas faux dans un sens, mais malgré tout le peu de comportement qui est

définit dedans (pre/post condition) n'est pas modifiable. Cette classe
abstraite définit un peu plus qu'une interface, elle inclut une partie
de l'implémentation du contrat... Enfin bref, c'est phylosophique à ce
niveau là. Si on ne s'en tient pas à la définition syntaxique, ça va
être dur de faire une frontière entre classe abstraite et interface...

En java tu as plusieurs solutions (toutes relativement
lourdes) je vais faire la plus légère mais la moins réutilisable, il
faut externaliser les branchement dans une classe abstraite si cette
combinaison de classes mères doit être utilisé souvent...

interface i1
{
float f1(int param);
}
abstarct class ca1 implements i1
{
public final float f1(int param)
{
//préconditions
float resultat=do_f1(param);
//postconditions
return resultat;
}
protected float do_f1(int param);

};

interface i2
{
float f2(int param);
}
abstarct class ca2 implements i2
{
public final float f2(int param)
{
//préconditions
float resultat=do_f2(param);
//postconditions
return resultat;
}
protected float do_f2(int param);

};

/*ça c'est la méhtode rapide on hérite d'une et on implemente
l'interface de l'autre et on en dérive en interne la classe
abstraite...
ça n'est clairement pas la méthode la plus lisible ou la plus
élégante, mais c'est la plus courte...
*/

class MaClasseUtilisateur extends public CA1 implements I2
{

//class interne implementant i2
protected class I2InternImpl extends CA2
{
protected int do_f2(char param) { // implémentation };
}

public final float f2(int param)
{
I2InternImpl.f2();
}

protected float do_f1(int param) { // implémentation };
};

Ta solution marche effectivement, mais elle pose un gros problème : tu fais
confiance à l'utilisateur de ta bibliothèque pour implémenter (en tou cas en
partie) la fonctionnalité de pré/postconditions.
L'appel aux pre/postcondition n'est visible que dans les classes

abstraites CA1 et CA2... L'"héritant" ou l'utilisateur n'en ont pas
connaissance. L'héritant vois en plus de i1 et i2 les fonctions
do_fX() mais je ne vois pas comment il pourrait les redéfinir sans
ça...

C'est une erreur au niveau
de la séparation des responsabilités entre les différentes parties du code :
en clair, c'est un faute d'encapsulation et tu es obliger de révéler à
l'utilisateur une partie de l'implémentation de ta bibliothèque, alors qu'il
ne devrait avoir connaissance que de I1 et de I2. C'est ce genre de choses
qui rend Java difficile à utiliser pour de gros projets où l'encapsulation
est fondamentale.
Je crois qu'on en vois pas plus qu'en C++...

D'abord je trouve qu'il s'agit plus de classe abstraites que
d'interfaces.
Syntaxiquement ce sont des classes abstraites, sémantiquement ce sont des

interfaces (elles n'implémentent pas elles-même la fonctionnalité).
Pas faux dans un sens, mais malgré tout le peu de comportement qui est

définit dedans (pre/post condition) n'est pas modifiable. Cette classe
abstraite définit un peu plus qu'une interface, elle inclut une partie
de l'implémentation du contrat... Enfin bref, c'est phylosophique à ce
niveau là. Si on ne s'en tient pas à la définition syntaxique, ça va
être dur de faire une frontière entre classe abstraite et interface...

En java tu as plusieurs solutions (toutes relativement
lourdes) je vais faire la plus légère mais la moins réutilisable, il
faut externaliser les branchement dans une classe abstraite si cette
combinaison de classes mères doit être utilisé souvent...

interface i1
{
float f1(int param);
}
abstarct class ca1 implements i1
{
public final float f1(int param)
{
//préconditions
float resultat=do_f1(param);
//postconditions
return resultat;
}
protected float do_f1(int param);

};

interface i2
{
float f2(int param);
}
abstarct class ca2 implements i2
{
public final float f2(int param)
{
//préconditions
float resultat=do_f2(param);
//postconditions
return resultat;
}
protected float do_f2(int param);

};

/*ça c'est la méhtode rapide on hérite d'une et on implemente
l'interface de l'autre et on en dérive en interne la classe
abstraite...
ça n'est clairement pas la méthode la plus lisible ou la plus
élégante, mais c'est la plus courte...
*/

class MaClasseUtilisateur extends public CA1 implements I2
{

//class interne implementant i2
protected class I2InternImpl extends CA2
{
protected int do_f2(char param) { // implémentation };
}

public final float f2(int param)
{
I2InternImpl.f2();
}

protected float do_f1(int param) { // implémentation };
};

Ta solution marche effectivement, mais elle pose un gros problème : tu fais
confiance à l'utilisateur de ta bibliothèque pour implémenter (en tou cas en
partie) la fonctionnalité de pré/postconditions.
L'appel aux pre/postcondition n'est visible que dans les classes

abstraites CA1 et CA2... L'"héritant" ou l'utilisateur n'en ont pas
connaissance. L'héritant vois en plus de i1 et i2 les fonctions
do_fX() mais je ne vois pas comment il pourrait les redéfinir sans
ça...

C'est une erreur au niveau
de la séparation des responsabilités entre les différentes parties du code :
en clair, c'est un faute d'encapsulation et tu es obliger de révéler à
l'utilisateur une partie de l'implémentation de ta bibliothèque, alors qu'il
ne devrait avoir connaissance que de I1 et de I2. C'est ce genre de choses
qui rend Java difficile à utiliser pour de gros projets où l'encapsulation
est fondamentale.
Je crois qu'on en vois pas plus qu'en C++...

Vous avez filtré cet utilisateur ! Consultez son message

D'abord je trouve qu'il s'agit plus de classe abstraites que
d'interfaces.
Syntaxiquement ce sont des classes abstraites, sémantiquement ce sont des

interfaces (elles n'implémentent pas elles-même la fonctionnalité).
Pas faux dans un sens, mais malgré tout le peu de comportement qui est

définit dedans (pre/post condition) n'est pas modifiable. Cette classe
abstraite définit un peu plus qu'une interface, elle inclut une partie
de l'implémentation du contrat... Enfin bref, c'est phylosophique à ce
niveau là. Si on ne s'en tient pas à la définition syntaxique, ça va
être dur de faire une frontière entre classe abstraite et interface...

En java tu as plusieurs solutions (toutes relativement
lourdes) je vais faire la plus légère mais la moins réutilisable, il
faut externaliser les branchement dans une classe abstraite si cette
combinaison de classes mères doit être utilisé souvent...

interface i1
{
float f1(int param);
}
abstarct class ca1 implements i1
{
public final float f1(int param)
{
//préconditions
float resultat=do_f1(param);
//postconditions
return resultat;
}
protected float do_f1(int param);

};

interface i2
{
float f2(int param);
}
abstarct class ca2 implements i2
{
public final float f2(int param)
{
//préconditions
float resultat=do_f2(param);
//postconditions
return resultat;
}
protected float do_f2(int param);

};

/*ça c'est la méhtode rapide on hérite d'une et on implemente
l'interface de l'autre et on en dérive en interne la classe
abstraite...
ça n'est clairement pas la méthode la plus lisible ou la plus
élégante, mais c'est la plus courte...
*/

class MaClasseUtilisateur extends public CA1 implements I2
{

//class interne implementant i2
protected class I2InternImpl extends CA2
{
protected int do_f2(char param) { // implémentation };
}

public final float f2(int param)
{
I2InternImpl.f2();
}

protected float do_f1(int param) { // implémentation };
};

Ta solution marche effectivement, mais elle pose un gros problème : tu fais
confiance à l'utilisateur de ta bibliothèque pour implémenter (en tou cas en
partie) la fonctionnalité de pré/postconditions.
L'appel aux pre/postcondition n'est visible que dans les classes

abstraites CA1 et CA2... L'"héritant" ou l'utilisateur n'en ont pas
connaissance. L'héritant vois en plus de i1 et i2 les fonctions
do_fX() mais je ne vois pas comment il pourrait les redéfinir sans
ça...

C'est une erreur au niveau
de la séparation des responsabilités entre les différentes parties du code :
en clair, c'est un faute d'encapsulation et tu es obliger de révéler à
l'utilisateur une partie de l'implémentation de ta bibliothèque, alors qu'il
ne devrait avoir connaissance que de I1 et de I2. C'est ce genre de choses
qui rend Java difficile à utiliser pour de gros projets où l'encapsulation
est fondamentale.
Je crois qu'on en vois pas plus qu'en C++...

vclassine

01/08/2003 à 09:13

Loïc Joly wrote in message news:<bgbhas$jkk$...

Vincent wrote:
Loïc Joly wrote in message news:<bg5tvk$oj8$...

Vincent wrote:

Euh? En C++ on peut écrire une fonction redéfinissable mais pas
appelable par la classe fille?

Oui.

class A
{
private:
virtual void f();
};

f est redéfinissable, mais non appelable, ni par le client, ni par la
classe fille.

Et on n'est pas obligé de la redéfinir pour créer une classe concrète fille, non?

Si tu ajoutes =0 à la fin, si :
class A
{
private:
virtual void f() = 0;
};

Sinon au delà de la fonctionnalité syntaxique ça sert à quoi? Même si
elle était protected elle ne serait pas appelable puisque virtuelle
pure, non? Enfin disons que ça appelerait la fonction de la classe
fille, me gourge?

vclassine

01/08/2003 à 09:17

Loïc Joly wrote in message news:<bgbhik$6u7$...

Vincent wrote:
Ce que je dis c'est que les templates sont certes utiles, mais que ça
n'est pas utiliser (sauf domaine très particulier) au point que ça
constitue une différence d'importance pour le choix d'un langage par
un quasi-débutant en programmation et débutant en conception qui aura
déjà bien de la peine à utiliser correctement les concepts objets
avant que les templates débarquent dans Java...

J'estime (et ne suis pas le seul) que pour apprendre le C++, il faut
utiliser des templates AVANT que d'apprendre à construire ses propres
classes (dès qu'on parle de structures de données comme tableaux ou
listes, en fait). L'utilisation de templates n'est pas du tout
accessoire en C++ moderne.

Je ne dis pas le contraire, dans la mesure où ca éxiste il faut les
utiliser. Mais d'abord on parle là d'un niveau d'utlisation normal. Et
si il débute ne java il ne les utilisera pas (au début) mais il pourra
quand même se frotter à plein d'autres choses. Et a mon avis ça n'est
pas très grave...

Effectivement, les utilisations avancées ou la création de ses propres
templates me semblent plus destinées à quelqu'un ayant déjà une certaine
habitude.

Loïc Joly

01/08/2003 à 09:29

Vincent wrote:

Loïc Joly wrote in message news:<bgbhas$jkk$...
class A
{
private:
virtual void f() = 0;
};

Sinon au delà de la fonctionnalité syntaxique ça sert à quoi? Même si
elle était protected elle ne serait pas appelable puisque virtuelle
pure, non? Enfin disons que ça appelerait la fonction de la classe
fille, me gourge?

Et oui...

Le code suivant est valide (sauf faute de frappe ;)):

class A
{
protected:
virtual void f() = 0;
};

void A::f()
{
cout << "A::f" << endl;
}

class B : public A
{
virtual void f();
void g();
}

void B::f()
{
cout << "B::f" << endl;
}

voig B::g()
{
f();
A::f();
}

int main (void)
{
B b;
b.g();
}

--
Loïc

Julien Blanc

01/08/2003 à 10:21

Vincent wrote:

Je rappel pour ceux qui veulent répondre à la question qu'elle à été
posé par un débutant...

oui mais dans ce cas, la réponse n'est ni java ni c++, mais plutôt ADA,
au moins, il prendra de bonnes habitudes :).

--
Julien Blanc. Equipe cadp. VERIMAG. Grenoble. France.

adebaene

01/08/2003 à 12:04

(Vincent) wrote in message news:...

Ta solution marche effectivement, mais elle pose un gros problème : tu fais
confiance à l'utilisateur de ta bibliothèque pour implémenter (en tou cas en
partie) la fonctionnalité de pré/postconditions.
L'appel aux pre/postcondition n'est visible que dans les classes

abstraites CA1 et CA2... L'"héritant" ou l'utilisateur n'en ont pas
connaissance. L'héritant vois en plus de i1 et i2 les fonctions
do_fX() mais je ne vois pas comment il pourrait les redéfinir sans
ça...
Non, l'héritant voit aussi les classes ca1 et ca2, et il voit qu'il

doit hériter de l'une et aggréger l'autre en republiant son interface
à l'extérieur. C'est ça qui est anormal.

Arnaud

Java et C++

10 réponses

Veuillez sélectionner un problème