3 ms·

Surely you'd remove repetition by doing this instead: hawaiian_pizza = { crust: "thin", sauce: "tomato", cheese: "regular",

by strken 4y ago

Surely you'd remove repetition by doing this instead: hawaiian_pizza = { crust: "thin", sauce: "tomato", cheese: "regular", toppings: ["ham", "pineapple"] } pepperoni_pizza = { crust: "thin", sauce: "tomato", cheese: "regular", toppings: ["pepperoni"] } def make_pizza(pizza): requests.post(PIZZA_URL, pizza) This isn't better just because it's DRY, it also keeps the data separate from code, which makes it usable elsewhere. Defining fifty different types of pizza inline inside functions is a strange choice, because it tightly couples your pizza definitions to your pizza-making. What if you want to answer a question like "how many thin crust pizzas do we sell?"

n4r9 4y ago
Even better IMO (although devolving into pseudo code): pizza_base = { crust: "thin", sauce: "tomato", cheese: "regular", toppings: [] } hawaiian_pizza = pizza_base { toppings: ["ham", "pineapple"] } pepperoni_pizza = pizza_base { toppings: ["pepperoni"] } def make_pizza(pizza): requests.post(PIZZA_URL, pizza)
- kitkat_new 4y ago
  this could(!) be coincidental code duplication
- 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 ago
    Agreed, 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 ago
    With 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 ago
      I 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 ago
    I 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.
battlebeansbogs 4y ago
Came here for this. Why would your pizza definitions be in code at all.. Python is my favourite language but boy does it make people crazy, imagine recompiling your an app because restaurant A wanted to add a new pizza definition? To speak to the wider point about DRY, it's a guiding principle for abstraction. If you have two kinds of abtractions for your method, one leads to code repetition, the other does not. Generally favour the does not. The fact that you should have additional rules, like you shouldn't need rabbit hole debugging (jumping through a million files/objects) to understand core behaviour is not a failure of a useful guiding principle
thrown_22 4y ago
Not to mention it lets you do things like: mixed_pizza = { crust: [["thin"], ["thick"]], sauce: [["tomato"]], cheese: [["regular"]], toppings: [["beef"], ["pineapple", "pepperoni"]] } Where you offload the logic of making multi-topping pizzas into the data.

by strken 4y ago

n4r9 4y ago

Even better IMO (although devolving into pseudo code): pizza_base = { crust: "thin", sauce: "tomato", cheese: "regular", toppings: [] } hawaiian_pizza = pizza_base { toppings: ["ham", "pineapple"] } pepperoni_pizza = pizza_base { toppings: ["pepperoni"] } def make_pizza(pizza): requests.post(PIZZA_URL, pizza)

kitkat_new 4y ago
this could(!) be coincidental code duplication
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 ago
  Agreed, 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 ago
  With 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 ago
    I 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 ago
  I 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.

battlebeansbogs 4y ago

Came here for this. Why would your pizza definitions be in code at all.. Python is my favourite language but boy does it make people crazy, imagine recompiling your an app because restaurant A wanted to add a new pizza definition? To speak to the wider point about DRY, it's a guiding principle for abstraction. If you have two kinds of abtractions for your method, one leads to code repetition, the other does not. Generally favour the does not. The fact that you should have additional rules, like you shouldn't need rabbit hole debugging (jumping through a million files/objects) to understand core behaviour is not a failure of a useful guiding principle

thrown_22 4y ago

Not to mention it lets you do things like: mixed_pizza = { crust: [["thin"], ["thick"]], sauce: [["tomato"]], cheese: [["regular"]], toppings: [["beef"], ["pineapple", "pepperoni"]] } Where you offload the logic of making multi-topping pizzas into the data.