5 ms·
> The advantage is that you end up with more reusable methods. Like "shower" or "Prepare food" that can be used elseware. But that is exactly the author of thi
by jonnytran 18y ago
> The advantage is that you end up with more reusable methods. Like "shower" or "Prepare food" that can be used elseware.
But that is exactly the author of this post's point. When you have something that is more reusable, like "Prepare food", you end up using it in multiple situations, increasing the complexity of relationships between components.
So for example, when you want to make sure you eat bacon with breakfast, you can't just add "Prepare bacon" to "Prepare food" b/c now the "Prepare food" task may be executed in "Have lunch", "Have dinner", and "Have midnight snack". And you don't want bacon with your midnight snack! Instead, you have to add a parameter to the task, some conditional, add parameter to each call site, etc... i.e. more complex.
- xenophanes 18y agoRe-using showering code is less error prone than maintaining separate copies of showering code!
- pdubroy 18y agoNot necessarily. When you make a single change to a shared function, you might cause undesired changes to other code that calls that function.
- xenophanes 18y agoSo you're advocating copy/paste style coding, and telling us it is less buggy? Seriously? And without some extensive explanation? What about the studies showing number of bugs is proportional to lines of code? Your way adds more lines of code.
- pdubroy 18y agoNo, I'm saying that putting common code in a separate method is not necessarily -- as in, "as a logical result or consequence" -- less error-prone. I'm not advocating cutting and pasting huge blocks of code everywhere, but a 1-line calculation duplicated in 4 spots is probably okay.
- deleted 18y ago[deleted]
- smhinsey 18y agoIt probably is okay to duplicate a calculation 4 times, all other things being equal. At the same time, I'd say it's probably a sign of other problems. If you need to reuse a calculation, that calculation is part of your application's domain (using the term loosely) and should be represented there, rather than being embedded inside scenario-appropriate parts of the system.
- silentbicycle 18y agoThe function may be doing too much, then. It would probably contains several reusable pieces if you broke it up differently.
- silentbicycle 18y agoIs "prepare bacon" necessarily part of "prepare food" itself, though? Rather than hardcoding preparing bacon as a stage of food prep, it's probably more maintainable to have the kinds of food passed in (as a list, a Menu object, whatever) - what you're cooking strongly influences the entire process. washHands() for f in val(foods) do coroutine.init(f) ... end waitUntilDone() if (not aLazyGit) then doDishes() end Really, cooking usually involves interwoven stages of things like setting water boiling, whisking a roux, kneading dough, chopping peppers, etc. Tacking on "...and make bacon" at the end of all cooking batches doesn't make sense. Instead, break prepareFood() down further into operations such as boilWater(vol), preheatOven(temp), etc.; Those should be reusable, barring unusual circumstances (e.g. boiling water at high altitudes). Without a lot of specialization via arguments, prepareFood() is too coarse an abstraction, about as vague as doTaxes().