Например.

Ку, друзья. Вопрос по бест практис. Вот у меня есть в программе кастомный сетевой протокол. Я получаю по сети буферы по UDP а потом эти буферы байтиков мне надо парсить в свой протокол. У моего кастомного протокола есть порядка 30 типов пакетов. У всех пакетов есть общие поля, а есть поле данных, которое разбивается на разные подполя для каждого пакета. Вопрос в том, как сделать лучше:

1) Создать интерфейс, в котором описать общие поля, а в наследниках уже определять дополнительные поля. Парсер будет создавать объект наследника но возвращать объект типа интерфейса. А дальше через instanseof проверять что это именно за пакет и кастить при необходимости, чтобы получать данные с полей.

2) Создать один класс и парсить все поля пакетов в хеш-мапу, а дальше курить эту хеш-мапу. Тогда для одних пакетов в хеш-мапе будут одни ключи валидными, для других - другие.

Я склоняюсь к первому варианту, но не знаю насколько норм считаются такие проверки и касты. С другой стороны не хочется возиться с хеш-мапой, запоминать для какого типа пакета какой ключ в хеш-мапе есть и все эти проверки на нулы делать тоже не хочется.

Какие есть мысли по этому поводу?

1 вариант выглядит более читаемо и легко поддерживаемо. Но это имхо.

А ты уверен, что хочешь хранить общие поля в интерфейсе? У интерфейсов другая роль

Ну если мне нужно получить доступ к общему полю независимо от типа наследника. Скажем, у меня есть поле дескриптора пакета, оно есть у всех пакетов. Почему бы тогда не описать это поле в родительском классе?

Так родительский класс или интерфейс?

Там, кстати, возможно не интерфейс получится, а абстрактный класс, некоторые поля будут абстрактными.

Об этом Дмитрий же выше и говорил

Ну да, я просто не продумал детали реализации. Но всё таки вопрос в другом. Лучше ли будет вариант с наследниками, или один класс с хеш-мапой?

Ребят, привет, подскажите плез, через RestTemplate можно ловить html страницу, а не json?

Ну а что будет с мапой, если потребуется разное поведение делать у разных пакетов

А зачем кастить? Как будут использоваться разные поля?

Лучше все на полиморфизме делать и интерфейсах

Я не предполагаю никакого особого поведения для разных пакетов. По сути у класса две задачи:

1) Получить массив байт и распихать по соответствующим полям, чтобы потом получать к ним доступ
2) Запихнуть все поля обратно в массив байт

Больше от этого класса ничего не требуется.

А без каста как я получу данные из поля? Если у одного пакета, например, есть поле request, а у другого result. У их родителя таких полей, понятное дело, нет. Без каста же не получится получить ни то, ни другое поля. Или я чего-то не знаю?

Ну это сериализация, можно например в каждом пакете написать реализацию, как его можно сериализовать/десериализовать, тогда потом просто будет вызывать на нем и не знать как, без instanceof. А интерфейс поможет работать со всеми как с одним

а как предпологается использовать потом эти классы, как часто поля будут менятся?

если делать надолго то тут лучше с классами, а если будут часто меняются то ИМХО мапа, а может вам вообще разные сущности не нужны вам и одной будет за глаза подо все случаи

Может кто подсказать про секьюрити ?
Я хочу к entity сделать 2 поля : password, confirmPassword.

password - хешируется и пишется в базу , с аннотацией @JsonIgnore - чтобы не показывать его в селекте.

confirm - с аннотацией JsonIgnore и @Transient.

Я хочу для регистрации по рест - посылать этот entity , но из-за jsonIgnore в контроллере я вижу только null.  

Как это все правильно организовать ?

не городить велосепеды а использовать готовые решения