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

Question

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

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

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

public class DatabaseClient implements IDBClient { 

    @Override 
    public String read(ClientInput input) { 

    } 
} 

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

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

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

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, как это и затем использовать завод, чтобы получить экземпляр 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); 

Постановка задачи: -

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

Answer 1

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

• Самая большая разница, которую я вижу между длинными и длинными в этом контексте, заключается в том, что 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 только полезно, если вы можете поймать его в точке, где вы можете сделать что-то полезное с ним - эхо его обратно к пользователю или любой другой.

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

Преимущество класса 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"); 
    } 

Другой вариант заключается принять параметр как идентификатор пользователя Long, испытывая его на нуль, а затем сохранить его в качестве частного, примитив долго, как только вы знаете его действительным.

Answer 6

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

Long является объект, так:

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

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

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