Как лучше сформировать класс Record?

Question

[Yourmind]

У меня есть какой то класс User (храню его в бд). У него есть первичный ключ id. Также у меня есть класс Record, означает запись клиента. В нем там есть какие то поля. Также нам надо ссылаться на клиента. И тут возникает вопрос как лучше: хранить в классе User или только его id?
Т е:

public class User {
private int id;
...
}

Вариант 1:
public class Record {
private int user;
...
}

вариант2:
public class Record {
private User user;
...
}

Comments

[Евгений Ромашкан]

Лучше только id ради меньшей связности.

[Frozen Coder]

Евгений Ромашкан, Можете раскрыть мысль? Как ссылка на класс оказывает влияние на связность?

[Евгений Ромашкан]

Frozen Coder, Чтобы инициализровать экземпляр вашего класса вам придётся постоянно создавать экземпляр класса User, если класс не взаимодействут с моделью юзера, хоть и относится к ней(т.е. должен знать что она есть) наилучшим вариантом будет шэрить идентификаторы. Они почти всегда достаточно стабильны, в отличии от классов.

[Frozen Coder]

Евгений Ромашкан, как понять, что классы нестабильны? Ну есть у меня в классе Record ссылка на User. Что там у него внутри меняется, мне в Record никак не волнует. Что плохого в экземпляре объекта, если мы запускаемся на сервере, а не на IOT? А потом внезапно понадобиться куда-нибудь передавать заполненый класс Record со всеми его вложенными товарищами и тогда привет рефакторинг или метод на сто-пятьсот аргументов или новый класс?

[Евгений Ромашкан]

Frozen Coder, В данном случае хватит лишь того факта что идентификаторы сущностей стабильнее чем сами сущности.
У класса User может поменсяться конструктор, название, интерфейс, он может быть вынесен в отдельный микросервис, он может превратиться в несколько классо UserCredentials + UserPersonalInfo и т.п., но при всех этих действиях его ID не поменяется.

А потом внезапно понадобиться куда-нибудь передавать заполненый класс Record со всеми его вложенными товарищами и тогда привет рефакторинг или метод на сто-пятьсот аргументов или новый класс?

Что значит передавать Record со вложенными товарищами?
Record это модель/сущность или DTO?
Ваше "передавать со всеми вложенными товарищами" часом не нарушает закон Деметры?
Зависит ли логика, или планируется ли зависимость в бизнес логике между этими двумя классами?

Это вопросы на которые вы сами должны ответить. А под эгидой "А потом внезапно понадобиться куда-нибудь передавать заполненый класс" можно и ещё тысячу классов из системы в ваш Record запихать.

Answer 1

[Victor Bomberow]

Если у вас есть смонения, что в будущем обычным встроенным типом дело не ограничится, то предпочитайте класс.

Если вы используете концепцию Record для названия, то скорее всего вы ещё не определились с диаграммой классов, потому что Record слишком высокоуровневые понятие, и скорее всего, вы планируете использовать как класс-контейнер, а значит имеет смысл сделать его шаблонным/параметризируемым типом хранения.

Если все же вы не уверены, то лучше оставить User, потому что так намерения выражены однозначнгти код понятнее, будет проще в будущем рефакторить

Answer 2

[Frozen Coder]

Это классы прямое отображение вашей схемы БД (т.е. описывают java-кодом как у вас данные в БД хранятся) или это ваши обычные классы, которые участвуют в бизнес логике?

Если первое, то такое обычно лучше генерить автоматом с помощью какого-нибудь JOOQ, если оно вам вообще надо. И тогда это будет вариант 1

Если второе, то конечно выбираете вариант 2. Какой вам толк от одного id-шника? А если вам куда-то передавать надо будет Record, то ещё и отдельно его User будете тащить?

Есть ещё вариант, что это у вас какое-то DTO и нужно только знать id, связанного пользователя и всё. Самого пользователя никогда внутри Record увидеть не хотите, не ожидаете, не нужно, лишние таскать тяжело. Тогда вариант 1.

Вообщем. Исходите из решаемой проблемы и как вы с этим будете дальше жить и использовать.

Comments

[Евгений Ромашкан]

Если второе, то конечно выбираете вариант 2. Какой вам толк от одного id-шника? А если вам куда-то передавать надо будет Record, то ещё и отдельно его User будете тащить?

У меня есть, условно продукт, у него есть какая-то логика, есть Категория. В продукте я храню только ссылку на категорию.
С чего вдруг мне нужно будет тащить Категорию туда где нужен продукт?

А толк от id-шки в том чтобы выразить связь, т.к. продукт должен относится к категории.

[Frozen Coder]

Евгений Ромашкан, ну и будут поля пустые, кроме id. Зато потом, когда понадобиться всё вместе заполненное, не надо будет плодить ещё класс(ы).

[Евгений Ромашкан]

Frozen Coder,

ну и будут поля пустые, кроме id

Сущность Категории не существует без, условно, поля "Название", и других обязательных для заполнения данных. Это первое.
Второе - qualityisspeed.blogspot.com/2014/09/beyond-solid-d...

p.s. Начните лучше юнит-тесты писать - очень быстро придёт познание, чем плохо лепить зависимости без причины.

[Frozen Coder]

Евгений Ромашкан, пишу я тесты уже несколько лет. Где зависимости в тестах не нужны, не заполняешь их или мокаешь. 5 проектов сменил с разными стеками, авторами, сроками жизни и нигде ничего подобного не видел, за исключением, как, я написал в ответе, DBRecord и DTO.

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