The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Suppose you had a class containing a public member email. If that member were assigned a bogus value someplace, and then that value was read/used someplace else, a problem would surface. In this instance, your class should be in charge of its members: make email private, and use getter/setter methods. In your setter method, the email address could be validated, and rejected if found to be incorrect. The places that then call the getter method would not have to worry about bogus email addresses.
"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
If they have access to the code, then make them private. This gives that object better encapsulation, allowing it to more easily be extended, refactored or completely rewritten without affecting the rest of the code. Your coworkers can always increase the interface to the object by making them public if they need to, but more likely they will consider exactly what access is actually needed instead of just making internal implementation public.
The down side to having a lot of members public is that not only do the users have those buttons and knobs to turn, they may think they have to. Every public member is a decision for the user: do I have to set this, or does it default? Is the default what I want? When do I have to set it?
You need to decide if your typical use case needs the flexibility. If it doesn't, then I'd argue that those members should be private.
Yes it's a programming question, but wait a moment, I am NOT asking to solve any problem here, I am asking to select your favourite of 2 options.
I think what they want me to do here at work is disgusting. I have to suck it up anyway, since it's the guy who accepts pull request that tells me to do it, period. But I am curious whether or not I am in good company with my prejudice.
It's about DTO, constructors with zillion of parameters and all private properties.
code I prefer and put in my pull request, with 24 properties (i.e large number of properties)
Of course, using reasonable defaults would prevent you from having runaway parameter lists for your constructors, and all you have to do is set the properties that need to be changed.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
I would go for option 1.
I would also look at having some sort of mapping functionality so that the values can be populated 'automatically' by passing the DTO to some form of orchestrator together with the data source to populate it.
The following in option 2 is a huge code smell:
public FooDto(T1 value1 /** 24 values later */, T24 value24)
I have done this myself in the past but it is generally accepted nowadays that a large number of parameters in a signature is a bad idea.
“That which can be asserted without evidence, can be dismissed without evidence.”
Agree that Too much parameters in Option 2 is terrible one. Too much parameters require changes in other places(Ex: Business Logic layer, Code-behind, etc.,) when you need to remove/add parameters later.
that's a good one!
in fact it might the easiest way how to go about it.. by that I mean I can implement that with some quick copy paste...
whereas implementing the constructor is going to be manually intensive and bug prone!