[Débat] Technologie .NET vs JAVA

**davcha** · 06/06/2011, 18h12

Envoyé par B.AF

Moi je ne comprends pas pourquoi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public int prop
{
get{return _prop;}
set {_prop=value;}
}

est mieux que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
public int getProp
{
return _prop;
}

public int setProp(int i)
{
return _prop;
}

Si quelqu'un veut m'expliquer, je suis open, mais je comprends toujours pas....
Et là où je trouve ça encore mieux, c'est qu'aujourd'hui la "mode" semble être les interfaces fluides...Qui rendent bien souvent inutiles la propriété en C#...
Mais bon...

Tu préfères quoi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
truc.setProp(machin.getProp());
truc.Prop = machin.Prop;

Tu me diras que c'est juste du sucre syntaxique... Je te répondrais que oui, mais qu'est-ce qui n'en est pas ?

**_skip** · 06/06/2011, 19h15

Ce qui me dérange avec les propriétés en java, c'est que lorsque je crée de simples POJO destinés à servir par exemple de parameter objects, le standard "m'oblige" à demander à mon IDE de générer 50 lignes de bouse pour polluer ma classe.

Et si je manque de bol, ces méthodes faisant partie d'une API publique, je suis obligé de documenter ces bêtises à double lorsque j'ai des choses intéressantes à raconter sur la propriété, ce qui arrive tout de même malheureusement assez souvent.

Bien que je m'y conforme, j'ai toujours trouvé assez débile de devoir générer des get/set partout. Je triche en utilisant lombok lorsque c'est possible. C'est un point que je trouve mieux réussi dans scala dont la syntaxe autorise de laisser visible un membre public et de le passer plus tard en propriété intelligente sans casser le code à la compilation.
Ca évite d'écrire de la plomberie tout en préservant cette (soi-disant) encapsulation si chère aux yeux du monde.

**B.AF** · 06/06/2011, 22h34

Ok c'est vrai que l'autoproperty c'est top pour les DTO, et pour les copies de propriété c'est plus clean.

En même temps comme j'ai toujours aimé les interfaces fluides et que j'utilise cela énormément pour coder ainsi que du pattern factory (mécaniquement), j'avoue que même en C# j'utilise des méthodes pour setter

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
var _instance =NonsenseObject.CreateNewEmpty()
                      .MakeSense(true)
                      .BuildChaosOrganiser(false)
                      .FinalySetIteration(3000)
                      .BuildObject();

donc pour moi c parfois plus verbeux en Java, mais pour l'utilisateur de l'API, généralement ça ne change rien.
Sauf effectivement les lambda si j'utilise une convention de paramètres dans un singleton.

**Médinoc** · 07/06/2011, 07h00

En C# 3.0, tu peux initialiser avec les appels de propriétés:

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

MaClasse obj = new MaClasse() { Prop=toto, Prop2=tata };

**unknow0** · 07/06/2011, 10h17

Envoyé par Médinoc

En C# 3.0, tu peux initialiser avec les appels de propriétés:

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

MaClasse obj = new MaClasse() { Prop=toto, Prop2=tata };

et c'est quoi la diff avec:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaClasse obj = new MaClasse(toto, tata);

vu que dans tous les cas faut allez voir la doc pour, dans ton cas, savoir le nom de proprieter et dans le cas "normal" l'ordre des parametre.

**Nathanael Marchand** · 07/06/2011, 11h00

Envoyé par unknow0

et c'est quoi la diff avec:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaClasse obj = new MaClasse(toto, tata);

vu que dans tous les cas faut allez voir la doc pour, dans ton cas, savoir le nom de proprieter et dans le cas "normal" l'ordre des parametre.

La différence c'est que dans le cas des propriétés, tu n'es pas obligé de créer un grand nombre de constructeurs avec toutes les surcharges possibles pour initialiser.

**davcha** · 07/06/2011, 11h16

En même temps, avec .NET 4, tu peux faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
class Truc{
  public Truc(int a=0, int b=2, int c=4, string machin="bidule"){...}
}

new Truc(b:3, machin:"trucmuche");

**Nathanael Marchand** · 07/06/2011, 11h59

Envoyé par davcha

En même temps, avec .NET 4, tu peux faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
class Truc{
  public Truc(int a=0, int b=2, int c=4, string machin="bidule"){...}
}

new Truc(b:3, machin:"trucmuche");

Oui sauf que pour le coup, je déteste les paramètres par défaut

**Bluedeep** · 07/06/2011, 12h02

Envoyé par Nathanael Marchand

Oui sauf que pour le coup, je déteste les paramètres par défaut

Il te dit pas d'aimer ça, il dit qu'on peut le faire

**B.AF** · 07/06/2011, 12h20

