6 ms·

Code Smell: Primitive Obsession [video]

20 points by DanielBMarkham 5y ago

cratermoon 5y ago
See also https://wiki.c2.com/?StringlyTyped https://wiki.c2.com/?StringlyTyped
- imoverclocked 5y ago
  So much this. Strings can contain anything… json, JavaScript, invalid utf8, you name it! I’ve seen type systems (poorly) re-implemented in already typed languages around string usage.
  - cratermoon 5y ago
    Full disclosure: as a young programmer I contributed to and was co-responsible for promoting an in-house Java library which misused strings in exactly this way. I didn't know any better, I was working with some people who only knew SQL and in the relational schema every column was type char or varchar.
    - imoverclocked 5y ago
      I too have gone back and looked at code only to think, “what idiot wrote this?!” … when I slowly realize that I’m the only author. Experience can’t be taught. :)
- michaelfeathers 5y ago
  “The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information.” - Alan J. Perlis
  - cratermoon 5y ago
    At least today we have string types which know their own length and character set. Two strings walk into a bar and sit down. The bartender says, "So what'll it be?" The first string says, "I think I'll have a beer quag fulk boorg jdk^CjfdLk jk3s d#f67howe%^U r89nvy~~owmc63^Dz x.xvcu" "Please excuse my friend," the second string says, "He isn't null-terminated."
deleted 5y ago
[deleted]
zokier 5y ago
Isn't this another variation of "parse, don't validate"?
- eezing 5y ago
  Except that your strings are no longer strings. DDD value objects, thanks but no thanks.
dreyfan 5y ago
Code Smell: Making Everything an Object
stevebmark 5y ago
Early on in the video they talk about designing specific type of "Customer" types that reflect the domain of the business, such as reflecting that Customers must be at least 21 years old to use the product. Be very careful applying Domain Driven Design to your programs. To make software durable and survive long term, as much of the domain logic should be pushed into the user's world, and not locked into your code, poisoning it. You shouldn't need an engineer to make your program support onboarding a new type of Customer. That shouldn't require a new class and a new type. Think of the "extreme" anti-DDD software of spreadsheets. Almost every company in the world uses Excel or Google Sheets or some spreadsheet software. The business domain stays in user land, as it should. The more you use DDD, the more you poison and lock in your software into business rules that can limit the flexibility of the business, and force engineers to get involved for the business to try new things.
- asadawadia 5y ago
  wdym user's world?
- dan-robertson 5y ago
  A ‘new type of customer’ could mean all sorts of things. In my mind it means a new sort of business for the company. It doesn’t seem crazy to me that software work should be required for a new kind of business—there would surely be new contracts needed from the legal department as well as different marketing and possibly accounting or billing. And if nothing new is needed, perhaps they aren’t really a new kind of customer after all. The DDD way to handle customers who must be over 21 is to have some type for the input of your business process, say customeOver21, and some function to which you give a customer and get back either a corresponding customerOver21. This makes sense if the kinds of customer are totally different but if, for example, you are a shop and some products may only be sold to customers over 21, then you probably want some different logic instead (eg each item may correspond to some requirements on the customer (or even some other state, e.g. max 2 of this item per customer) and these requirements can then be unioned together for all the items in a cart.) But however you do things, I think you should work hard to ensure that it is easy to avoid accidentally treating, eg, a customer id as a transaction id or SKU id.
- 5y ago
stevebmark 5y ago
This video format is challenging to watch. It's one presenter with a (co-host? I haven't seen this podcast/show/whatever before), and they keep going off into "oh you know what that reminds me of". The tangents seem like they (or at least the co-host) is showing off "this is what I know" and it makes the main message really hard to follow. I'm 30 minutes in and I'm giving up. Two people talking over each other takes away from the presentation / main thread.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
pwdisswordfish0 5y ago
Don't use broken Regexes like this one to validate email addresses.
aranchelk 5y ago
Interestingly, this is OOP advice that if generalized, applies pretty directly to functional programming. In my mind the fundamental problem with using primitives is you’re overloading the meaning of existing types, you can use them in the wrong places and the type checker of course can’t catch those misuses. You’re stuck with functions/methods that may be applied even if they don’t make sense. This is very much analogous to failure to use newtype wrappers in Haskell-like languages to differentiate distinct uses of existing types. Same symptoms, same underlying conceptual issue.
mikewarot 5y ago
>Name = name; This is so wrong, why not use newname for a new name value? Being clever like this is exactly why I stay away from C/C++ and other case sensitive languages. They encourage pendantry.

