Reprise du message précédent :

rappel: je fais du VB6

A has B

ouais.
IOC jte dis, au lieu de tes lookups des années 80

C'est un classique de la conception et la règle numéro 1 de "Head first Design patterns" (qui ne fait que reprendre le GOF): "code for interface, not for implementation"

checked = exception que tu dois gérer (catcher ou throwser). ex : MalformedURLException (ce qu'elle est chiante celle là   )
unchecked = exception que tu n'es pas obligé de gérer. ex : NumberFormatException ou NullPointerException

yes, les mocks, 2e argument (je sais hein ); mais c'est parfois un peu vaseux de justifier un choix de design "pour les tests". L'histoire de l'object lourd non prévu, tu pourrais m'expliquer?

on a pas la meme notion de sémantique alors
(puisqu'aux dernieres nouvelles, tu étais un fervent partisan du FNFE)

hop, 3e argument, merci

je plussoie fortement
d'ailleurs, c'est le mot d'ordre du "Head First Design Pattern" : "dépendez d'une interface et pas d'une implémentation"
 
edit: toasted, j'y crois pas

Bah en attendant... je vois un mec qui essaie de faire du filtrage assez compliqué au niveau du principe alors qu'il ne sait même pas récupérer la luminosité de ses pixels

Pour moi c'est pas compliqué: on les gère toutes.
Quitte a gérer les plus improbables tout en haut de la pile avec un traitement tout-à-fait générique con (Java fait une gestion par défaut, qu'on peut améliorer pour le rendre un peu plus user-friendly).

en meme temps j'm'en fous j'me casse
tu veux venir à bxl?

1) mouais, je dois t'avouer que ça doit faire 3 ans que ça m'est pas arrivé. bien souvent j'extrais même plus mes interfaces à l'avance quand je suis tout seul, ça prend 10s à faire au moment où j'en ai besoin. Au boulot je fais un peu plus gaffe parce que mes collègues sont pas encore au top (ils ont du mal avec le code mouvant, et ils ont un peu tendance à sacraliser le mien au lieu de le tordre à leurs contraintes).
 
2) j'ai dit "hors des situations exceptionnelles".

C'est bien, t'as bien retiendu la leçon.  

VOUS ALLEZ ME LACHER AVEC CE FILE.EXISTS?

chuis ingé \o/

qqun peut me confirmer un truc vachement traitre, les flèches dans le Gof sont inversées par rapport à l'uml nan ?

1) les tests te poussent vers des bonnes pratiques dans ce cas.
 
2) imaginons que mon framework m'oblige à hériter d'un certaine classe pour bénéficier de la persistance, des transactions et de la sécurité (psst, pas de nom) et que je veux le faire rentrer avec un chausse-pied dans ton framework à toi qui avait prévu un machin abstrait.

 
l'expression

 
 
(bon, vous pouvez voter pour moi comme modo, j'ai assez fait mes preuves que je ne fais pas *que* foutre la merde, ici. )

Ok, ça me parait normal. C'est pour ça que la distinction checked/unchecked me paraissait douteuse.

Ben ouais, techniquement, t'as largement le niveau.

bon, ben dommage, pour une fois qu'ya une discu intéressante sur ce topic je file au pieu /o\
 
allez une derniere question pour la route : quel est le principal Design Pattern utilisés par les streams I/O de Java ?
1) Adapter
2) Decorator
3) Abstract Factory

je pensais pas à ça.  
 
bon, je vous la donne : un détecteur de cycle dans un algo en descente récursive. comme la valeur de retour de la fonction est occupée par la valeur normale de l'algo, c'est une exception qui signale la détection de cyle, et avec un catch finement placé autour de l'appel récursif, on peut donner un chemin passant par la boucle à l'utilisateur (utilisé dans mon compilo B)

2, et 1 pour reader/writer vs streams

j'ai rien compris
(mais j'ai pas lu tout, spour ça )
sinon les continuations sont implémentées à coup d'exceptions aussi

foutrement aucune idée mais en général l'archi est douteuse (avec les printStream et les bufferedBidule).
 
d'ailleur y'a quelques mois j'ai bossé sur un bug pas très drôle : monsieur fait un readLine() avant de la tronçonner à coup de indexOf et de subString(), sauf que la ligne faisait 116Mo ce jour là

heu ouais génial ...
http://today.java.net/pub/a/today/2004/02/10/ioc.html
 
 
Le type 2 qui est une horreur sans nom.
 
le type 1 et 3, ca nécessite toujours que tu instancie tes truc au départ ... donc même si tu a déplacé le problème, tu l'as toujours : il faut bien que tu instancie tes classes quelque part.  
et récupérer tes objets par des clefs, c'est pas un truc à te manger des exceptions sans pouvoir les accompagner d'un message d'erreur explicite si l'objet est pas dispo ?  
 
 
(mais ca a l'ait sympa PicoContainenr si ca fait ce que j'imagine que ca peut faire )

-- tu bosses dans quel boite ? parce que je vais un peu beaucoup postuler dans les semaines qui arrivent et vu que je suis belge ya une probabilité qu'on se croise si tu fais dans les entretiens des juniors...

2.
 
Mais c'est extèmement douteux, franchement lourd, et super chiant à utiliser

ben y'a quand meme pas mal de Decorators dans le bouzin hein
ce genre de truc ne ressemble pas trop à un Factory quand meme  

une truc d'enculé : à quoi sert l'InterruptedException dans wait et sleep ?
 
(perso, je maîtrise ce domaine que depuis 1 mois où 2, première fois où j'ai été obligé de mettre les mains dedans à fond)
 
ou encore mieux (mais c'est juste de la lecture de doc là) : la doc de wait() dit qu'on doit être synchronisé sur l'objet sur lequel on attend, et la doc de notify() dit qu'on doit être synchronisé sur l'objet sur lequel on attend, comment je peux me synchroniser sur l'objet pour le notifier si un autre thread est en train de pioncer dans son bloc synchronized ?

 
C'est la version moderne du setjmp() avant la boucle, et longjmp() quand on en "tout en base" ?

type1 c'est du lookup, c'est bidon, type2 je deteste, mais c'est ce que les springeux font :\ (c't'une secte ces mecs là )
type 3 c'est ce que j'emploie, avec pico, effectivement. et c'est pas moi qui instancie mes objects, c'est pico. normalement, dans ton code, si tu as une appli standalone, tu ne touches à pico que dans ton main (en gros, hein, tu peux avoir des utils autour), tu recup ton objet de depart et c'est parti. (voire tu laisses pico le démarrer tout seul avec une interface genre Startable)
Dans le cas d'une appli web par exemple, c't'encore plus simple, t'as par exemple tes Actions qui declarent simplement des dependences et hop, t'as juste rien à faire à part registrer tes implementations correctement dans les bons scopes...

0x90>Ben c'est des exceptions

non merci, les threads je vais faire semblant de rien

 
WNOHANG  was  not  set  and an unblocked signal or a SIGCHLD was caught.

c'est un peu léger, jeune homme.

Bon alors le monsieur a dit: tu vérifies que la sortie est pareille que l'entrée, si c'est le cas tu balourdes une exception des familles parce que ça veut dire que tu pars en récursivité "infinie". Et hop, en chopant l'exception, tu te sors élégamment du cercle infernal et tu peux même le signaler voire même retrouver à quelle profondeur t'es parti en couille.
 
C'est bien ça raynal ?

euh oui mais il parlait des InterruptedException sur wait() et notify() là