Что вы делаете, когда начинаете новый класс POJO?

Question

Допустим, вы настраиваете POJO.

Что вы определяете при настройке класса?

Вот мой список

• Конструктор для создания объекта с предоставленными полями (чтобы я мог сделать поля окончательными и, следовательно, неизменяемыми)
• ToString
• равно
• * 1014 хэш-код *
• орудия, сопоставимые
• get методы (где применимо)
• [Необязательно] конструкторы копирования для изменяемых полей - чтобы гарантировать неизменность класса
• [Необязательно] Определите интерфейсы для доступа к полям и методам.
• [Необязательно] реализует Serializable и реализует схему управления версиями.

Это перебор или звуковая инженерия? Что-нибудь упущено, что вы бы добавили?

Answer 1

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

Answer 2

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

Я бы сказал, что у вас там хороший список, но (в зависимости от вашего механизма ORM) я также склонен определять, какие значения (кроме идентификатора автоинкремента) определяют «уникальность» любой записи.

Я упоминаю об этом только потому, что hibernate имеет странное поведение с наборами, если вы используете идентификатор в hashCode, потому что он может измениться в середине процесса.

Также стоит отметить, что стоит потратить время на изучение того, какие коллекции будут Lazy или Eager, особенно для метода toString (который может вызвать Lazy-Inits, если вы выполняете toString, когда вы отсоединены от контекста постоянства). .

Answer 3

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

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

Если, с другой стороны, вы смотрите на более крупный, распределенный проект или публичный API, я думаю, что это идет вразрез с основами. Как минимум, обо всем в этом списке следует подумать, даже если в конечном итоге решено, что класс может быть изменчивым, например, по крайней мере, решение было принято разумно.

Answer 4

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

Обычно я начинаю с интерфейса, который определяет, что какой-то другой объект в системе хочет, чтобы новый объект делал. Реализация этого интерфейса "вытянет" остальную часть класса в существование.

Answer 5

Полный перебор. Применить ЯГНИ.

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