3 ms·
Don't do this! OP's version is better! It might be "fine", but you don't gain anything here while introducing both indirection and coupling. DRY is _not_ about
by dgb23 4y ago
Don't do this! OP's version is better!
It might be "fine", but you don't gain anything here while introducing both indirection and coupling. DRY is _not_ about data repetition. Data repetition is fine.
Alice and Bob having the same birthday is coincidental. And even if they are actually twins, you rather say that they are twins separately.
In your example you are just preserving keystrokes, but you don't say anything of value with 'pizza_base'. You haven't shown that 'pizza_base' is worth keeping track of or even mentioning.
A pepperoni_pizza with thick crust or extra cheese is still a pepperoni_pizza. A hawaiian_pizza's sauce being tomato doesn't relate to a pepperoni_pizza's sauce.
When coding data, just be explicit, verbose and keep it simple. Our text editors, IDEs and database APIs have affordances to change data in bulk. Those things are orders of magnitude easier if your data is simple, dumb and not complected.
- amannm 4y agoAgreed, I'm scared of working with programmers that aren't able to see this. There's no point of capturing the "base pizza" concept. Nobody is impressed here. My eyes have to flick around so much more. Additionally, the programmer is decreasing the ease with which the codebase can adapt to market demand due to their likely overconfidence in their understanding/visibility over the market the product is being built for.
- n4r9 4y agoWith only 2 types of pizza with the same base, I'm inclined to agree. But if there are more, or a strong potential for more (as there is with pizza), I'd argue that this factoring allows simpler implementation of new pizzas as well as easier comparison of existing pizzas.
- dgb23 4y agoI think volume is almost deceptive. It seems like we’re doing useful compression, but if we’re not careful we introduce complexity and indirection that is not based on actual needs. So we essentially code ourselves into a corner. There are circumstances when your version is actually better: when pizza_base has a real meaning in your domain, outside of the code representing it. The chefs, accountants and so on use the term day to day, and might even have specific pricing or techniques around it. Then pizza_base is an actual thing that you want to represent in some way. However it could also just be a function, which derives from pizza_base from your raw data. Like is_pizza_base(). I would prefer that in general. There is nothing wrong with dumb, raw, data. It gives you leverage and frees you from coupling.
- im3w1l 4y agoI disagree because his abstraction matches the domain. You will literally see menus designed around the assumption that a not-folded thin (or thick, for some venues I guess) pizza with cheese and tomato sauce is the default, that some pizzas deviate from.