this post was submitted on 18 Jul 2024
38 points (97.5% liked)

Programming

17477 readers
229 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
 

With this post I've taken a bit more of a practical turn compared to previous Post-Architecture posts: It's more aimed at providing guidance to keep (early) architecture as simple as possible. Let me know what you think!

you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 4 points 4 months ago (1 children)

No, that's my point. Providing the builder factory as an abstract way to construct an entity, it is an abstraction. It removes you from the actual detail, that's an abstraction. But it also introduces extra complexity, which in turn negates the value of the abstraction.

In reality, the intention is an abstraction, the result is often enough a bad abstraction that introduces more complexity and adds indirection.

[โ€“] [email protected] 0 points 4 months ago

@agressivelyPassive if you routinely call indirections abstractions, then 'premature abstraction is the root of all evil' holds. If you separate the two concepts, you might think differently.

If my team's codebase had a business logic class that had a concrete dependency on an EntityBuilderFactory, I'd vomit a little, but I wouldn't delete it (can't piss off too many people all the time). But I would route around the damage by allowing the class to depend on the EBF *or* something else.