Pourquoi mettre deux constructeurs

**titeufdev** · 29/03/2011, 01h57

Bonsoir tout le monde j été en train de lire un code et j ai pas pu comprendre pourquoi il y a deux constructeur qui contient le même vecteur de LigneVente ?
ainsi que la boucle for dans la méthode CalculTotale, c est la premier fois que je vois une boucle pareille , est ce que quelqu'un peut m expliquer comment il fonctionne?
cordialement

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
 
 
 
 
package ma.ofppt.ntic2.caisse.bo;
 
import java.util.Date;
import java.util.Vector;
 
 
public class Vente {
    private int id_v;
    private Date datev;
    private Caisse caisse;
    private Vector<LigneVente> lvs;
 
 
    public Vente(){
        this.lvs=new Vector<LigneVente>();
 
    }
 
    public Vente( Caisse caisse) {
 
        this.caisse = caisse;
        this.lvs=new Vector<LigneVente>();
    }
 
 
    public LigneVente CreateLigneVente(Article a,int qte){
        LigneVente lv=new LigneVente(qte, a, this);
        lvs.add(lv);
        return (lv);
    }
 
 
    public double CalculTotal(){
        double total=0;
        for(LigneVente lv:lvs){
            total=lv.calculSousTotal()+total;
        }
        return total;
    }
 
    public Caisse getCaisse() {
        return caisse;
    }
 
    public void setCaisse(Caisse caisse) {
        this.caisse = caisse;
    }
 
    public Date getDatev() {
        return datev;
    }
 
    public void setDatev(Date datev) {
        this.datev = datev;
    }
 
    public int getId_v() {
        return id_v;
    }
 
    public void setId_v(int id_v) {
        this.id_v = id_v;
    }
 
    public Vector<LigneVente> getLvs() {
        return lvs;
    }
 
    public void setLvs(Vector<LigneVente> lvs) {
        this.lvs = lvs;
    }
 
 
 
 
 
}

**Logan Mauzaize** · 29/03/2011, 08h43

Il y a deux constructeurs car l'un initialise l'attribut "caisse" et pas l'autre.

La boucle "for-each" est une syntaxe qui a été introduit en Java 1.5. Il s'agit d'itérer sur un ensemble de valeur soit via un tableau, soit via un objet qui implémente l'interface Iterable.
Le compilateur se charge de transformer le "for-each" en une boucle "while" utilisant la méthode "iterator()"

Ex:

Code :

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

1
2
3
4
5
6
 
List<FooBar> myFoobarList = .....
for (FooBar foobar : myFoobarList)
{
   // ...
}

devient

Code :

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

1
2
3
4
5
6
7
8
9
10
 
List<FooBar> myFoobarList = .....
{
   Iterator<FooBar> $anonymousIterator = myFoobarList;
   while ($anonymousIterator.hasNext())
   {
     FooBar foobar = $anonymousIterator.next();
     // ...
   }
}

Très pratique pour itérer sur une collection, cependant il faut faire attention à ce que ton instance ne soit pas null.

**RomG7** · 29/03/2011, 08h58

Bonjour,
Lors de la construction d'un objet de type "Vente", il doit falloir obligatoirement construire une liste de type "LigneVente" pour répondre au modèle de la base de données (Pour une date et une caisse, il y aura un ou plusieurs articles, ...)

Que l'on passe par un constructeur ou par un autre, il est impératif de construire la liste de type "LigneVente".

On pourrait aussi construire directement cette liste dans la déclaration de la propriété :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
public class Vente {
    private int id_v;
    private Date datev;
    private Caisse caisse;
    private Vector<LigneVente> lvs = new Vector<LigneVente>();
 
 
    public Vente(){
        this.caisse = null;
    }
 
    public Vente( Caisse caisse) {
        this.caisse = caisse;
    }

**javaNavCha** · 29/03/2011, 09h51

Bonjour
Il y a une différence entre ces deux constructeurs

Code :

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

1
2
3
4
5
6
7
8
9
10
public Vente(){
        this.lvs=new Vector<LigneVente>();
    
    }
 
