Quand utiliser Long vs long en java?

long est une primitive, qui doit ont une valeur. Simple.

Long est un objet, donc:

• il peut être null (ce qui signifie ce que vous voulez, mais "inconnu" est une interprétation commune)
• il peut être passé à une méthode qui accepte un Object, Number, Long ou long paramètre (le dernier grâce à l'auto-déballage)
• , il peut être utilisé un générique du type de paramètre, c'est à dire List<Long> est OK, mais List<long> est pas OK
• , il peut être sérialisé / désérialisé via le mécanisme de sérialisation java

, utilisez Toujours la chose la plus simple qui fonctionne, donc si vous avez besoin des fonctionnalités de Long, utiliser Long sinon utiliser long. La surcharge d'un Long est étonnamment petite, mais elle est là.

1 Long est la partie de compteur orientée objet de long. La différence est la suivante, et elle s'applique à Float float, Integer integer etc.

• long est un type primitif, tandis que Long est une classe Java (et donc il héritera de Object).
• long doit être attribué avec un nombre valide, tandis que Long peut être null
• les instances longues ne peuvent pas utiliser les avantages de OO, tandis que les instances Longues sont de vrais objets Java
• Long est sérialisable, il sera donc très utile lorsque faire un fichier, une base de données ou un réseau IO
• long est plus efficace que Long compte tenu de l'espace mémoire et de la vitesse de traitement

Si vous effectuez des calculs lourds, utilisez des types primitifs. Sinon, si vous vous intéressez davantage au design, les pièces de compteur d'objets seront très utiles.

2 Puisque vous n'utilisez aucun framework si j'observe correctement, je vous suggère de créer une interface commeValidated avec une méthodebool validate () . Et à chaque fois que vous essayez de mettre une entrée dans l'appel de base de données validate à l'avance.

1) Utilisez Long si vous devez traiter la valeur comme un objet. Utilisez longtemps sinon; c'est plus efficace.

2) Appel au jugement, vraiment. En approfondissant cela signifie que vous allez vérifier même lorsque la valeur provient d'une source de confiance, mais cela peut détecter des erreurs dans un autre code. Le rapprocher de l'entrée utilisateur signifie que vous perdez cette vérification approfondie de la santé mentale (et que vous devrez peut-être vérifier à plus d'un endroit), mais évite de passer du temps à vérifier les choses que vous avez déjà vérifiées. Ce qui est le mieux dépend de comment vous prévoyez d'utiliser / améliorer ce code à l'avenir.

1. Comme Long est un type privimitive de classe wrapper long et Long est une classe, ce qui indique que son instance pourrait être nulle. De mon point de vue, utiliser la classe wrapper est meilleur que le type primitif car il pourrait y avoir un état null, ce qui pourrait nous dire plus d'informations.
   De plus, la classe wrapper sera automatiquement initialisée avec 0, c'est bon pour l'utilisation paresseuse.

2. Pour la validation des données, je pense que vous feriez mieux de le faire dans controller plutôt que DAO, alors ayez un bon méthode pour gérer cela ou alerter l'utilisateur pour les modifier!

L'avantage de la Longue classe est que la valeur peut être nulle. Dans votre cas, si aucun IDENTIFIANT long n'est fourni, si vous détectez rapidement cela avec quelque chose comme..

public ClientInput(Long userid, Long clientid, Map<String, String> parameterMap, Long timeout_ms, boolean debug) {
    if (userid == null) {
          throw new IllegalArgumentException("userid is null");
    }

À votre deuxième question, vous pouvez également placer votre validation d'ID dans le constructeur. Cela garantit que si l'ID est null ou invalide, un ClientInput ne peut jamais être créé. Mais il n'y a pas de" meilleure " réponse pour l'endroit où vous mettez cette validation, cela dépend de la structure du reste de votre code, mais idéalement vous voulez attrapez de telles choses le plus tôt possible.

public ClientInput(Long userid, Long clientid, Map<String, String> parameterMap, Long timeout_ms, boolean debug) {
    if (userid == null || userid < USER_ID_MIN || userid > USER_ID_MAX ) {
          throw new IllegalArgumentException("userid is invalid");
    }

Une autre option consiste à accepter le paramètre userid en tant que Long, en le testant pour null, mais ensuite à le stocker en tant que long privé et primitif, une fois que vous savez qu'il est valide.

J'essaie de garder les objets Bean aussi simples que possible, ce qui signifierait gérer la validation ailleurs - soit dans une classe de validateur distincte, soit dans une méthode validate (). L'algorithme général est le même:

• validateInputParametres()
• readDb ()

Je ferais quelque chose comme:

final ClientInput input = new ClientInput(109739281L, 20L, paramMap, 1000L, true);
validate(input); // throw/handle exceptions here

final Map<String, String> paramMap = new HashMap<String, String>();
paramMap.put("attribute", "segmentation");

final IDBClient client = DatabaseClientFactory.getInstance();
client.read(input);