|
|
Good ideas about the default values. And C# actually does have named paramaters. So, if they all have default values, you could just pass in a few that need to be set.
|
|
|
|
|
Good to know that named parameters were actually implemented. At my job, we're still using VS 2008, so I wasn't aware that they had taken my advice!
|
|
|
|
|
 You should really try and get them to update or you should go somewhere else. That sound ridiculous to still be using VS2008.
|
|
|
|
|
Yeah, I know. But it's about the only job available in my relatively small city, and I'm nearing retirement anyway, so I'm basically just playing out the clock...
|
|
|
|
|
I strongly prefer the code your prefer.
Putting all of those properties as separate parameters of a method is something I was forced to do by someone who got his code from a glorious "whitepaper", and has resulted in hours added on to debugging when one of the parameters is wrong in some way, and has resulted in unnecessarily lengthy code calling those methods for every property even when only one or two properties need to be set.
|
|
|
|
|
You could propose an option 3, that has an object with all the items that need to be passed in. According to Martin Fowler, too many options passed into a constructor is a code smell.
Quote: A large list of construction parameters, like any large parameter list, is a CodeSmell. Usually when I see these I find that many of the parameters are DataClumps and should be replaced by their own object. Having said that it's not unusual for constructor methods to have more parameters than other methods - but they are a good place to spot data clumps.
Martin Fowler - Constructor Initialization
|
|
|
|
|
I believe there are reasons for either style and I don't mean a simple preference by the developer.
The first style allows you to initialise an object with some default values and gradually fill its properties with desired non-default values. Also it allows you to change those values over time to reflect changes in how the class (or another dependent class) should behave. You can see that in any visual component for UWP/WPF/ASP.NET. Meanwhile, the second style creates a kind of immutable object (it can only be read although its properties can still be changed due to internal operations, if any). Changes to this data may not be desired due to e.g. the intended design of the application (or API) or legal reasons.
If you must follow the second style with a class with so many constructor arguments (with which I agree it might be a code smell), I'd recommend creating a Builder for the object. MyFooClass in this example seems to be one which might actually hint at why the guy wanted you to change the code style; perhaps he thought you were trying to create in MyFooClass a Builder for FooDto and wanted you to make it so both classes don't repeat themselves. Anyway, I'd recommend approaching the guy with an open mind to try and understand his motivations for requesting the style change; it may either enhance your knowledge of the application or the guy you're working with.
[UPDATED] Both Dan's or Marc's answers offer a great alternative to avoiding so many arguments on the constructor. I'd also check if you could go either way.
- Leonardo
modified 31-Oct-18 12:49pm.
|
|
|
|
|
I personally don't like either option. Why create two classes that duplicate the same information. I would create a property in MyFooClass to point to FooDto. Or better yet, inherent MyFooClass from FooDto.
|
|
|
|
|
FooDto could be final for all we care. its whole intent, purpose, life cycle, is to turn Data into JSON and vice versa. Nothing more....
mm.. I'd like the idea of justsharing my own internal status class... but that won't fly either.. plus I have been forced to take in some dependency that prevent having these internal status in shared library.. So I do need to duplicate them in contract library upon which I depend
|
|
|
|
|
To quote Alan Perlis: If you create a function with 10 arguments, you probably missed one.
|
|
|
|
|
Option 2.
There should never be a possibility where an object can get constructed without it being initialized properly. Making them mandatory or optional parameters to a constructor achieves that, and the compiler will find every last place where someone has initialized the object incorrectly. Not only that, it'll run very early in the development process, ensuring that the developer that just added the new parameter has all those details still fresh in their head when the bugs are found. What better unit test could you possibly hope for?
The other aspect of how you've been asked to rewrite that code is also a better practice -- you've been asked to reduce the public interface by removing the property setters. This just ensures that nobody can reach into your object and twiddle those properties after it's been constructed. If someone needs that, they can change your code, but hopefully they will evaluate whether there's a better that ensures the object can't be put in a bad state. If the object can't ever be put in a bad state, you can't have bugs because someone was sloppy.
|
|
|
|
|
|
We're actually mostly scared of the drop bears.
cheers
Chris Maunder
|
|
|
|
|
That's one in the last panel, I think. 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
And I can't read any of it, "because the authenticity of the received data could not be verified". I guess it has to do with invalid SSL certificates or something in that direction.
|
|
|
|
|
In a recent survey, 2/3 of the lions said that they were happy to serve as King of the Forest, while another 1/9 thought it was way too much responsibility. If 14 lions gave one of these two answers, how many lions were surveyed in total?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
|
Are you on drugs?
Lions can't talk.
|
|
|
|
|
Why has nobody explaind that to our housecats?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Your housecats try to talk to lions? 
|
|
|
|
|
No. They all thought they were lions.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Ours thinks he is a tiger. A 17 foot long tiger.
The evidence is against him, but I applaud the enthusiasm.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
My granny yawned , thought about it for a second and said 18. 
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
18 lions + 1 wolf.
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
