Lors de l'utilisation de Longues vs long en java?

Ci-dessous est mon Interface -

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

C'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 devient l'instance de DatabaseClient comme celui -

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

Maintenant, j'ai besoin de faire un appel à read méthode de mon DatabaseClient qui accepte le ClientInput paramètre et ci-dessous est la classe la même. Cette classe n'a pas été écrit par moi, donc c'est la raison pour laquelle je vais avoir 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 de faire un appel pour read méthode de DatabaseClient, ils vont créer le ClientInput paramètre comme ceci, puis utilisez l'usine pour obtenir l'Instance de DatabaseClient, puis d'appeler 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 userid, clientid, timeout_ms devrait être Long objet ou tout simplement long dans ClientInput classe?
  2. Deuxième question que j'ai est, il pourrait être possible que le client peut passer de fausses informations telles que negative user ids, negative client id, negative timeout valeur etc etc.. Alors où je dois faire cette validation? Dois-je faire cette vérification de la validation dans le constructeur de ClientInput classe ou à un autre endroit? Quelle est la meilleure façon de le faire et comment dois-je procéder à la validation?
Vous avez posé deux questions très différentes. Vous devriez en faire deux séparés offres, comme Stackoverflow n'est pas destiné à être un groupe de discussion. Je suis sûr que vous trouverez à la fois les questions posées et a répondu à de nombreuses fois avant. Sur la première question, rechercher lors de l'utilisation de l'objet et de l'utilisation d'une primitive. Pour la deuxième question, la recherche pour la validation des arguments / paramètres.

OriginalL'auteur AKIWEB | 2014-01-10

  1. 14

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

    • la plus grande différence que je vois entre et long dans ce contexte est que Long peut être null. Si il ya une possibilité que vous pourriez avoir des valeurs manquantes le Long de l'objet sera utile que la valeur null peut indiquer des valeurs manquantes. Si vous êtes à l'aide de primitives, vous aurez à utiliser une valeur spéciale pour indiquer manquant, qui est probablement va être un gâchis. La vitesse ou la taille n'est pas susceptible d'être un problème, sauf si vous prévoyez de faire un tableau d'un million de ces choses et puis la sérialisation.

    • Ma préférence pour la validation de la logique est de lancer une sorte de coutume ValidationException au point où la chose pourrait échouer. Si vous êtes simplement à la création de ces choses avec un constructeur, la chose la plus simple serait tout simplement de valider, par ex.

       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 la validationException n'est utile que si vous pouvez l'attraper, à un point où vous pouvez faire quelque chose d'utile avec de l'écho de retour à un utilisateur ou quoi que ce soit.

    Je fais la même chose Steve, j'utilise seulement IllegalArgumentException. Mais oui, le temps est un wrapper pour une longue. Le seul réel avantage de l'utilisation de Long est fait pour égaliser de référence au lieu de la valeur, ou utiliser la valeur null comme une sentinelle.

    OriginalL'auteur Steve B.

  2. 39

    long est un primitif, qui doit ont une valeur. Simple.

    Long est un objet, donc:

    • il peut être null (le sens de ce que vous voulez, mais "inconnu" est une interprétation commune)
    • il peut être transmis à une méthode qui accepte un Object, Number, Long ou long paramètre (la dernière en date grâce à la fonction auto-unboxing)
    • 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 est possible de sérialiser/désérialiser 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, utilisez Long utiliser autrement long. La surcharge d'un Long est étonnamment petit, mais il est là.

    OriginalL'auteur Bohemian

  3. 2

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

    • est la durée d'un type primitif, alors que pendant Longtemps est une classe Java (et donc il va hériter d'un Objet).
    • doit être affecté à un numéro de série valide, alors que pendant Longtemps peut être null
    • long instances ne pouvez pas utiliser les avantages de l'OO, tandis que les instances de Long sont de véritables objets Java
    • Est la durée d'un serializable de sorte qu'il sera très utile lorsque vous faites fichier, base de données ou du réseau IO
    • longtemps est plus efficace que le Long compte tenu de l'espace mémoire et la vitesse de traitement

    Si vous faites de lourds calculs, utiliser les types primitifs. Sinon, si vous êtes sujet de plus sur la conception, l'objet de contre-parties sera très utile.

    2 Puisque vous n'êtes pas en utilisant des cadres si je suis en observant correctement, je vous suggère de faire une interface comme Validé avec une méthode bool valider(). Et à chaque fois que vous essayez de mettre une entrée dans la base de données d'appel de valider à l'avance.

    OriginalL'auteur TwilightSun

  4. 0

    1) l'Utilisation de Longues si vous avez besoin de traiter la valeur comme un objet. Longues, l'autre, c'est plus efficace.

    2) le Jugement d'appel, vraiment. Mettre plus profond signifie que vous allez vérifier, même lorsque la valeur est à venir à partir d'une source de confiance, mais qui peuvent rattraper les erreurs dans le code des autres. Le mettre plus près de l'entrée de l'utilisateur signifie que vous perdez qu'au plus profond de la santé mentale-vérifier (et peut-être besoin de vérifier à plus d'un endroit), mais évite de passer du temps vérifier les choses que vous avez déjà vérifié. Ce qui est mieux dépend de la façon dont vous prévoyez sur l'utilisation ou à l'amélioration de ce code dans l'avenir.

    OriginalL'auteur keshlam

  5. 0

    1. Comme Long est classe wrapper privimitive type long et Long est une classe, qui indiquent son exemple pourrait être null. De mon point de vue, l'utilisation classe wrapper est mieux que de type primitif, car il peut y avoir null état, ce qui pourrait nous dit de plus amples informations.

      En outre, la classe wrapper sera automatiquement initialisé à 0, c'est bon pour les paresseux à l'aide.

    2. Pour la validation des données, je pense que vous feriez mieux de le faire dans controller plutôt que DAO, puis avoir une bonne méthode pour gérer ce ou alerter l'utilisateur de les modifier!

    OriginalL'auteur Rugal

  6. 0

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

    À votre deuxième question, vous pouvez placer votre ID de validation 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 de l'endroit où vous mettez cette validation, il dépend de la structure du reste de votre code, mais, idéalement, vous voulez prendre 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 est d'accepter le paramètre userid comme un Long tester la valeur null, mais ensuite le stocker en tant que privé, primitive de long, une fois que vous connaissez la validité de son.

    OriginalL'auteur slipperyseal

  7. 0

    J'essaie de garder les Haricots objets aussi simples que possible, qui serait un moyen de manipulation de validation, d'ailleurs -, soit dans une autre classe de validation ou dans un validate() de la méthode. 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);

    OriginalL'auteur as21