I am wondering which principle should I use. Here is my situation.I have a class named TravelOffer. This class looks like this:public class TravelOffer{    private final long id;    private final StartZone startZone;    private final EndZone endZone;    private final List<Waypoint> waypoints;    private final Period startOff;    private final User travelCreator;    private final List<User> participantsList;    private final TravelExtras travelExtras;    private final CandidateApprovement candidateApprovement;    private int numberOfSeats;    private double pricePerPerson;    private Luggage luggage;    private boolean additionalLuggageTransport;    private String additionalDescription;}As u see there are the following attributes: User tavelCreator and List<User> participantsListWhat I am wondering is should it be like this or simply to replace the User object with an String userId and then from a singleton class to get the User object which will be in a Hashmap?
Should I have an object as attribute or primitive id?
java;design patterns;object oriented design
I don't think there's one right answer because both solutions come with some advantages and disadvantages. I regularly use both depending on the situation. Having the referenced entity as an object makes this entity class more convenient to use but the downside is that it quickly gets complex to manage all these references. Once the object graph gets more complex you may find yourself in a situation where you can find a chain of references between any two arbitrary entities. Think what happens when you later modify the User class, for example, and add member List<TravelOffer> to it. You now have a cyclic dependency and looking up one entity would require you to follow the graph and lookup a whole bunch of other entities you probably will not need. This all can be managed with proxy classes and lazy loading, for example, but that easily gives you new problems to worry about.Having the referenced entity as an ID is easy for you to implement but makes the entity class less convenient to use. As you mentioned yourself, it would require you to do extra lookups when you use the entity. Using a singleton does not sound like a good idea so this approach would then limit you to making these lookups only in places where you have access to some kind of a repository that knows how to resolve the IDs.