Pen^2 (./1790) :
Étant donné l'implémentation, d'un point de vue bas niveau, je suis d'accord. Mais sémantiquement c'est pas censé être la même chose.De la même manière je ne conseillerais pas les enum c++ pour faire des opérations sur des entiers.
Sauf que faire un singleton avec une classe c'est encore plus un hack que de le faire avec une enum. Le concept de base d'une classe c'est de fournir un modèle qui permet de produire un nombre indéterminé d'instances. Bref, tout le contraire du singleton. C'est justement a la classe qu'on doit rajouter des hacks pour permettre de réaliser cela.
Un enum Java est bien plus adapté, vu qu'il est fait pour produire un nombre prédéterminé d'instances.
Si une enum ne parait pas naturelle c'est juste un problème d'habitude, héritée du C puis du C++. Dans ces langages, une enum n'est avant tout un ensemble de valeur numériques, ce qu'il n'a jamais été le cas en Java.
squalyl (./1792) :
le machin qui manque le plus a java c'est quand même un préprocesseur...
C'est ce je pensais à l'époque où je faisais des jeux vidéos sur téléphones portables. On avait besoin de pas mal de code conditionnel pour gérer les différentes tailles d'écran, le diverses quantité de mémoires, les hacks spécifiques a certaines marques, ...
On a commencé par faire notre propre préprocesseur pour traiter cela, puis on a utilisé le programme "cpp" qui gère la partie préprocesseur de gcc.
Mais au final on c'est rendu compte qu'il était bien plus simple, propre et généralement tout aussi efficace de s'appuyer sur les constantes Java.
En gros tout objet de type
boolean,
char,
String,
byte,
short,
int ou
long qui est déclarés comme "static final" est une constante. Toutes les opérations qui ne portent que sur des constantes sont traitées à la compilation et les code qui s'avèrent morts suite a cette évaluation sont sorti du fichier class final. C'est un comportement qui est garanti par la spécification Java.
squalyl (./1795) :
La on est obligé de faire des trucs sales genre if(debug.enabled) Log,i("tag", "proot"); et on compte sur l'optim (debug.enabled est un static final boolean) pour virer les lignes quand la cond est évaluée a false, mais y'a pas d'autres moyens. Une classe filtre qui éviterait d'afficher des trucs rendrait l'app silencieuse, mais ne virerait pas les chaines.
Ca n'a rien de sale. La suppresion du code d'un if dont la condition repose uniquement sur des constantes est garantie par la spécification.
Pen^2 (./1796) :
Une méthode infiniment plus classe (et surtout robuste et élégante 
— ouais, classe, quoi 
) est d'utiliser un aspect : ça tient en trois lignes, c'est ajouté partout (ou aux endroits souhaités si tu veux faire plus fin) et se désactive à un seul endroit.
Au bucher l'hérétique!!!
La programmation aspect est juste une horreur, qui ne fait heureusement pas partie de Java de base.
C'est une saleté encore pire que l'introspection. Ça rend le flux d’exécution du code encore plus difficilement prévisible. A la limite tant que ça ne sert qu'a faire des log, ça peut aller. Mais si on en abuse, ça peut très vite devenir une horreur
du java? omg, va falloir que je relise la sec du langage
du java? omg, va falloir que je relise la sec du langage 
— ouais, classe, quoi , c'est vraiment un test en carton (genre la visibilité avec la réflexion. Super. Moi avec un décompilateur je modifie encore plus de trucs
— j'ai même pas été au bout
).
, c'est vraiment un test en carton (genre la visibilité avec la réflexion. Super. Moi avec un décompilateur je modifie encore plus de trucs 
— j'ai même pas été au bout 
