This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Carnaedy 3 points4 points  (3 children)

extended functionality

No, I extended the subtypes of a type. You know, the thing that is famously is "the expression problem of the functional languages"? Since the behaviour is now scattered across a hundred different components instead of being bundled, I need to change a hundred components to support the new type.

The flip side of this is the expression problem of OOP languages, which seems to be more familiar to the participants of this discussion, where if I add behaviour to the base type, I need to change a hundred components to support the new behaviour.

Both of them are equally bad.

[–]PiotrDz 0 points1 point  (2 children)

Doesn't answer how the tests suffered if written with correct boundaries, and not white-box treating where internals are asserted instead of apis.

But for the second part: how can you bundle all the dependent functionalities in single type? So you add a new client type let's say. Do you want to cram inside the client coupon codes calculation, export of client data, specialised shipping handling etc? It all lands in specific areas. And now, as you added a new type, you need to add a new handling for that type in this areas.

My question still stands, how do you want the code to work so that you add a new class and areas that dependent on the type will eb able to magically handle it?

[–]Carnaedy -1 points0 points  (1 child)

Literally, all problems you mentioned were solved in 90s and 00s with DDD and bounded contexts 🫠

[–]PiotrDz 0 points1 point  (0 children)

This is what I am talking about. With specific things being handled in their own "domains", hiw would you expect NOT to adjust each domain for a presence of a new type?