Use a constructor with multiple parameters, or create multiple sets?

Asked

Viewed 270 times

1

Amid use a constructor with multiple parameters or give a lot of sets, which of these options is more performative for the compiler, would cost less memory and would be faster?

  • Did any of the answers solve your question? Do you think you can accept one of them? Check out the [tour] how to do this, if you haven’t already. You would help the community by identifying what was the best solution for you. You can accept only one of them. But you can vote on any question or answer you find useful on the entire site

2 answers

4

The two questions you should read first are What good is a builder? and Getters and Setters Methods (actually there is a list of questions to read). Without knowing why use these mechanisms will not be able to make a proper decision.

There it will be clear that it will be created setters only to initialize variables is wrong.

It would even make sense if the language allowed to initialize the variables and then not touch it through initializers, then it might even be useful in some cases (reading everything there you will see that the builder is still needed in others, although it could combine the two). Until the date of writing of this answer no better known language allowed it to do so. C# will allow version 9 (if all goes well, and I do not know if it will be good, I have reservations).

I want to emphasize that strictly speaking of object orientation getters, and mainly setters, are misrepresentations. The most fundamentalist proponents of this paradigm consider that you should only have more significant methods for operations that by chance manipulate one or more fields and probably do operations that better justify changing these fields, so a Setter would somehow leaking abstraction and exposing the field indirectly. I’m not a fundamentalist or a big OOP fan, but I try to think about it and adopt the best mechanism. Developing software is planning what you do, analyzing all possible issues, at least in software designed to last.

Alternatives

In some cases you may want to make a pattern Builder to help, so you can gradually build the object and then use it as a parameter of the real object. It is a little complex, it consumes a little more resource at least at a certain time, but it is more correct than to leave setters exposed only to initialize values.

In some cases it is possible to group certain parts of your object into smaller objects (Endereço or AnáliseCrédito as examples) to greatly reduce the amount of real parameters to use. But I fear that most people will abuse this and start modeling wrong just to solve a technical issue of code, this is horrible and a lot of experienced people live doing and recommending, should be the last choice.

Many parãmetros

Do not rule out using many parameters in the constructor even if it seems wrong, it is not in many cases.

I know it can be complicated if you have a lot of optional data (yet somehow all fields (not attributes as people call) need to be initialized in some way, even if in a constructor written by the compiler.

Sometimes doing the simple is worth more than doing the conceptually right. But I doubt that creating setters just to initialize the object is better in any situation. If it is an initializer method that you control that will not accept change after a certain point may be interesting, but it is not a Setter per se, and it will be complex, will worsen the whole object to avoid the builder.

Performance and consumption

The performance should not be an issue there, just think about it if it is something that has relevance, usually does not, the scenarios I see that may be end up not looking at the whole context, because the bulk of the construction work should be in other issues. But the constructor will be much faster in strict proportion only to the call of this or other method, in all the difference will be (well) small.

Calling multiple methods will always be more expensive than calling just one, even if it has many parameters. There is an intrinsic cost in the call.

I talked about execution performance, but the performance for the compiler will also be slightly better using the constructor, even if it depends a little on how it does each thing. That’s even less relevant.

Memory consumption of the object itself (in heap) will be equal, may there is more use of the stack depending on how to use the builder or the setters, but it is still less relevant because stack automatically manages at zero cost so it only changes a little the processing cost, forget your consumption.

The object may be larger using setters if you need to create a mechanism to control whether the whole object is built, which will make all methods less performative yet.

3

There are some differences between constructor purposes and sets methods:

Builders

The idea of the builder is construct the object, that is, to give all the structure necessary for that object to exist.

For example: in theory, for the IRS you only exist if you have a CPF. Therefore, it makes sense for an object of the person type to exist only if it has a CPF. Given this reasoning, it makes sense for you to put CPF as a constructor attribute, since for a person to exist, they would need to have CPF.

Set methods

Sets are used for change some attribute of the object. If your object has fields that can change during your lifetime, then your object needs sets for these fields.

In the above example, you should have the setName in the Person object, as a person can change the name during their lifetime. However, if you consider on your system that a person should never change CPF, then you should not have a setCPF, since in this case CPF is not a mutable attribute.

Constructors vs set methods

In short: use constructor parameters for the essential attributes and sets methods for attributes can be modified.

When in doubt, think about whether it makes sense for that object to exist without that attribute. And also remember that what is placed in the constructor has to be of extreme relevance, because the more attributes in the constructor, the greater the amount of values that must be passed when instantiating an object. Putting too many parameters in the constructor can generate an unnecessary increase in code, which makes it difficult to write and maintain code.

However, often all attributes of an object are very relevant. As, for example, the name of the person in the recipe system may be something relevant to the Person object. This will depend on the modeling of the system. Most of the time in programming there is no definitive rule, it goes from case to case and with experience you will learn how to act in each case.

Performance

I don’t know which is more performative, but I would guess the parameters on constants. But I assure you that this difference is irrelevant, especially when it comes to a high-level language like Java. It’s always very important to worry about performance, especially when looping or using external libraries, but when programming in high-level language, perhaps even more important is to make code readable, organized and that follows whenever possible the standards of Software Engineering.

PS: If you really have curiosity, research how to do empirical tests in programming and do your tests. Testing of this kind is always a good way to learn more.

  • 1

    You know that CPF can be as much or more changed than the name?

  • I figured it would probably be something changeable as well, but I couldn’t think of something not changeable at the moment. But I understand that I should have made that clear. I will edit.

  • The point is that if your system doesn’t allow the person to change the number he is fundamentally wrong because people change regardless of their system leave or not. You can understand the mechanism, but it is not suitable for the reality of the systems. And that is one of the reasons that getters/setters are problematic and almost no one understands this. They do not consider the context of change. Everything can be changed for some reason, but not for everyone. To do more or less they are not even necessary (especially p Setter). More or less organized is the same as disorganized.

  • If within the logic of your system, a person cannot have more than one CPF in life, then you can choose not to have set for that attribute. If a real-world person changes the CPF, in the system view he is another person and it is the role of the developer to know how to deal with it. I don’t think it’s something "fundamentally wrong". Every modeling will have pros and cons.

  • I understand your comment, but I have always seen this as a limitation of OO (and also of all computing). Unfortunately, you can’t model everything exactly as it is in the real world. In many cases the use of sets is very useful, but yes, I agree that in many other cases, the use is a bit stupid.

  • This would be a fanciful system so it’s fundamentally wrong. And it has systems like this, I know because I’m a victim of them. You can’t do the right thing because the system won’t allow it, then you make the mistake and screw it up. I would like people to stop making fundamentally wrong systems because she thinks about her system and not the need for who uses it that’s always real.

  • I didn’t see that I had added an answer. I understood your point. I just find the answer a little heavy for a beginner (ashuashaus), but it’s important to know this.

  • Blz, thank you guys!!

Show 3 more comments

Browser other questions tagged

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