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.
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
– Luan Brito
@Luanbrito can sustain and substantiate this? Why should use OO resources, and why is it easier to solve possible problems?
– Maniero
@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.
– danilo
I understand your point, but I don’t think I have enough arguments to convince you otherwise
– Luan Brito
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?
– Maniero