cratermoon 5y ago

See also https://wiki.c2.com/?StringlyTyped https://wiki.c2.com/?StringlyTyped

imoverclocked 5y ago
So much this. Strings can contain anything… json, JavaScript, invalid utf8, you name it! I’ve seen type systems (poorly) re-implemented in already typed languages around string usage.
- cratermoon 5y ago
  Full disclosure: as a young programmer I contributed to and was co-responsible for promoting an in-house Java library which misused strings in exactly this way. I didn't know any better, I was working with some people who only knew SQL and in the relational schema every column was type char or varchar.
  - imoverclocked 5y ago
    I too have gone back and looked at code only to think, “what idiot wrote this?!” … when I slowly realize that I’m the only author. Experience can’t be taught. :)
michaelfeathers 5y ago
“The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information.” - Alan J. Perlis
- cratermoon 5y ago
  At least today we have string types which know their own length and character set. Two strings walk into a bar and sit down. The bartender says, "So what'll it be?" The first string says, "I think I'll have a beer quag fulk boorg jdk^CjfdLk jk3s d#f67howe%^U r89nvy~~owmc63^Dz x.xvcu" "Please excuse my friend," the second string says, "He isn't null-terminated."

deleted 5y ago

[deleted]

zokier 5y ago

Isn't this another variation of "parse, don't validate"?

eezing 5y ago
Except that your strings are no longer strings. DDD value objects, thanks but no thanks.

dreyfan 5y ago

Code Smell: Making Everything an Object

stevebmark 5y ago

Early on in the video they talk about designing specific type of "Customer" types that reflect the domain of the business, such as reflecting that Customers must be at least 21 years old to use the product. Be very careful applying Domain Driven Design to your programs. To make software durable and survive long term, as much of the domain logic should be pushed into the user's world, and not locked into your code, poisoning it. You shouldn't need an engineer to make your program support onboarding a new type of Customer. That shouldn't require a new class and a new type. Think of the "extreme" anti-DDD software of spreadsheets. Almost every company in the world uses Excel or Google Sheets or some spreadsheet software. The business domain stays in user land, as it should. The more you use DDD, the more you poison and lock in your software into business rules that can limit the flexibility of the business, and force engineers to get involved for the business to try new things.

asadawadia 5y ago
wdym user's world?
dan-robertson 5y ago
A ‘new type of customer’ could mean all sorts of things. In my mind it means a new sort of business for the company. It doesn’t seem crazy to me that software work should be required for a new kind of business—there would surely be new contracts needed from the legal department as well as different marketing and possibly accounting or billing. And if nothing new is needed, perhaps they aren’t really a new kind of customer after all. The DDD way to handle customers who must be over 21 is to have some type for the input of your business process, say customeOver21, and some function to which you give a customer and get back either a corresponding customerOver21. This makes sense if the kinds of customer are totally different but if, for example, you are a shop and some products may only be sold to customers over 21, then you probably want some different logic instead (eg each item may correspond to some requirements on the customer (or even some other state, e.g. max 2 of this item per customer) and these requirements can then be unioned together for all the items in a cart.) But however you do things, I think you should work hard to ensure that it is easy to avoid accidentally treating, eg, a customer id as a transaction id or SKU id.
5y ago

stevebmark 5y ago

This video format is challenging to watch. It's one presenter with a (co-host? I haven't seen this podcast/show/whatever before), and they keep going off into "oh you know what that reminds me of". The tangents seem like they (or at least the co-host) is showing off "this is what I know" and it makes the main message really hard to follow. I'm 30 minutes in and I'm giving up. Two people talking over each other takes away from the presentation / main thread.

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]

pwdisswordfish0 5y ago

Don't use broken Regexes like this one to validate email addresses.

aranchelk 5y ago

Interestingly, this is OOP advice that if generalized, applies pretty directly to functional programming. In my mind the fundamental problem with using primitives is you’re overloading the meaning of existing types, you can use them in the wrong places and the type checker of course can’t catch those misuses. You’re stuck with functions/methods that may be applied even if they don’t make sense. This is very much analogous to failure to use newtype wrappers in Haskell-like languages to differentiate distinct uses of existing types. Same symptoms, same underlying conceptual issue.

mikewarot 5y ago

>Name = name; This is so wrong, why not use newname for a new name value? Being clever like this is exactly why I stay away from C/C++ and other case sensitive languages. They encourage pendantry.