Passing parameters using primitives or an object containing the fields?

Asked

Viewed 70 times

1

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;  
}
  • the most appropriate would be to use void insert(Client) that so you use the features of object orientation and it becomes easier to solve possible problems

  • 2

    @Luanbrito can sustain and substantiate this? Why should use OO resources, and why is it easier to solve possible problems?

  • @Luanbrito, I asked the question to evaluate the visions that many can add, but mine is that I do not see any advantage in using an object, I wish that someone could convince me if there is any scenario in which this can be worthwhile. Using the object you actually lose a lot with OO, the method lost its signature with it, what data will it handle? you do not know, just know that will use a Client object that can have hundreds of fields, which is true in large applications.

  • I understand your point, but I don’t think I have enough arguments to convince you otherwise

  • Did the answer resolve what was in doubt? Do you need something else to be improved? Do you think it is possible to accept it now?

1 answer

4


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.

  • but as a general rule it is not much better to pass each data as a parameter in the method signature? so will be making the interface explicit. even if the object imports to the system and is a domain object, the method signature does not lose its semantics?

  • When you talk in semantics you can’t apply the general rule, each case has its semantics and only by looking at the case can you tell which is the best semantics there. If one does not understand what is semantics and what is the correct semantics he will use the wrong mechanism. So I say that to develop is not to memorize language syntax, it is to understand problems.

  • is that I have tried to apply a "general" rule used in the market and taught in universities, in which the entity "Customer" anemic domain is created and it is used everywhere with hundreds of fields, so I understand that the semantics are lost, but I understood your great answer that as always, once again added a lot.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.