|
|
|
|
|
by Archelaos
135 days ago
|
|
Strong static type checking is helpful when implementing the methodology described in this article, but it is besides its focus. You still need to use the most restrictive type. For example, uint, instead of int, when you want to exclude negative values; a non-empty list type, if your list should not be empty; etc. When the type is more complex, specific contraints should be used. For a real live example: I designed a type for the occupation of a hotel booking application. The number of occupants of a room must be positiv and a child must be accompanied by at least one adult. My type Occupants has a constructor Occupants(int adults, int children) that varifies that condition on construction (and also some maximum values). |
|
Or, you could do what I did when faced with a similar problem - I put in a PostgreSQL constraint.
Now, no matter which application, now or in the future, attempts to store this invalid combination, it will fail to store it.
Doing it in code is just asking for future errors when some other application inserts records into the same DB.
Business constraints should go into the database.