Can you give a clear example on “thinking in types” approach ?
https://refactoring.guru/smells/primitive-obsession
Let's say, for example, that we need to handle distances in on our code with different units (meters and inches, for example). I've seen code bases that use integers or floating points for this and it's always confusing and error-prone what is the unit. In fact, you could accidentally use some other values (money) as distances.
Instead, if your programming language allows this, you could define a type Distance and make sure that all the code that handles distances only use this Distance type. Everyone is forced to think about distances when maintaining the code, conversions routines are implemented and instantiated in one place etc.
parent, student, address
While the unskilled would:
parentfirstname, parentlastname, parentaddress1, .... studentpostcode
Incidentally, that's another thing about the difference between actually-skilled programmers and "pretenders": the former will always explain something in very simple terms, while the latter will try to use as much abstract and vague technical-sounding terms as possible.
A perhaps simpler, perhaps better example: Floats are lossy, but transactions in currency cannot be. An inexperienced developer might make the mistake of representing currency values as floats, while a more experienced developer would know to use some sort of BigDecimal. But the more experienced developer is still making a fatal error. Currencies have units, but BigDecimals do not. While BigDecimals can be added together, it is not meaningful to add Dollars to Euros. A developer who is "thinking in types" will define a numeric type for Dollars and a numeric type for Euros that cannot be added together.
If the transaction value can be superior to 21 thousands (or if the code is deployed on a 32bit system, or if i want my floating point value high), maybe i would use a long, and probably an enum to keep track of the different currencies the second time i pass over the module. Maybe even a field (or a macro outside the struct) with the floating point value (4 to 6 seems good enough tbh).
I'm an "int, char, loop" guy, at least at first, especially if i have to write something from scratch. Thinking in "object" or "type" makes me uncomfortable except when it is for interfaces (but GUI makes me uncomfortable too, so...). I feel this is inefficient, and that well-defined/organized data should not need such complex handlers in most cases.
> (via @userbinator) Yes, I'd call that "grouping related data (and functions, if you're using OOP) together"; no need to obfuscate the matter by saying "thinking in types".
There's some nuance between what you two are saying. IMO the "related" vector (depending on the definition) is a potential driver of what I refer to as the "Single Class Application". Back to the OP example, the Shipment and Notification are related to an Order. The simple "related" question says it's ok to implement all of those in one class instead of three.
The real questions to ask are about the specific relationship of possession. Does this attribute BELONG to this object or another? Does this object DO this action? These go a little beyond the typical OOP mantra of abstraction and encapsulation.