web-dev-qa-db-fra.com

Quand utiliser Long vs Long en Java?

Ci-dessous mon interface -

public interface IDBClient {
    public String read(ClientInput input);
}

Ceci est ma mise en œuvre de l'interface -

public class DatabaseClient implements IDBClient {

    @Override
    public String read(ClientInput input) {

    }
}

Maintenant, j'ai une usine qui obtient l'instance de DatabaseClient comme ceci -

IDBClient client = DatabaseClientFactory.getInstance();
....

Maintenant, j'ai besoin d'appeler la méthode read de mon DatabaseClient qui accepte le paramètre ClientInput et ci-dessous est la classe pour le même. Ce cours n'a pas été écrit par moi, c'est pourquoi j'ai une question à ce sujet et je suis à peu près sûr que c'est la mauvaise façon de le faire.

public final class ClientInput {

    private Long userid;
    private Long clientid;
    private Long timeout_ms = 20L;
    private boolean debug;
    private Map<String, String> parameterMap;

    public ClientInput(Long userid, Long clientid, Map<String, String> parameterMap, Long timeout_ms, boolean debug) {
        this.userid = userid;
        this.clientid = clientid;
        this.parameterMap = parameterMap;
        this.timeout_ms = timeout_ms;
        this.debug = debug;
    }
}

Ainsi, lorsque le client appelle la méthode read de DatabaseClient, il crée le paramètre ClientInput comme ceci, puis utilise la fabrique pour obtenir l'instance de DatabaseClient puis appelez la méthode de lecture en conséquence.

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

ClientInput input = new ClientInput(109739281L, 20L, paramMap, 1000L, true);

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

Énoncé du problème: -

  1. Donc ma première question est la suivante: userid, clientid, timeout_ms doit être Long objet ou simplement long dans la classe ClientInput?
  2. Ma deuxième question est la suivante: il est possible que le client transmette des informations erronées telles que negative user ids, negative client id, negative timeout valeur etc etc .. Alors où dois-je faire cette validation? Dois-je faire cette vérification de validation dans le constructeur de la classe ClientInput ou à un autre endroit? Quelle est la meilleure façon de procéder et comment dois-je procéder à la validation?
javamapconstructor
20
AKIWEB

Je ne pense pas qu'il y ait une seule bonne réponse. Quelques suggestions:

  • La plus grande différence que je vois entre long et Long dans ce contexte est que Long peut être null. S'il y a une possibilité que vous ayez des valeurs manquantes, l'objet Long sera utile car null peut indiquer des valeurs manquantes. Si vous utilisez des primitives, vous devrez utiliser une valeur spéciale pour indiquer manquant, ce qui sera probablement un gâchis. La vitesse ou la taille ne seront probablement pas un problème, sauf si vous prévoyez de créer un tableau d'un million de ces choses, puis de sérialiser.

  • Ma préférence pour la logique de validation est de lancer une sorte de ValidationException personnalisé au point où la chose pourrait échouer. Si vous créez simplement ces choses avec un constructeur, la chose la plus simple serait simplement de les valider, par exemple.

     public ClientInput(Long userid, Long clientid, Map<String, String> parameterMap, Long timeout_ms, boolean debug) throws ValidationException {          

      if (userid == null) throw new ValidationException("UserId is required"); 
            ...etc, etc...
}

En fin de compte, le ValidationException n'est utile que si vous pouvez l'attraper à un point où vous pouvez faire quelque chose d'utile - le renvoyer à un utilisateur ou autre chose.

16
Steve B.

long est une primitive qui doit avoir une valeur. Facile.

Long est un objet , donc:

  • il peut être null (ce qui signifie ce que vous voulez, mais "inconnu" est une interprétation courante)
  • il peut être passé à une méthode qui accepte un paramètre Object, Number, Long ou long (le dernier grâce à la décompression automatique)
  • il peut être utilisé avec un type de paramètre générique, 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 de l'une des fonctionnalités de Long, utilisez Long sinon utilisez long. Les frais généraux d'un Long sont étonnamment petits, mais ils sont là.

43
Bohemian

1 Long est la contre-partie orientée objet de long. La différence est la suivante, et elle s'applique à Float to float, Integer to 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 numéro valide, tandis que Long peut être null
  • les instances longues ne peuvent pas utiliser les avantages d'OO, tandis que les instances de Long sont réelles Java objets
  • Long est un sérialisable, il sera donc très utile lors des E/S de fichiers, de bases de données ou de réseaux
  • 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 contre-pièces de l'objet seront très utiles.

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

2
TwilightSun

J'essaie de garder les objets Bean aussi simples que possible, ce qui impliquerait de gérer la validation ailleurs - soit dans une classe Validator 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);
0
as21

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

2) Appel au jugement, vraiment. L'approfondir 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 d'autres codes. En le rapprochant de l'entrée utilisateur, vous perdez ce contrôle d'esprit profond (et devrez peut-être vérifier plus d'un endroit), mais évitez de passer du temps à vérifier des choses que vous avez déjà vérifiées. Ce qui dépend le mieux de la façon dont vous prévoyez d'utiliser/d'améliorer ce code à l'avenir.

0
keshlam

  1. Comme Long est une classe wrapper de type privimitif long et Long est une classe, qui indique que son instance peut être nulle. Dans ma perspective, l'utilisation de la classe wrapper est meilleure que le type primitif car il pourrait y avoir un état null, ce qui pourrait nous donner plus d'informations.
    De plus, la classe wrapper sera automatiquement initialisée avec 0, c'est bon pour une 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 une bonne méthode pour gérer cela ou avertissez l'utilisateur de les modifier!

0
Rugal

L'avantage de la classe Long est que la valeur peut être nulle. Dans votre cas, si aucun Long ID n'est fourni, si vous le détectez rapidement 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");
    }

Pour votre deuxième question, vous pouvez également placer la validation de votre ID dans le constructeur. Cela garantit que si l'ID est nul ou non valide, 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 attraper 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, puis en le stockant en tant que long primitif privé, une fois que vous en connaissez la validité.

0
slipperyseal