C# code survey
-
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)
public class FooDto
{
public T1 Property1 { get; set; }
// ....
public T24 Property24 { get; set; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto() { Property1 = property1, //.... Property24 = property24, }; }}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto(property1 /\*\* \*/, property24); }}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values. Though one could counter argument that we got unit test for just that. At any rate, which of those 2 is your favourite code style?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Of the two choices given, I'd take 1; but would prefer a third option.:
public class FooDto
{
public FooDto(MyFooClass foo)
{
Property1 = foo.property1;
// .....
Property24 = foo.property24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;
}If for some reason I
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
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)
public class FooDto
{
public T1 Property1 { get; set; }
// ....
public T24 Property24 { get; set; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto() { Property1 = property1, //.... Property24 = property24, }; }}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto(property1 /\*\* \*/, property24); }}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values. Though one could counter argument that we got unit test for just that. At any rate, which of those 2 is your favourite code style?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
If you really want to bake their noodle, put all the value maps in Attributes and then have the object built via Reflection such as in this article[^]. It's a super complicated way to do simple tasks :laugh:
if (Object.DividedByZero == true) { Universe.Implode(); }
-
Option 1, but I do see the argument for option 2, especially if the properties are mandatory.
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 -
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)
public class FooDto
{
public T1 Property1 { get; set; }
// ....
public T24 Property24 { get; set; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto() { Property1 = property1, //.... Property24 = property24, }; }}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto(property1 /\*\* \*/, property24); }}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values. Though one could counter argument that we got unit test for just that. At any rate, which of those 2 is your favourite code style?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
public class Foo
{
public class DTO
{
public T1 P1 { set; get; } = P1_default_value;
...
public T24 P24 { set; get; } = P24_default_value;
}public void In(DTO dto)
{
// Set _P* from dto.P*
}public DTO Out()
{
DTO dto = new DTO();// set dto.P\* from \_P\* return dto;}
private T1 _P1;
...
private T24 _P24;
}The DTO object constructs itself with a consistent default set of values. The DTO property accessors are responsible for maintaining consistency of that set. The
InandOutmethods of theFooclass manage its internal state based on accepting or producing a DTO, respectively. This approach lets you do things like this:Foo foo = new Foo();
...
foo.In(new DTO() { P3 = Fred, P17 = Wilma; });
Foo foo2 = new Foo();
foo2.In(foo.Out());Software Zen:
delete this; -
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)
public class FooDto
{
public T1 Property1 { get; set; }
// ....
public T24 Property24 { get; set; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto() { Property1 = property1, //.... Property24 = property24, }; }}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto(property1 /\*\* \*/, property24); }}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values. Though one could counter argument that we got unit test for just that. At any rate, which of those 2 is your favourite code style?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
So option 1 gives you simplicity, whereas option 2 gives you immutability. There are arguments for both, the immutability one being that one DTO can be safely shared by many things as none of them can alter it. With option 1, by rights you need to keep cloning the thing to prevent any badly behaved code messing up the 'master' copy. So there's a memory/performance trade off with all that. You often get that cloning for free through serialization mind. That said, when you wish to change one property on option 2, it becomes a screaming nightmare of reconstructing a new one with one difference in the constructor parameter list. We had option 2, but it was too much to stomach in the end.
Regards, Rob Philpott.
-
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)
public class FooDto
{
public T1 Property1 { get; set; }
// ....
public T24 Property24 { get; set; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto() { Property1 = property1, //.... Property24 = property24, }; }}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto(property1 /\*\* \*/, property24); }}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values. Though one could counter argument that we got unit test for just that. At any rate, which of those 2 is your favourite code style?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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)
public class FooDto
{
public T1 Property1 { get; set; }
// ....
public T24 Property24 { get; set; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto() { Property1 = property1, //.... Property24 = property24, }; }}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto(property1 /\*\* \*/, property24); }}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values. Though one could counter argument that we got unit test for just that. At any rate, which of those 2 is your favourite code style?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
It depends. I use option 2 only for values that are absolutely necessary for the class to work (and that should never be 24 parameters, that's just bad design!). And option 2 is ideal for constructor injection in DI. Other than that, option 1.
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
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)
public class FooDto
{
public T1 Property1 { get; set; }
// ....
public T24 Property24 { get; set; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto() { Property1 = property1, //.... Property24 = property24, }; }}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto(property1 /\*\* \*/, property24); }}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values. Though one could counter argument that we got unit test for just that. At any rate, which of those 2 is your favourite code style?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Could you not just use inheritance and do away with all the property setting?
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass : FooDto
{
// ....
}This exposes properties T1 ... T24 of the base FooDto class but that may or may not be an issue. There are arguments against combining DTOs and inheritance, so without knowing the details of your implementation this may not be appropriate. Part of "knowing the details" of course involves the use of a crystal ball to envisage future changes, but depending on the scenario you can pretty much rule out a lot of potential stuff and, in this case, save yourself a lot of code.
-
Super Lloyd wrote:
select your favourite of 2 options.
I prefer favorite.
Everyone is born right handed. Only the strongest overcome it. Fight for left-handed rights and hand equality.
Down-vote! :-)
Outside of a dog, a book is a man's best friend; inside of a dog, it's too dark to read. -- Groucho Marx
-
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)
public class FooDto
{
public T1 Property1 { get; set; }
// ....
public T24 Property24 { get; set; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto() { Property1 = property1, //.... Property24 = property24, }; }}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto(property1 /\*\* \*/, property24); }}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values. Though one could counter argument that we got unit test for just that. At any rate, which of those 2 is your favourite code style?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Nobody seems to have yet mentioned any other alternatives...one would be passing in a structure with 24 members as an initializer, although in C# that doesn't really eliminate the problem, since you'd have a similar problem with how to initialize the structure. Might be useful tho if you instantiated a lot of these objects with mostly the same parameters. I would never condone instantiating a class without initializing all member data items, but if there are reasonable default values for them, I could see an initializer (or maybe even a few) that initialized all or most of them to default values, and only set one or two to non-default values. Don't ever want to leave values uninitialized, however. Of course, there are those who would say that any object that needs this many initializers is poorly designed and should be refactored. It would be up to the author in each individual case to decide if this is feasible. For my money, this makes a good case for a language feature I've been wanting ever since the days I worked with the ADA language - named parameter lists. Then you could offer default values for all parameters, and let the caller set only the ones (s)he wants to differ from the default values. Of course, you can emulate this now in C#, but it requires 2^n constructors. I've done it with three parameters (eight constructors), but of course it would be impractical with 24.
-
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)
public class FooDto
{
public T1 Property1 { get; set; }
// ....
public T24 Property24 { get; set; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto() { Property1 = property1, //.... Property24 = property24, }; }}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto(property1 /\*\* \*/, property24); }}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values. Though one could counter argument that we got unit test for just that. At any rate, which of those 2 is your favourite code style?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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.
-
Nobody seems to have yet mentioned any other alternatives...one would be passing in a structure with 24 members as an initializer, although in C# that doesn't really eliminate the problem, since you'd have a similar problem with how to initialize the structure. Might be useful tho if you instantiated a lot of these objects with mostly the same parameters. I would never condone instantiating a class without initializing all member data items, but if there are reasonable default values for them, I could see an initializer (or maybe even a few) that initialized all or most of them to default values, and only set one or two to non-default values. Don't ever want to leave values uninitialized, however. Of course, there are those who would say that any object that needs this many initializers is poorly designed and should be refactored. It would be up to the author in each individual case to decide if this is feasible. For my money, this makes a good case for a language feature I've been wanting ever since the days I worked with the ADA language - named parameter lists. Then you could offer default values for all parameters, and let the caller set only the ones (s)he wants to differ from the default values. Of course, you can emulate this now in C#, but it requires 2^n constructors. I've done it with three parameters (eight constructors), but of course it would be impractical with 24.
Good ideas about the default values. And C# actually does have named parameters. So, if they all have default values, you could just pass in a few that need to be set. Named and Optional Arguments (C# Programming Guide) | Microsoft Docs
-
Nobody seems to have yet mentioned any other alternatives...one would be passing in a structure with 24 members as an initializer, although in C# that doesn't really eliminate the problem, since you'd have a similar problem with how to initialize the structure. Might be useful tho if you instantiated a lot of these objects with mostly the same parameters. I would never condone instantiating a class without initializing all member data items, but if there are reasonable default values for them, I could see an initializer (or maybe even a few) that initialized all or most of them to default values, and only set one or two to non-default values. Don't ever want to leave values uninitialized, however. Of course, there are those who would say that any object that needs this many initializers is poorly designed and should be refactored. It would be up to the author in each individual case to decide if this is feasible. For my money, this makes a good case for a language feature I've been wanting ever since the days I worked with the ADA language - named parameter lists. Then you could offer default values for all parameters, and let the caller set only the ones (s)he wants to differ from the default values. Of course, you can emulate this now in C#, but it requires 2^n constructors. I've done it with three parameters (eight constructors), but of course it would be impractical with 24.
-
-
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)
public class FooDto
{
public T1 Property1 { get; set; }
// ....
public T24 Property24 { get; set; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto() { Property1 = property1, //.... Property24 = property24, }; }}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto(property1 /\*\* \*/, property24); }}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values. Though one could counter argument that we got unit test for just that. At any rate, which of those 2 is your favourite code style?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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.
-
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.
-
:) You should really try and get them to update or you should go somewhere else. That sound ridiculous to still be using VS2008.
-
Could you not just use inheritance and do away with all the property setting?
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass : FooDto
{
// ....
}This exposes properties T1 ... T24 of the base FooDto class but that may or may not be an issue. There are arguments against combining DTOs and inheritance, so without knowing the details of your implementation this may not be appropriate. Part of "knowing the details" of course involves the use of a crystal ball to envisage future changes, but depending on the scenario you can pretty much rule out a lot of potential stuff and, in this case, save yourself a lot of code.
Such a FoodDto is absolutely useless, a snapshot in time... There is little point in deriving from it... This FooDto sole purpose is to be turned into json and vice versa. It comes from an object that do update each individual property in real time (mostly hardware read status)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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)
public class FooDto
{
public T1 Property1 { get; set; }
// ....
public T24 Property24 { get; set; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto() { Property1 = property1, //.... Property24 = property24, }; }}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto(property1 /\*\* \*/, property24); }}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values. Though one could counter argument that we got unit test for just that. At any rate, which of those 2 is your favourite code style?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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
-
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)
public class FooDto
{
public T1 Property1 { get; set; }
// ....
public T24 Property24 { get; set; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto() { Property1 = property1, //.... Property24 = property24, }; }}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto(property1 /\*\* \*/, property24); }}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values. Though one could counter argument that we got unit test for just that. At any rate, which of those 2 is your favourite code style?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
