Когда использовать Long vs long в java?

Ниже мой интерфейс -

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

Это моя реализация интерфейса -

public class DatabaseClient implements IDBClient {

    @Override
    public String read(ClientInput input) {

    }
}

Теперь у меня есть factory, который получает экземпляр DatabaseClient как этот -

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

Теперь мне нужно сделать вызов метода read моего DatabaseClient, который принимает параметр ClientInput, а ниже - класс для него. Этот класс не был написан мной, поэтому я задаю вопрос об этом, и я уверен, что это неправильный способ сделать это.

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;
    }
}

Поэтому, когда клиент делает вызов метода read DatabaseClient, он создает такой параметр ClientInput, как это, а затем использует factory для получения экземпляра DatabaseClient, а затем вызывает метод чтения соответственно.

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);

Проблема: -

  • Итак, мой первый вопрос заключается в том, должен ли userid, clientid, timeout_ms быть Long объект или просто просто Long в классе ClientInput?
  • Второй вопрос, который у меня есть, может быть, что клиент может передать неверную информацию, такую ​​как negative user ids, negative client id, negative timeout значение и т.д. и т.д. Затем, где я должен сделать эту проверку? Должен ли я выполнять проверку валидации в конструкторе класса ClientInput или в каком-либо другом месте? Какой лучший способ сделать это и как мне сделать валидацию?

Ответы

Ответ 1

Я не думаю, что есть один правильный ответ. Несколько советов:

  • Самая большая разница, которую я вижу между long и Long в этом контексте, заключается в том, что Long может быть нулевым. Если есть вероятность, что у вас могут отсутствовать значения, объект Long будет полезен, так как нуль может указывать на отсутствующие значения. Если вы используете примитивы, вам нужно будет использовать какое-то особое значение, чтобы указать отсутствие, что, вероятно, будет беспорядочным. Скорость или размер вряд ли будут проблемой, если вы не планируете создавать массив из миллиона этих вещей, а затем сериализуете.

  • Мое предпочтение логике валидации заключается в том, чтобы бросить какое-то пользовательское исключение ValidationException в момент, когда вещь может потерпеть неудачу. Если вы просто создаете эти вещи с помощью конструктора, проще всего просто проверить его, например.

     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...
}

    в конечном счете исключение validationException полезно только в том случае, если вы можете поймать его в точке, где вы можете сделать что-то полезное с ним - повторить его обратно пользователю или тому подобное.

Ответ 2

long - это примитив, который должен иметь значение. Простой.

long - это объект, поэтому:

  • это может быть null (что значит, что угодно, но "неизвестное" - обычная интерпретация)
  • он может быть передан методу, который принимает параметры Object, Number, long или long (последний из них благодаря автоматической распаковке)
  • можно использовать общий тип параметра, т.е. List<Long> в порядке, но List<Long> не OK
  • он может быть сериализован/десериализован через механизм сериализации java

Всегда используйте простейшую вещь, которая работает, поэтому, если вам нужны какие-либо функции long, используйте long, иначе используйте long. Накладные расходы long на удивление малы, но он есть.

Ответ 3

1 Длинная сторона, ориентированная на объект, длинна. Разница заключается в следующем, и она применяется к Float для float, Integer к целым и т.д.

  • long - примитивный тип, а Long - это класс Java (и поэтому он наследует Object).
  • long должно быть присвоено допустимое число, а Long - null
  • длинные экземпляры не могут использовать преимущества OO, а экземпляры Long - это реальные объекты Java.
  • Long является сериализуемым, поэтому он будет очень полезен при работе с файлом, базой данных или сетью IO
  • long более эффективен, чем Long, учитывая объем памяти и скорость обработки.

Если вы делаете тяжелые вычисления, используйте примитивные типы. В противном случае, если вы хотите больше узнать о дизайне, детали счетчика объектов будут очень полезны.

2 Поскольку вы не используете какие-либо фреймворки, если я правильно соблюдаю, я предлагаю вам создать такой интерфейс, как Validated, с помощью метода bool validate(). И каждый раз, когда вы пытаетесь поместить ввод в вызов базы данных, проверьте заранее.

Ответ 4

1) Используйте Long, если вам нужно обработать значение как объект. Используйте в противном случае; он более эффективен.

2) Судебный вызов, действительно. Включение этого более глубокого означает, что вы собираетесь проверять, даже когда значение исходит от источника, которому вы доверяете, но это может ловить ошибки в другом коде. Помещая его ближе к пользовательскому вводу, вы теряете эту глубокую проверку работоспособности (и, возможно, вам нужно проверить несколько мест), но избегайте проводить время, проверяя вещи, которые вы уже проверили. Что лучше всего зависит от того, как вы планируете использовать/улучшать этот код в будущем.

Ответ 5

  • В качестве Long используется тип примитивного класса Long и Long - класс, который указывает, что его экземпляр может быть нулевым. В моей перспективе использование класса-оболочки лучше, чем примитивный тип, потому что в нем может быть состояние null, что может сообщить нам дополнительную информацию.
    Кроме того, класс-оболочка будет автоматически инициализирован с помощью 0, это полезно для ленивого использования.

  • Для проверки данных, я думаю, вам лучше сделать это в controller, а не DAO, а затем иметь хороший метод для этого или предупредить пользователя об их изменении!

Ответ 6

Преимущество класса Long заключается в том, что значение может быть нулевым. В вашем случае, если Long ID не предоставляется, если вы быстро обнаружите это с чем-то вроде.

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

К вашему второму вопросу вы можете также разместить свою идентификационную проверку в конструкторе. Это гарантирует, что если идентификатор является нулевым или недействительным, ClientInput никогда не может быть создан. Но нет "лучшего" ответа на то, где вы ставите эту проверку, это зависит от структуры остальной части вашего кода, но в идеале вы хотите как можно раньше поймать такие вещи.

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");
    }

Еще одна опция - принять параметр userid как Long, протестировать его на null, но затем сохранить его как закрытый, примитивный длинный, как только вы его знаете.

Ответ 7

Я стараюсь держать объекты Bean максимально простыми, что означало бы проверку правильности работы в другом месте - либо в отдельном классе Validator, либо в методе validate(). Общий алгоритм один и тот же:

  • validateInputParametres()
  • readDb()

Я бы сделал что-то вроде:

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);