    public Vente( Caisse caisse) {
 
        this.caisse = caisse;
        this.lvs=new Vector<LigneVente>();
    }

Donc la classe Vente peut être appelée en deux façons.

**professeur shadoko** · 29/03/2011, 11h32

je voudrais pas faire ma mauvaise tête mais ce code a un sérieux problème avec l'encapsulation:
il y a une raison pour avoir un "set" sur l'id qui est manifestement la clef de l'objet et qui est immuable?
il y a une raison pour exposer le Vector qui est manifestement géré par le code courant?

(il peut y avoir une raison ... mais est ce volontaire?)

**Logan Mauzaize** · 29/03/2011, 11h38

Envoyé par professeur shadoko

il y a une raison pour avoir un "set" sur l'id qui est manifestement la clef de l'objet et qui est immuable?

Oui si tu utilises une API reposant sur la réflexion/commons-bean (Struts, Hibernate, etc.)

De plus c'est un code "académique" (d'après le nom du package et OFPPT

**professeur shadoko** · 29/03/2011, 14h12

Envoyé par Nemek

De plus c'est un code "académique" (d'après le nom du package et OFPPT

c'est bien ce qui m'inquiète: sous prétexte qu'on a un cas bien précis dans lequel c'est utilisé on généralise quitte à violer (inconsciement?) les principes de l'encapsulation ....
(ce code de passera pas à l'analyse statique d'outils comme findbugs)
C'est l'inverse qui devrait être vrai: les principes d'abord les exceptions circonstancielles après.

**Logan Mauzaize** · 29/03/2011, 14h58

Tu pourras pas reprocher à un "académicien" de ne pas avoir un code parfait. De plus c'est même pas lui qui a pondu le code ...

Je pense pas que findbugs te crache dessus parce que t'as une méthode "setId". D'autant plus que je vois mal comment tu vas renseigner ton "id" si t'as pas de setter ... Que ce soit Hibernate / JDBC / Serialization / etc.

**professeur shadoko** · 29/03/2011, 17h33

Envoyé par Nemek

Je pense pas que findbugs te crache dessus parce que t'as une méthode "setId". D'autant plus que je vois mal comment tu vas renseigner ton "id" si t'as pas de setter ... Que ce soit Hibernate / JDBC / Serialization / etc.

pour findbugs je pensais au get du Vector qui se fera jeter ...
pourquoi JDBC, serialization seraient-ils concernés par ce cas particulier? (à part le cas tordu d'une super-classe non serialisable). Un id immuable fixé par tous les constructeurs me semble le cas général. Idem le Vector ne devrait jamais être exposé (c'est un membre qui assure le fonctionnement interne de l'objet).

**Logan Mauzaize** · 29/03/2011, 17h41

Parce qu'au moment de créer l'instance et de la remplir tu ne connais pas l'id, il faut donc le setter ultérieurement ?

La serialization "impose"/"recommande tres très très" fortement d'avoir un constructeur par défaut... Dans ce cas comment changer l'id ?

**professeur shadoko** · 30/03/2011, 09h51

Envoyé par Nemek

La serialization "impose"/"recommande tres très très" fortement d'avoir un constructeur par défaut... Dans ce cas comment changer l'id ?

ah bon? pourquoi? une référence dans le document de spec?
(.... je croyais que ceci n'était vrai que pour la première super-classe dans la hierarchie qui ne soit pas serializable)

**Logan Mauzaize** · 30/03/2011, 10h54

Oups t'as raison pour la sérialization

En revanche ca change pas le problème de l'id généré "post" création de l'instance.

**professeur shadoko** · 30/03/2011, 12h06

en fait cette histoire de constructeur par défaut relève de la légende urbaine.
Il y a relativement peu de situation ou ça s'impose :
- bean graphique en phase de mise en oeuvre par un outil de mise en page
(mais on peut détecter la situation et provoquer une erreur en cas d'utilisation illicite)
- classe service (exemple classe utilisée par ServiceLoader)

pour la serialisation il n'y a aucun problème et en fait il ne devrait pas même y en avoir pour des remontées de données depuis une BDD (sauf que pas mal d'outil mal conçus -j'ose le dire- finissent pas l'imposer).
Le problème est que du coup on casse l'encapsulation en permettant la construction d'objets "illégaux" au regard des contraintes métier : on a potentiellement des objets dont des variables membres obligatoires ne sont pas présentes -je ne développe pas ici le cas particulier des constructions en évaluation "paresseuse"-)

l'autre point est qu'il ne devrait absolument pas y avoir de "set":
- pour des membres immuables
- pour des membres dont la modification relève de contraintes gérées par la classe (exemple: le solde d'un compte en banque)
- pour des membres qui relèvent plus généralement du fonctionnement interne (Vector dans l'exemple)

il ne devrait pas y avoir de "get" dans certains cas (ici Vector ou alors on fournit une copie non-modifiable)
Il suffit de regarder les classes de base de Java pour voir que ces principes sont utilisés!

d'où mon message de base: il ne faut pas que des procédures particulières utilisées uniquement dans des cas précis deviennent des "règles" qui cassent l'encapsulation. Si on se débrouille bien on gère des objets particuliers dans ces situations et au final on passe la main à de vrais objets métiers.

**Logan Mauzaize** · 30/03/2011, 12h21

Moi ce qui me choque c'est de mettre trop de contraintes sur les "bean", d'ailleurs j'ai retrouvé la règle d'or du constructeur par défaut (les "bean" doivent avoir un constructeur par défaut ce que j'avais confondu avec la sérialization)

Si je suis ta logique tu n'aurais pas de setter pour chaque propriété mais une macro fonction setter à laquelle tu passerai toute une sorte de paramètres que tu validerais ensuite modifierait l'ensemble des propriétés impactées de ton objet. De toute manière, ton objet aurait tout de même un état transitoire dans lequel il est illégal ... Il n'y a pas de transaction sur les instructions Java ...

Est-ce que la règle ne devient pas caduque si on n'utilise pas la sérialisation pour transférer des états (ex: CORBA, WS)

Un solde peut être négatif, il n'y a que le contexte qui définit la validité d'un solde.

Pour le Vector (:beurk: vive les List), je suis plutôt d'accord mais ca oblige parfois à soit recopier les valeurs dans une nouvelle List, soit créer un Wrapper ... J'accepte une méthode getFils() : List si elle me fait gagner en utilisation de ma classe.

**professeur shadoko** · 30/03/2011, 12h53

Envoyé par Nemek

Moi ce qui me choque c'est de mettre trop de contraintes sur les "bean", d'ailleurs j'ai retrouvé la règle d'or du constructeur par défaut (les "bean" doivent avoir un constructeur par défaut ce que j'avais confondu avec la sérialization)

pas si d'or que ça on peut faire un bean sans constructeur sans paramètre (mais il faut un peu torturer: exemple XMLEncoder/decoder). le problème de base c'est que les premiers beans ont été conçus pour le problème particulier des éditeurs graphiques et qu'on a retranscrit ces règles de designtime dans des contextes de runtime pour lesquelles ces règles ne s'imposent nullement.

Si je suis ta logique tu n'aurais pas de setter pour chaque propriété mais une macro fonction setter à laquelle tu passerai toute une sorte de paramètres que tu validerais ensuite modifierait l'ensemble des propriétés impactées de ton objet. De toute manière, ton objet aurait tout de même un état transitoire dans lequel il est illégal ... Il n'y a pas de transaction sur les instructions Java ...

j'ai pas compris la remarque (j'ai faim)... de toute façon les classes standard de java n'appliquent pas du tout ces set/get systématiques ... et il y a de très bonnes raisons pour cela.

Est-ce que la règle ne devient pas caduque si on n'utilise pas la sérialisation pour transférer des états (ex: CORBA, WS)

se discute mais on pourrait l'éviter. (2 cas de figure: le mécanisme de la serialisation ou on récupère les données puis on appelle un constructeur appropriéi sur l'objet métier -soit directment soit indirectement-).

Un solde peut être négatif, il n'y a que le contexte qui définit la validité d'un solde.

donc pas de setSolde: ça casse l'encapsulation.

**Logan Mauzaize** · 30/03/2011, 13h55

Envoyé par professeur shadoko

pas si d'or que ça on peut faire un bean sans constructeur sans paramètre (mais il faut un peu torturer: exemple XMLEncoder/decoder).

Un bean sans constructeur, j'appelle ça un bean avec un constructeur par défaut

Envoyé par professeur shadoko

le problème de base c'est que les premiers beans ont été conçus pour le problème particulier des éditeurs graphiques et qu'on a retranscrit ces règles de designtime dans des contextes de runtime pour lesquelles ces règles ne s'imposent nullement.

Une règle qui me semble justifiée pour manipuler correctement/simplement/facilement des objets qui ne sont porteur que de données.
En terme codetime/runtime, il faut admettre qu'un objet a un état transitoire dans lequel il n'est pas valide (à un moment ou un autre), donc à un moment ou un autre tes contraintes sont violées. Tu cherches à le minimiser temporellement cet état au runtime mais finalement as-tu minimiser temporellement le designtime/codetime/maintenancetime pour un principe ?

Envoyé par professeur shadoko

j'ai pas compris la remarque (j'ai faim)... de toute façon les classes standard de java n'appliquent pas du tout ces set/get systématiques ... et il y a de très bonnes raisons pour cela.

Je suis ok qu'il n'est pas nécessaire de faire des set/get systématiques surtout s'il y a des contraintes techniques et/ou comme tu dis des problèmes d'encapsulation (on n'expose pas toute la mécanique de la classe).
Cependant ce principe ne doit pas être systématique pour toute classe (notamment les beans qui à mon sens sont la pour porter des données)

Quand je parle de macro setter c'est genre une méthode d'un bean qui prendrait en paramètre tout un tas d'entrée (ex: HttpServletRequest) pour initialiser/modifier ton objet.
Dans un premier temps il faudrait extraire les informations qui intéressent ton objet, puis vérifier que l'état actuel et cible (état après modification) soient cohérent et enfin modifier les propriétés de l'objet.
Je trouve ça tordu car ca donne la responsabilité au bean l'extraction des informations qui le concernent ou alors il faut sans cesse construire des entrées dans le seul but de satisfaire un principe.
Si une erreur (Throwable) survient durant la modification, tes super check n'auront servi à rien car ton objet dans un état transitoire (et invalide avec ceux-ci).

Envoyé par professeur shadoko

se discute mais on pourrait l'éviter. (2 cas de figure: le mécanisme de la serialisation ou on récupère les données puis on appelle un constructeur appropriéi sur l'objet métier -soit directment soit indirectement-).

Ca me paraît créer beaucoup de fabrique...

Envoyé par professeur shadoko

donc pas de setSolde: ça casse l'encapsulation.

Tu créées un nouveau compte à chaque opération ?

**professeur shadoko** · 30/03/2011, 14h22

Envoyé par Nemek

Un bean sans constructeur, j'appelle ça un bean avec un constructeur par défaut

la phrase est : "un bean sans constructeur sans paramètres".
donc constructeur avec paramètre. oui on peut faire des beans avec uniquement des constructeurs dotés de paramètres.

. Tu cherches à le minimiser temporellement cet état au runtime mais finalement as-tu minimiser temporellement le designtime/codetime/maintenancetime pour un principe ?

c'est pluto l'inverse: on met en péril la logique applicative en fonction de procédures liées à un état très particulier (et , en plus, évitable dans la grande majorité des cas).

Tu créées un nouveau compte à chaque opération ?

sachant que le champ solde est modifié par N méthodes: dépot, retrait, fraisBancaires, etc. avec chacune sa logique, ses controles ... on fait quoi avec setSolde ? Ce ne peut être un service "metier" et sa présence est un vrai danger pour la logique de l'application. Quand l'objet est construit/reconstitué on donne un solde de départ par le constructeur mais après il ne peut y avoir d'opération setSolde.
Encore une fois pourquoi mettre en avant des principes reservés à des situations particulières et qui ne sont pas mis en oeuvre dans les codes de Java lui-même?

**professeur shadoko** · 30/03/2011, 14h36

en relisant vos arguments je crois avoir compris quelque chose donc question est ce que l'objet MasqueSaisiePersonne qui permet d'enregistrer/véhiculer les résultats d'une saisie d'information est une Personne (objet métier)?

**Logan Mauzaize** · 30/03/2011, 14h47

Envoyé par professeur shadoko

la phrase est : "un bean sans constructeur sans paramètres".
donc constructeur avec paramètre. oui on peut faire des beans avec uniquement des constructeurs dotés de paramètres.

Ok j'avais pas compris ^_^ Heureusement que c'est possible ! Mais possible ne veut pas dire obligatoire.

Envoyé par professeur shadoko

c'est pluto l'inverse: on met en péril la logique applicative en fonction de procédures liées à un état très particulier (et , en plus, évitable dans la grande majorité des cas).

Ca ne change rien à la logique applicative si t'as fait une conception.
Derrière "évitable", je sens la mise en place de tout un mini-système pour gérer un principe, donc du temps en conception/codage/maintenance/évolution

Envoyé par professeur shadoko

sachant que le champ solde est modifié par N méthodes: dépot, retrait, fraisBancaires, etc. avec chacune sa logique, ses controles ... on fait quoi avec setSolde ? Ce ne peut être un service "metier" et sa présence est un vrai danger pour la logique de l'application. Quand l'objet est construit/reconstitué on donne un solde de départ par le constructeur mais après il ne peut y avoir d'opération setSolde.
Encore une fois pourquoi mettre en avant des principes reservés à des situations particulières et qui ne sont pas mis en oeuvre dans les codes de Java lui-même?

Ton objet est donc final sans possibilité d'évoluer, tu dois donc ajouter une méthode pour chaque nouvelle règle, voir à chaque modification de règles. Exemple les retraits d'un compte jeune est plafonnée à 700€/semaine, 1500€/mois, sauf dérogation, chaque dérogation permet d'aller jusqu'à deux fois le plafond de départ.

Visiblement, tu opposes POJO et EJB. Alors qu'on peut très bien utiliser les deux. Y compris dans un même système.

**Logan Mauzaize** · 30/03/2011, 14h55

Envoyé par professeur shadoko

en relisant vos arguments je crois avoir compris quelque chose donc question est ce que l'objet MasqueSaisiePersonne qui permet d'enregistrer/véhiculer les résultats d'une saisie d'information est une Personne (objet métier)?

Je ne "philosophe" pas sur du code "académique", je le fais déjà peu sur des applications en production. Ca n'a pas d'interêt autre que "la branlette intellectuelle" (cf. un livre que je lis en ce moment). Ca revient à demander à un artiste si son esquisse est une oeuvre d'art ... Non et ca serait une perte de temps ! Fais tu une conception poussée/détaillée de tes maquettes ?

En revanche "philosopher" sur ce qui devrait être dans l'état de l'art, ok. Car ca me fait progresser ! Bon être honnête, je suis d'accord sur certains de tes principes en matière d'idéal. Cependant je trouve ça contre-productif. Et entre le "conceptuel" et le "pragmatisme", je choisis chaque jour ce qui me fais gagner du temps.

Pourquoi mettre deux constructeurs

avec Java

Discussions similaires

Partager

Partager