Reprise du message précédent :
tu veux dire que cette règle te parait inutile ? Je ne prend pas position pour l'instant... t'as un exemple qui la contredirait ?

ben je sais pas j'ai des des classes qui servent juste à faire du typage de groupe, qu'on me passe pas des carottes à la place des choux. Je les marque abstraites pour que ça se voit.

non mais un exemple concret hein, pas une image de prof.
la question que je me pose c'est que si t'as une classe abstraite qui ne laisse rien à définir aux sous-classes, je vois pas l'interet de pas en faire LA classe concrete et je vois pas ce que viennent foutrent les sous classes, mais bon, j'ai plus toute ma tête.

'fais chier, j'ai déjà viré ce code.
 
y'avait :
 
Type
abstract LiteralType extends Type
VariableType extends Type (concret)
BaseType extends LiteralType  
Powerset extends LiteralType
 
(et un troisième mais on s'en fout)
 
 
 
Bon, y'avait Type qui contient du code, notament, un double dispatching sur ensureEquals(Type other) , donc ensureEquals(VariableType other), ensureEquals(BaseType other), ensureEquals(Powerset other).
 
Quand tu fais t1.ensureEquals(t2) et soit ça fait rien, soit ça rapporte une erreur (en réalité en-dessous, ça peut unifier l'un des deux types s'il est indéterminé). Par dans type, toutes les ensureEquals() rapportent une erreur, donc si tu override pas, par défaut 2 types sont incompatibles (parcequ'il y a plus de types structurellement incompatibles entre eux que de compatibles).
 
sauf que dans VariableType, à un moment, j'avais besoin d'affecter un Type qui n'était pas un VariableType donc un LiteralType.
 
Donc j'ai LiteralType qui contient rien, mais qui est utilisé pour regrouper des classes, y'a du code concret au-dessus (par défaut une comparaison de type échoue) et en dessous (par exemple BaseType impléme ensureEquals(BaseType  other) pour faire une vraie comparaison), mais pas de méthodes abstraites propres.

bon euh désolé, j'essaierai de relire une autre fois, là j'y arrive plus :\

 
je crois que j'ai trouvé la technique ultime pour pas trop oublier certains todos ....

ils font chier en java, y'a pas d'implémentation compacte des collections, pour quand on a très peu d'éléments.
 
Je vais utiliser une HashMap alors qu'au max je vais avoir 5 éléments dedans

une List avec une methode helper qui va boucler dans le tas pour retrouver le bon objet ?

-- > y'a un truc genre contains(Object) et remover(Object) je crois sur les listes
 
 
bon, je suis repassé à eclipse, le bordel SVN est payant et à part dans idea, je vais pas présenter une facture de 4000 balles par personne dans une startup.
 
 
fais chier, parce que eclipse manque de refactoring tout cons (genre convert class to interface)

tiens, cadeau :  
http://www.thedailywtf.com/forums/51784/ShowPost.aspx

en fait non, y'a bien SVN dans intellij de base /o\

J'ai tendance à utiliser une interface (sans méthode par exemple) dans ce genre de situation.

phna < non parce que la superclasse possédait déjà du code.

et philosophiquement parlant je trouve que classe abstraite != interface

Ce n'est pas une question de philosophie mais plutôt un problême de cas d'utilisation.
 
Sinon je ne parle pas le "pmd syntaxe" mais à priori la regle "merde" dans le cas valide ou une classe abstraite hérite d'une autre classe abstraite en implémentant qu'une partie des méthodes abstraites de la classe parent.

C'est chelou ça, on peut avoir des méthode publiques dans une classe publique qui retournent un type "package-private". Quand on appelle des méthodes sur le résultat, ça compile pas.

bon, les cons, j'ai une question technique :
 
j'ai des objets (un collecteur de messages d'erreur, le gestionnaire de type, le gestionnaire du token courant etc.) qui doivent être accédés depuis une cinquantaine de classes (bon, disons 30 chaques) je me demande si je dois faire un piont d'accès par un singleton (style service locator) ou si je me fais *vraiment* chier à faire passer les bordels par les constructeurs ? ou alors il y a une autre technique que j'ai ratée ?

j'imagine que tu connais ma réponse
mtnt, si t'as bcp de trucs à passer, y'a ptet matière à encapsulation ?
 
.. et pour gerer ton bordel, tu peux te permettre d'utiliser picocontainer?

oui

bah je vois pas trop comment, les instances de mes utilisateurs de ses services sont pas "fixes", dans le parsing, si je passe sur un "+", je créé une instance de BinaryOp qui peut avoir besoin d'un des services en question. Sauf que BinaryOp elle a une cinquantaine de copains.

ha ok.
 
(enfin cela dit, doit y'avoir moyen, hein, mais c'est sans doute pas le cas de base)

+1 !
 
ce que je regrette souvent aussi c'est un SortedSet qui se baserait sur une  bête List plutôt que sur un arbre

bah euh, Collections.sort ?

C'est vrai que SWT, c'était intéressant sur le papier, mais à utiliser c'est vraiment pas top, et à programmer c'est vraiment l'horreur

'tain, mais c'est vrai que jikes c'est plus rapide
 
par contre, le projet passe pas.

 
alors la on va pas être copains  

souk > c'est une instance différente dont le toString() est le même non ?

ouais
connard de JAXB

copain

alt+insert est ton pote

http://openide.netbeans.org/tutori [...] andclasses

Chouette paragraphe. Le contenu est evident, mais c'est bien expliqué je trouve.

c'est pas ça qui va faire rentrer ma ArrayList dans une interface SortedSet ...

et donc ?

alors telecommande a fromage

je relance d'une brosse a dent

t'as compris ce que je voulais dire ou pas ?