Chaque fois que j'écris une nouvelle classe, j'utilise une tonne de variables de classe pour décrire les propriétés de la classe, jusqu'au point où je retourne pour passer en revue les codes que j'ai dactylographiés, je vois des années 40 à 50 de variables de classe , Indépendamment de ce qu'ils soient publics, protégés ou privés, ils sont tous utilisés bien en évidence dans les classes que j'ai définies.
Même si, les variables de la classe se compose principalement de variables primitives, telles que les booléens, les entiers, les doubles, etc., j'ai toujours ce sentiment mal à l'aise où certaines de mes classes avec de grandes quantités de variables de classe peuvent avoir un impact sur les performances, Cependant négligeable, ils peuvent être.
Mais être rationnel aussi possible, si je considérais la taille de la RAM illimitée et des variables de classe Java illimitées, une classe Java peut être un bloc de mémoire infiniment important dans la RAM, que la première partie du bloc contient les cloisons de variables de classe et Le reste du bloc contient les adresses aux méthodes de classe dans la classe Java. Avec cette quantité de RAM, la performance pour elle est très non provisoire.
Mais ce qui précède ne fait pas de mes sentiments plus facile que dit. Si nous devions envisager des variables de classe Java limitées mais illimitées, quel serait le résultat? Qu'est-ce qui se produirait vraiment dans un environnement où la performance compte?
Et probablement peut être mentionné à l'avance, je ne sais pas si vous avez beaucoup de variables de classe compte comme une mauvaise pratique de Java, lorsque tous sont importants, et toutes les classes ont été refactées.
Merci d'avance.
7 Réponses :
performance n'a rien à voir avec le nombre de champs d'un objet. La consommation de mémoire est bien sûr potentiellement affectée, mais si les variables sont nécessaires, vous ne pouvez pas faire grand chose à ce sujet. Ne vous inquiétez pas trop sur la performance. Faites votre code simple, lisible, maintenable, testé. Ensuite, si vous remarquez des problèmes de performance, mesurer et profiler pour voir d'où ils viennent et optimisent si nécessaire.
La maintenabilité et la lisibilité sont affectés par le nombre de champs qu'un objet a cependant. 40 à 50 champs est pas mal de nombreux champs et constitue probablement une indication que vos classes font trop de leur part et ont trop de responsabilités. Le refactorisant à de nombreuses sous-classes plus petites et à l'aide de la composition serait probablement une bonne idée.
+1 La maintenabilité et la lisibilité sont presque toujours plus importantes que la performance. En fait, je dirais que le code propre, simple et bien entretenu fonctionnera généralement bien s'il ne soit pas le plus rapide.
JB il fait du point de vue du GC. Je travaille sur une plate-forme de trading et nous avons parfois dû mettre de nombreux champs dans une classe pour réduire le nombre de fois que GC mineur prend (nous utilisons le collecteur CMS).
Je l'aime bien. +1 Assurez-vous que les exigences sont respectées d'abord, puis vous craignez de la performance si cela devient un problème.
J'espère que je ne ressemble pas à un cul, mais à mon avis, avoir plus de 10 propriétés dans une classe, c'est généralement un soupçon de mauvais design et nécessite une justification.
performance sage, si vous Selon le capteur de déchets que vous utilisez, avoir de plus gros objets peut être plus coûteux à allouer (ceci est vrai pour le collecteur de déchets CMS, mais pas pour le parallèle). Plus de travail de GC = moins de temps pour votre application à exécuter.
Sauf si vous écrivez un trafic élevé, une application de latence faible, les avantages d'avoir moins de cours (et d'utiliser moins de mémoire) vont être complètement submergés par l'effort supplémentaire nécessaire à la maintenance.
+1 Je ne vois pas la conception de classe autant différent de la conception de la DB. Parfois, c'est bien et même préféré, laissez une classe être un peu gonflée (2e et 1ère forme normale pour l'analogie de dB), surtout si la classe est sur la crête des exigences de la portée.
Le plus gros problème que je vois dans une classe avec beaucoup de variables est la sécurité du fil - il sera vraiment difficile de raisonner sur les invariants dans un tel cas. La lecture / maintenance aussi une telle classe va également être vraiment difficile.
Bien sûr, si vous faites autant que vous pouvez les champs immuables, cela va être beaucoup mieux.
J'essaie d'aller avec: moins c'est mieux, plus facile à entretenir.
Un principe de base que nous sommes toujours enseignés est de garder la cohésion élevée (une classe se concentre sur une tâche) et de coupler une tâche basse (moins d'interdépendance entre les classes de sorte que les changements d'un n'effectuent pas d'autre effet d'autres).
Tout en concevant un système, je croirai que l'accent devra être davantage sur la conception de maintenabilité, la performance prendra soin de lui-même. Je ne pense pas qu'il y ait une limite fixe sur le nombre de variables qu'une classe peut avoir une bonne pratique, car cela dépendra strictement de votre exigence.
Par exemple, si j'ai une exigence dans laquelle l'application suggère un cours à l'étudiant, et que l'algorithme a besoin de 50 entrées (scores, passe-temps, etc.), cela ne comportera pas si ces données sont disponibles en une classe ou dans un multiple. Les informations doivent être chargées dans la RAM pour une exécution plus rapide.
Je vais à nouveau dire, prendrai soin de votre conception, il est à la fois nocif de conserver des variables inutiles dans une classe (car elle chargera des informations non requises à la RAM) ou de scinder plus de classes que nécessaire (plus de références et d'un pointeur plus mouvement)
Parfois des variables de classe sont utilisées comme des constantes finales statiques pour stocker certaines chaînes par défaut telles que le nom du produit, la version, la version du système d'exploitation, etc. Ou même pour stocker des paramètres spécifiques du produit, de type, etc. Ces variables statiques peuvent être conservées à niveau de classe.
Vous pouvez également utiliser HASHMAP au lieu d'une classe simple si vous souhaitez simplement stocker des champs de champs ou un paramètre de produit qui change rarement. Cela peut vous aider à accélérer votre temps de réponse.
Deux choses que je voudrais mentionner: 1. Toutes les variables d'instance sont stockées dans une zone de tas de RAM .. 2. Toutes les variables statiques sont stockées dans une zone non-tasse (zone de méthode à spécifiquer).
Quel que soit le type de variable (instance ou statique), finalement réside dans la RAM.
venant maintenant à votre question. En ce qui concerne l'instance Variable, le collecteur des ordures intégré de Java fonctionnera dans la plupart des cas et vraiment efficacement, de continuer à libérer la mémoire. Cependant, les variables statiques ne sont pas recueillies.
Si vous êtes très préoccupé par des problèmes de mémoire en raison d'un grand nombre de variables de votre classe, vous pouvez recourir à des références faibles au lieu d'une référence forte traditionnelle.
Essayez de réduire les variables de classe si possible. Il suffit de changer votre modèle de conception peut aider à cela.
Sont-ils des variables ou des constantes de classe (c'est-à-dire
finale statique ). Seriez-vous également capable de donner un exemple de "variable de classe utile", car je trouve qu'il est un peu difficile d'imaginer quel type de scénario parle ici.Ceci est un nombre insensé de variables. Si du tout, cela devrait être nécessaire extrêmement rarement . Si vous vous trouvez en utilisant cela plus souvent, votre conception a besoin d'améliorer.