This topic is for the [Introduce Parameter Object] exercise in the [Refactoring] trail. Post any questions, corrections, or pointers you have to share with other Upcase subscribers.
[Introduce Parameter Object]: https://exercises.upcase.com/exercises/introduce-parameter-object
[Refactoring]: Refactoring Code | Code Refactoring Online Tutorial by thoughtbot
Hello, I wanna know if Value objects are exception to Sandi Metz’ rule of 3 arguments per method, since in the problem I ended with a solution with more than 3. If not then how would you implement it. Thanks!
You could introduce a Dimensions class to encapsulate the width, height and length values. (This would then give a ideal home for the volume method).
Thanks for sharing “Sandi Metzs’ rules” as I learned a few tips from Thoughtbot’s blog post! Let’s check, but I thought its “four method arguments” and not three?
It is indeed three as written on Sandi Metz' Rules For Developers
But the actual number is a somewhat arbitrary rule of thumb. In this case, grouping together width, height and length seems intuitive to me.
One of the best things about the Sandi Metz Rules (and there are many great things about them!) is that Sandi trusts you to exercise your own judgement. Creating a constructor with four arguments would be a code smell, but when you look at the alternatives (not keeping volume co-located with other dimensional attributes), they all entail “smellier” code.
If you find yourself breaking a rule more often than “very infrequently” it’s a sign that you probably need to adjust your overall approach.
I am confused about the premise of this refactor, as explained in the video or as demonstrated in this example. While a large number of parameters may be awkward, it seems that we are just moving this awkwardness from the instantiation of one method to the instantiation of a new method.
If the same set of parameters are used in several methods, then there would be more value to this new object. This is how Introduce Parameter Object is explained here:
Also, if we factored out a subset of parameters that “go together” (such as “Dimensions” as suggested by @andyw8) then that might make the chunks smaller – but the exercise instructions clearly request that ALL parameters be refactored into the new object.
I guess that the only value I see of the refactor in this example is to allow us to move the volume method out of the ShippingCalculator into the new class as @andyw8 suggested . But wouldn’t that type of refactor be just as valuable regardless of the number of parameters in the original object? The explanations I’ve seen for Introduce Parameter Object seem to say that this refactor is to be used when the parameter list is too long.
Is there more explanation I’m missing because I did not buy the Ruby Science book?