Primary keys, IDs, references. The first attribute we add to our objects. They don't exist in the real world.
Bijection Principle Violation.
Reference object to objects.
Build a MAPPER.
Only use keys if you need to provide an external (accidental) reference. Databases, APIs, Serializations.
Use dark keys or GUIDs when possible.
If you are afraid of getting a big relation graph use proxies or lazy loading.
Don't use DTOs.
Code Smell 40 - DTOs
Maxi Contieri ⭐⭐⭐ ・ Dec 2 '20 ・ 2 min read
This is a design policy.
We can enforce business objects to warn us if we define an attribute or function including the sequence id.
Ids are not necessary for OOP. You reference objects (essential) and never ids (accidental).
In case you need to provide a reference out of your system's scope (APIs, interfaces, Serializations) use dark and meaningless IDs (GUIDs).
Code Smell 20 - Premature Optimization
Maxi Contieri ⭐⭐⭐ ・ Nov 8 '20 ・ 2 min read
What is (wrong with) software
Maxi Contieri ⭐⭐⭐ ・ Oct 8 '20 ・ 4 min read
The One and Only Software Design Principle
Maxi Contieri ⭐⭐⭐ ・ Oct 13 '20 ・ 5 min read
Photo by Maurice Williams on Unsplash
All problems in computer science can be solved by another level of indirection.
Top comments (2)
Simple answers don't always fit complex problems.
Semantic keys are not always a code smell in the wild.
I've found the lack of them when needed for performance and scale resilience can be a problem. They are the first thing I sniff for in a relational database and some shared object structures.
Of course. But then we are talking about data and performance(accidental) In my article I was focusing solely on behaviour (essential)