Home > Enterprise >  How many inputs are "too much" for a constructor in C#
How many inputs are "too much" for a constructor in C#

Time:11-03

Could anyone tell me how many inputs are "too much" for a constructor in C#. For example what if I create a Constructor with 110 inputs! Thanks in advance!

class File
{

public File(string name, string id, int comment, .... ( 107))
{
}

 }

I have, maybe more than 3000 *.txt files, which contains attributes like: name, Id, comment, speed .... ( 106 others). I wanted to create a list of objects, like below:

List<File> file = new List<File>();
file .Add(new File("name", "id", "comment", "speed" ...( 106 others attributes));

and then here in the constructor to save all these attributes for each file, and then should I save all these in a Excel File...

CodePudding user response:

A huge part of programming is making source code readable for humans. Would you like to read a list of 110 constructor parameters, making sure they are all correct? Probably not.

Some argue for 1-3 parameters maximum, some argue up to 7 might be ok, it depend a bit how strict you are and what book you are reading. I'm not very dogmatic, so I would be more concerned about if the number of parameters makes sense in the context.

If you have a huge amount of parameters it signals something is wrong. Perhaps the class is doing too much, and should be split into separate classes? Perhaps some parameters are related and should really be grouped into more logical classes, lists, or some other datastructure?

See also Are there guidelines on how many parameters a function should accept, since this applies just as well to constructors as methods, and there is really nothing c# specific about the number of parameters.

If you have a bunch of text-files with some attributes, and presumably a value, you are probably better of describing this with some sort of key-value container, like a dictionary or List<(string, object)>. Another alternative would be some kind of de-serialization solution to automatically map keys/values to properties. But this returns to the first point, is it reasonable to need 100-ish properties to describe a single thing? Are you sure it is not better described as composed of multiple things

CodePudding user response:

Generally, there is not magic number of parameters in a method or constructor, that simply makes code good or bad.

But going over 10-15 parameters begs for refactoring.

The simpliest you could do is to define some DTO (data transfer object) that could carry all this info and you could simplify then constructor:

public File(FileInitialization fileInit) {...}

and define the class like:

public class FileInitialization { ...props...}

Going further, you could group some information, like general info (file name, extension), metadata (comments, etc.), etc. Then you get more granular code and still reduce params in cosntructor:

public File(GeneralFileInfo fileInfo, FileMetadata meta, ...)

One more suggestion is when creation of object is so complex, you could define some factory method, that would save you from providing all this complex information and encapsulate object creation and it intricacies.

CodePudding user response:

I guess you should encapsulate the inputs into a class, and pass it as one object instead of making your parameters in such way, this way will also help if you have any changes in the future. However I think if you write your case here people can help in better way, I mean write the case why you need to pass around 100 parameters into your contractor.

  •  Tags:  
  • c#
  • Related