Passing parameters using primitives or an object containing the fields?

Question

When creating the signature of a method, what would be the best design option for passing parameters?

Is there any good practice that addresses the signing of methods?

What would be better? For each parameter the simple types that represent as succinctly as possible each data passed, or use an object containing the fields with each data that needs to be treated within the method?

Examples

(each parameter a variable):

void inserir(string nome, int idade, string apelido, date dataDeNascimento)

(each parameter an object field):

void inserir(Cliente cliente)

where Customer is a class:

class Cliente {  
  string nome;  
  int idade;  
  string apelido;  
  date dataDeNascimento;  
}

Answer 1

Once again I repeat here at SOPT: there is no better option, no good practice, there is the most appropriate in the specific case. Good practice is the crutch that people use to follow cake recipe without learning the foundation of what they are doing and making right decisions.

Another thing I say a lot is that an artificial example is bad because it is not a concrete case and if you say it is good such a thing for this case it will not serve for a real case. The example of the question is very bad because it does not detail the actual conditions of the system (people fail a lot because they do not realize what matters in what they are doing) and it is something naive.

In general creating a type just to create an object and fill with data and use it to pass as argument (no parameters passed) does not make the slightest sense. But it’s not an absolute rule.

In general if you have a created type and it’s easy to create an object with it, and it makes sense to create it there, if at that point that object can be created in a valid state and has no other problems, then you should accept the object, but it is common to be an error if you have to create the object just to pass as argument, the ideal would be to already have this object.

For everything has exception. And there are cases that should accept both ways, can not know.

This example looks bad because it seems that this type was created just to pass an object and not because it matters in the system. Not that I can’t create types just for a mechanism, but it’s more common for types to be part of a model and not just to solve a code problem.

Something that few people realize is that the passage of arguments in a function call is a tuple implicit (in some cases it is up to a list) and tuples exist fundamentally to group data that makes sense to be together in a context without having to create a named type, the tuple is an anonymous type, and the function call has two types, the input and the output type, being that the output is usually unique, but can be multiple if you return a tuple, the input is already a tuple always, with zero, one or more members. If taught so people would understand much better.

Just keep in mind that the rule by the rule is always a mistake. The right thing to do is to understand what makes something cohesive and what allows low engagement pragmatically.