[HN Gopher] Code Smell: Primitive Obsession [video]
___________________________________________________________________
Code Smell: Primitive Obsession [video]
Author : DanielBMarkham
Score : 12 points
Date : 2021-09-25 09:23 UTC (1 days ago)
(HTM) web link (danielbmarkham.com)
(TXT) w3m dump (danielbmarkham.com)
| stevebmark wrote:
| 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 wrote:
| wdym user's world?
| dan-robertson wrote:
| 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.
| [deleted]
| stevebmark wrote:
| 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]
| cratermoon wrote:
| See also https://wiki.c2.com/?StringlyTyped
| imoverclocked wrote:
| 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 wrote:
| 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.
| michaelfeathers wrote:
| "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
| zokier wrote:
| Isn't this another variation of "parse, don't validate"?
| dreyfan wrote:
| Code Smell: Making Everything an Object
| [deleted]
| pwdisswordfish0 wrote:
| Don't use broken Regexes like this one to validate email
| addresses.
| aranchelk wrote:
| 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.
___________________________________________________________________
(page generated 2021-09-26 23:00 UTC)