How to organize the structure of two enumerations with a many-to-many relationship between them in terms of application and class architecture?

Question

I have a CarBrand enumeration:

 public enum CarBrand { BMW, MERCEDES, VOLKSWAGEN, AUDI, FORD, OPEL } 

and CarBodyType enumeration:

 public enum CarBodyType { SEDAN, MINIVAN, VAN } 

Relations between them are many for many . That is, the car brand can have several options for the type of car body, and the type of car body has several brands.

How to define such an entity-relationship model in my code with these enumerations?

Perhaps I need to create a field in each enumeration as a set parameterized by another enumeration?

 public enum CarBrand { BMW, MERCEDES, VOLKSWAGEN, AUDI, FORD, OPEL; private Set<CarBodyType> bodyTypes; public Set<CarBodyType> getBodyTypes() { return bodyTypes; } public void setBodyTypes(Set<CarBodyType> bodyTypes) { this.bodyTypes = bodyTypes; } } 

and

 public enum CarBodyType { SEDAN, MINIVAN, VAN; private Set<CarBrand> brands; // getter and setter } 

This is a good decision? Or would it be better to implement such a relationship through a third connection object? If so, what should it be? How should this object be designed and what fields should it contain?

Answer 1

It is almost certainly not the case that a body like has a brand. Most likely, it is not true that the brand “has” a body type. What you most likely want to model is a separate set of intersections of the allowed body types of each brand.

This is you most likely want a Vehicle that has a body type and brand:

 public class Vehicle { private CarBrand brand; private CarBodyType body; ... } 

and create Vehicles, each of which combines one model.

In response to the comment

For example, what about this case ? If the book and the author are listings.

I don't think the book / author example works for listings (and maybe your use of listings is at the heart of the problem). The number of books and authors is open; you will not model books or authors using a closed enumeration. Moreover, it is true that each book has one or more authors, while each author is only an author in the context of writing one or more books (otherwise it is just a person who wants to become an author).

In relational modeling of books and authors, you will have a Book table, an Author table, and a separate BookAuthor relationship BookAuthor , which was a combination of foreign keys with the Book and Author tables. In object terms, change the word "table" to "object", although in the object model you probably replace the BookAuthor table BookAuthor set of authors in each book and / or the set of books for each author.

Answer 2

The wrong practice is to have circular dependencies like this.

If you need to maintain this relationship, save it in a separate class that avoids rounding.

Answer 3

Then your CarBrand class CarBrand be a more complex structure called Enum. It could be a value type with some kind of ID card inside:

 class CarBrand { static Set<CarBrand> AllBrands; //replacement for CarBrand enum static Set<CarBodyType> GetTypes(CarBrand brand) { /* search this.AllBrands here */} static Set<CarBrand> GetBrands(CarBodyType type) { /* search this.AllBrands here */} /*specify types per brand */ Set<CarBodyType> bodyTypes; } 

If you prefer to use the CarBrand enumeration, this can also be done as an explicit third relationship structure. Enter an association class:

 class CarBrandTypePair { CarBrand, CarBodyType, } 

and the rest should be like the static part of the CarBrand sample above.

The first way is probably more extensible: you would add some other brands in the future. In the second approach, you should add increasingly simple associations.