¿Cuántas entradas son "demasiadas" para un constructor en C#? Por ejemplo, ¿qué pasa si creo un Constructor con 110 entradas?
class File { public File(string name, string id, int comment, .... (+107)) { } }Tengo quizás 3000 archivos de texto (o más), que contienen atributos como: nombre, ID, comentario, velocidad y 106 más. Quería crear una lista de objetos, como a continuación:
List<File> file = new List<File>(); file .Add(new File("name", "id", "comment", "speed" (+ 106 others attributes));y luego aquí en el constructor para guardar todos estos atributos para cada archivo, y luego debería guardar todo esto en un archivo de Excel.
Supongo que debería encapsular las entradas en una clase y pasarlo como un objeto en lugar de hacer sus parámetros de esa manera, de esta manera también ayudará si tiene algún cambio en el futuro. Sin embargo, creo que si escribe su caso aquí, las personas pueden ayudarlo de una mejor manera, me refiero a escribir el caso por el que necesita pasar más de 100 parámetros a su contratista.
Una gran parte de la programación consiste en hacer que el código fuente sea legible para los humanos. ¿Le gustaría leer una lista de 110 parámetros de constructor, asegurándose de que todos sean correctos? Probablemente no.
Algunos argumentan por 1-3 parámetros como máximo, algunos argumentan que hasta 7 podría estar bien, depende un poco de qué tan estricto sea y qué libro esté leyendo. No soy muy dogmático, por lo que me preocuparía más si la cantidad de parámetros tiene sentido en el contexto.
Si tiene una gran cantidad de parámetros, indica que algo anda mal. ¿Quizás la clase está haciendo demasiado y debería dividirse en clases separadas? ¿Quizás algunos parámetros están relacionados y realmente deberían agruparse en clases más lógicas, listas o alguna otra estructura de datos?
Consulte también ¿Existen pautas sobre cuántos parámetros debe aceptar una función?, ya que esto se aplica tanto a los constructores como a los métodos, y realmente no hay nada específico de C# sobre la cantidad de parámetros.
Si tiene un montón de archivos de texto con algunos atributos, y presumiblemente un valor, probablemente sea mejor que describa esto con algún tipo de contenedor de clave-valor, como un diccionario o List<(string, object)> . Otra alternativa sería algún tipo de solución de deserialización para asignar automáticamente claves/valores a propiedades. Pero esto vuelve al primer punto, ¿es razonable necesitar 100 propiedades para describir una sola cosa? ¿Estás seguro de que no se describe mejor como compuesto de varias cosas?
Generalmente, no hay un número mágico de parámetros en un método o constructor, que simplemente hace que el código sea bueno o malo.
Pero pasar de 10 a 15 parámetros requiere una refactorización.
Lo más simple que podría hacer es definir algún DTO (objeto de transferencia de datos) que podría llevar toda esta información y podría simplificar el constructor:
public File(FileInitialization fileInit) {...}y definir la clase como:
public class FileInitialization { ...props...}Yendo más allá, puede agrupar cierta información, como información general (nombre de archivo, extensión), metadatos (comentarios, etc.), etc. Luego obtiene un código más granular y aún reduce los parámetros en el constructor:
public File(GeneralFileInfo fileInfo, FileMetadata meta, ...)Una sugerencia más es que cuando la creación de objetos es tan compleja, podría definir algún método de fábrica, que le evitaría proporcionar toda esta información compleja y encapsularía la creación de objetos y sus complejidades.