Как «открытый класс FoobarID расширяет длинные»?

Думаю, я должен признать, что Long is final и не может быть продлен.Как «открытый класс FoobarID расширяет длинные»?

В нашем проекте мы используем базу данных и идентификаторы пропусков для разных вещей в коде как Long-s.

Но UserID не LogID и не ServerID хотя они все Long с. Мне кажется, что компилятор и IDE должны иметь возможность обнаруживать целую категорию ошибок, например. при попытке использовать UserID вместо ServerID. В настоящее время компилятор не обнаруживает этого, потому что тип обоих равен Long.

Если Long не final я мог сказать

public class UserID extends Long {};

но Long является final, так что я не могу. Есть ли что-то более изящное, чем:

public class UserID { 
     private Long ID; 
     UserID(Long ID) { 
      this.ID = ID; 
     } 
     UserID(UserID ID) { 
      this.ID = ID.toLong(); 
     } 
     public Long toLong() { 
      return ID; 
     } 
     public void fromLong(Long ID) { 
      this.ID = ID; 
     } 
    };

Edit: Я знаю , что это некрасиво - "плохо"! Комментарии, похоже, предполагают, что я собираюсь добавить что-то подобное в мой производственный код. Я не.

Это просто кажется таким расточительным и нелепым. И я думаю, что удачи, например, DbUtils для работы с UserID s в обработке JavaBean.

Есть ли «лучший способ» (ТМ)? (Кроме жизни только с Long -s ;-))

источник

2015-10-10 Peter V. Mørch

Сначала подумайте: у чего есть 'UserId',' LogId', 'ServerId' и' WhateverId' в общем и каковы их отличия? Когда вы это обнаружите, вы можете придумать лучшую стратегию дизайна. –

Решение на основе композиции достаточно изящно для меня, если вы избавитесь от 'UserID (UserID)' и 'fromLong (Long)', чтобы сделать его неизменным. –

Я не могу думать о том, о чем говорит Луиджи, но для меня любое решение выглядит странно. Даже ваше решение не мешает вам создавать новый UserId (LogId.getId()) или новый UserId (100500), в котором 100500 отправляется идентификатором того, кто взял идентификатор из другого объекта. Вы просто раздуваете свой код с помощью некоторого переработанного решения, которое не приносит вам ничего. –

-2

Вместо использования Long используйте BigInteger. Таким образом, вы можете увеличить UserIDBigInteger.

источник

2015-10-10 20:04:25 hotzst

Вы действительно предлагаете человеку сделать первичными ключи в своей базе данных как BigDecimal, а не долго? действительно? общий. –

Нет, я предлагаю сделать представление в Java BigDecimal. Конечно, если есть подходящая абстракция, которая позволила бы получить решение с наследованием, это может быть лучшим способом. – hotzst

'BigDecimal' должен использоваться для обработки десятичных значений, таких как 1.5. Я не вижу simmilitude между этим и значением 'Long', который не поддерживает такие данные. Возможно, вы хотите предложить продлить действие с BigInteger, но все же я не считаю это полезным. –

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

источник

2017-01-14 11:21:21

Как «открытый класс FoobarID расширяет длинные»?

ответ

Смежные вопросы