Reprise du message précédent :
kikoooooooo
 

a oui , quand même  
de toute façon c'est trop gros pour mon usage

Si j'ai bien compris, si je veux une système amélioré d'une usine logiciel, faut que je me la face moi même ?  
Pourtant c'est un processus répandu aujourd'hui...

 
Nous ne te voulons aucun mal, approche et dis nous dans note langue ce qui t'inquiète.

 
non, il te faut une usine logicielle pour faire des usines logicielles
 
je te conseille eclipse EGF :

 
Danke !    
 
 
Trop bon. Merci.

 
C'quand même bien pratique karmadecay pour quand on arrive le matin...
   http://karmadecay.com/i.imgur.com/FRdw2.jpg

ho waw.

 
 
Je me suis pécho une erruer pour nom de fichier trop long à l'extraction de l'archive.

Faut payer une taxe carbone, pour utiliser ça, non ?

 
drole je fais suivre

Karma Decay, ce nom

SSD AUJOURD'HUI  

question très basique de conception OO / C++:
 
j'ai une classe Foo qui contient facultativement un attribute par agrégation bar une référence vers Bar.
 
traduit en C++ ça donne par exemple ça:
 

 
comme Bar est facultatif je dois blinder mon code de if(bar){ ... }
 
l'autre solution,  à la place de remplir bar par 0 (null pointer..), c'est de remplir bar par une instance d'une classe dérivée de Bar (DummyBar) qui ne fait rien.
Dans ce cas je n'ai pas besoin de remplir mon code de if(bar){ ... }
 
J'ai l'impression que la méthode "null pointer" est beaucoup plus utilisée que la version "dummy instance". Pourtant la version "dummy instance" me parait sympa.
Je dois utiliser quoi comme façon de faire ?
 
(edit: apparemment ça s'appellerait le "Null Object pattern" )

Ba perso j'ai jamais trop joué avec ça, mais effectivement j'aurais émis la même critique que celle dans Wikipedia : gaffe aux erreurs qui vont être plus difficiles à détecter.
Sinon ba je sais pas, ça me paraît pas spécialement con. L'intérêt, c'est juste d'éviter les if(bar) dans ton code ou y a autre chose ?

Null object

Je pense que le code doit être prévu pour que les objets nuls ne soient pas considérés comme des valeurs particulières mais se comportent comme les autres objets. Le code devrait être à la fois plus clair, plus élégant et plus performant. Je l'ai déjà fait, mais je ne sais pas si c'est toujours faisable, par contre.

Plus performant, je sais pas. Dans un cas t'es des if() genre 1 fois par méthode, dans l'autre t'as des appels à une méthode vide avec parfois des return si besoin, sans compter le coût en mémoire qui sera négligeable de toute façon. En plus, si tu comptes sur le retour de la méthode vide en question, faut gérer les retours null donc rebelote.

Normalement on doit initialiser toute les variables.

Effectivement.

Il ne faut surtout pas que les méthodes du null object puissent retourner null, sinon ça ne sert à rien, ça ne fait que déplacer le problème.
Il faut que les résultats de toutes les méthodes du null object puissent être traitées sans cas particulier. C'est une restriction importante pour déterminer si le null object est utile ou pas.

Au pire (mais c'est un peu dégueu), elles lèveraient une exception ?

 
Je trouve que le Null Object Pattern est beaucoup plus intéressant. Si jamais le null object en question est un cas d'erreur, il suffit que l'objet en question lève une exception dès qu'on appelle une de ses méthodes. De cette façon, tu n'as pas à blinder le code utilisateur (de l'objet) de tests.
 
La question des performances à ce stade me semble complètement non pertinent. En plus je suspecte que des appels à des méthodes vides puissent être optimisés par le compilateur, donc on s'en fout un peu.

Enfin avec des methodes virtuelles, meme vide, ca va etre dur d'optimiser leur appel.

Certaines méthodes vont devoir être potentiellement passées en méthodes virtuelles si elles ne l'étaient pas juste pour supporter le Null Object. Ca ne m'étonnerait pas que ce soit une des choses qui rebutent les personnes qui pourraient l'implémenter

Comment tu brosse.  

Ba tes exceptions, tu vas vouloir les gérer

Oui et non. C'est pas spécialement pertinent pour ce qui est du design pur, mais point de vue exécution, entre un if(machin != null) et un throw new Exception, tu te fais défoncer (en Java et C# en tout cas).
Donc OK pour pas en parler dans la discussion initiale, mais je trouve que c'est un point important si le code se situe dans une boucle où la question de perfs se pose.

 
Bah ouais mais pas forcément au même endroit. "return null" c'est un code contaminant, quand t'en as à un certain niveau, tu finis par en avoir à tous les niveaux.
Et tu te tapes des machins du genre :  

 
L'exception tu la gères au niveau où c'est pertinent uniquement.
 

 
Une exception c'est exactement comme son nom l'indique un cas ... d'exception. Donc dans la plupart des cas, la question de leur impact sur les performances n'est pas pertinente.

Est-ce qu'un Foo sans Bar est dans un état légitime ou est-ce transitoire ?
Pourquoi bar n'est pas const ?

 
BUMP

Qualifier les indiens de ressources est un peu fort mais de la a parler d'outil quand meme

business ... intelligence .... PHP
 
trouvez l'intrus

OH HAI

tu trouves aussi

j'ai fait des progres, j'ai pas été etronner dans le topic

non mais déjà BI et personne inexpérimenté techniquement ET dans le domaine métier

Nan mais c'est concon la BI, hein.
On te demande juste d'imaginer qu'un cube OLAP est possible. Si déjà tu sais le faire sous Excel, c'est bon, t'es un expert...
(à croire que Business Objects n'existe pas depuis, pfiouu, au moins 5 ans maintenant)

#firstworldproblem
pour a peu prêt le même tarif , qu'est ce qui va mieux pour le dev :
je mets un second 24" à côté de mon dell 2406
je revends le 24" et me prends un 27" en 2560*1440
je pose deux 17" en mode portrait sur les côtés du 24"
 

2ème 24 pouces.

Bon, ben devoxx c'est bien pour le moment.

https://www.facebook.com/photo.php? [...] =1&theater

barbapapa

Mais quel temps de merde