conceptuellement, je ne comprends pas comment on peut penser objet sans penser ses constructeurs.

Au contraire, toutes les possibilités de création d'un objet devrait être connues et maitrisées. C'est d'ailleurs une des problèmatiques qu'adresse l'ioc.

La différence c'est que dans le cas des propriétés, tu n'es pas obligé de créer un grand nombre de constructeurs avec toutes les surcharges possibles pour initialiser.

Donc tu ne peux jamais tester correctement ton objet, vu que tu ne sais pas si le testeur ou même le code du test l'instancient correctement.

Et pour le problème de construction, il y a justement les concepts de fabriques qui sont intéressants.

**davcha** · 07/06/2011, 16h23

Envoyé par B.AF

Donc tu ne peux jamais tester correctement ton objet, vu que tu ne sais pas si le testeur ou même le code du test l'instancient correctement.

Ca aussi c'est un argument contre les "mauvais programmeurs".

En pratique, tu vas pas t'amuser à instancier un objet à coup de memberinit sur des membres privés.
Tu vas pas non plus t'amuser à instancier un objet manuellement, en dehors de son constructeur...

Quand tu fais du memberinit, tu appelles un constructeur, et ensuite tu initialises des propriétés. En gros, ça te permet de faire ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Truc truc = new Truc();
truc.setBidule(bidule);
Machin m = new Machin(chose);
m.setFoo(bar);
m.setPlop(ploup);
m.setBidule(truc);

Sauf que c'est légèrement plus lisible :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
var m = new Machin(chose){
  Foo = bar,
  Plop = ploup,
  Bidule = new Truc { Bidule = bidule }
};

Après, c'est une question de goût, mais y'a aucune différence entre les deux.

Je rappelle que les propriétés en C# sont traduites en getter/setter en CIL, que les divers "sucres syntaxiques" autour des constructeurs ou des appels de méthodes avec paramètre par défaut sont aussi convertis en l'équivalent qui va bien...

Bref, y'a aucune histoire de rupture d'encapsulation derrière tout ça.

**unknow0** · 07/06/2011, 16h31

Envoyé par Nathanael Marchand

La différence c'est que dans le cas des propriétés, tu n'es pas obligé de créer un grand nombre de constructeurs avec toutes les surcharges possibles pour initialiser.

humm pas faut en effet.

mais par contre sa pose d'autre probleme, tu peu definir nb'importe quelle attribut de cette facon? (genre les priver/protected)

l'avantage d'ogliger de passer par un constructeur c'est de garentire l'integriter de la class.

**Médinoc** · 07/06/2011, 16h37

L'initialisation ne marche que sur les publics, bien sûr.

Et le problème du "Ouin il faut utiliser que les constructeurs" est tout aussi présent en Java.

**B.AF** · 08/06/2011, 09h50

Envoyé par davcha

Ca aussi c'est un argument contre les "mauvais programmeurs".

...

Bref, y'a aucune histoire de rupture d'encapsulation derrière tout ça.

Ben si quelque part si tu dois attacher une propriété non initialisée à la construction, la plupart du temps c'est une composition.

Par soucis de maintenance, j'utiliserai une méthode avec une signature explicite.

Je comprends bien que ce soit lpus lisible ou plus simple, ça ne veut pas pour autant dire que c'est bien ou mieux.

**davcha** · 08/06/2011, 10h41

Genre, tu feras truc.setMachin(..) ?

Comme dit plus haut, y'a pas de différence entre propriété et getters/setters. C'est que du sucre syntaxique.
Rien t'empêche de mettre une grosse méthode derrière ton getter ou setter de propriété...

En fait, la seule différence entre les deux (Java et .NET, ici), c'est qu'en Java, tu n'as pas ce sucre syntaxique pour les propriétés.

Avoir un choix syntaxique (plus lisible qui plus est) n'est pas une bonne chose parce que celui-ci induit des différences fonctionnelles (qui n'existent pas) ?..

**Bluedeep** · 08/06/2011, 13h10

Envoyé par davcha

En fait, la seule différence entre les deux (Java et .NET, ici), c'est qu'en Java, tu n'as pas ce sucre syntaxique pour les propriétés.

C'est oublier un peu vite que cela a une influence sur la serialisation (pour la serialsisation XML par défaut entre autre).

Des getter/setter en méthode sont ignorés par le mécanisme de sérialisation.

**davcha** · 08/06/2011, 13h23

Comme si y'avait pas d'attribut qui empêche la sérialisation...

**Bluedeep** · 08/06/2011, 13h36

Envoyé par davcha

Comme si y'avait pas d'attribut qui empêche la sérialisation...

Ben si, justement; en revanche, il n'y a pas d'attributs qui précisent qu'une paire de méthode getter/setter doit être utilisée pour la sérialisation.