Java - Should I use a field or a class for the problem as follows:

Question

I have two tables in the DB

• FuelStation (fuel_station_id: int (PK), fuel_station_name: varchar, fuel_brand_id: int(FK))
• FuelBrand (fuel_brand_id: int (PK), fuel_brand_name: varchar)

As we can see, both tables are linked via. foreign key (fuel_brand_id)

Now, I want to design an object model corresponding to the above data model but I am confused which approach to use from the following two approaches:

• Whether to make only one class FuelStation and store fuel brand as String in the FuelStation class.

OR

• Make two classes: FuelStation and FuelBrand. And then associate them with a Many-to-One relationship as one fuel station will have only one fuel brand but one fuel brand can have many fuel stations.

Q1. Which approach is better?

Q2. What are the pros and cons of each approach?

---

Upto My Knowledge:

Pros of Approach 2

• It has made our object model more granular.

• Acc. to good design principles, our object-model must be atleast as granular as relational-model. And approach2 follows that principle

Pros of Approach 1

• No need to create a separate object for FuelBrand for every FuelStation

Answer 1

1. make only one class FuelStation and store fuel brand as String in the FuelStation class.
2. make two classes: FuelStation and FuelBrand. And then associate them with a Many-to-One relationship as one fuel station will have only one fuel brand but one fuel brand can have many fuel stations.

There is no clear universal choice between these two approaches, since a lot depends on the context. Some deciding factors:

• how many stations and brands do you have? If you have a huge number of stations using the same fuel brand, it may be better to avoid duplication using the 2nd approach. OTOH if in practice each fuel brand is used by only one station (and it's not going to change), it makes sense to use the 1st approach.
• is it possible/expected that FuelBrand properties change, or new properties are introduced? If so, it is again better to use the 2nd approach - otherwise any change in FuelBrand would require changing the FuelStation class.
• is it possible that a fuel station may have multiple fuel brands in the future? That would again require the 2nd approach.

As a bottom line, the 2nd approach is more flexible, so I would prefer that, even if there is no foreseeable changes right now which would explicitly require this design - in SW development, never say never :-)

Answer 2

Which one is better depends on what you want to do with the information.

a) If it is interesting to list all stations that deliver a certain brand, you might also want to opt having some sort of map from the FuelBrand name to a collection of FuelStations.

b) If the fuel brand has or will have any properties (price etc. ) that you want to use, it is better to make a class out of it.

Answer 3

No need to create a separate object for FuelBrand for every FuelStation

Either approach has the same number of objects - you either have N FuelBrand objects, or N string objects, N being either the number of brands or the number of stations depending whether you reuse the objects or not. So that argument is specious.

I would tend to represent each table with an class, since it does make it explicit that the brand is a brand rather than another thing. It also caters for different brands with the same name, which the relational schema allows, even though it's not very likely.