Recently I came across a friend talking that it is not advisable to change getter and setter.
I had made a setter change of a List . In it I did not receive a list by parameter, but an object of the type, and within the method I made a add in the list, this spared me some lines of code, however I was in doubt:
Is it worth investing in good programming practice for such small detail that will not make a difference in code performance or complexity?
First, it seems that the example cited is not even a case of using a setter as it is usually defined. A setter is a method that receives a value that would normally already go into a field, eventually does some processing before and / or after assigning to a private field that it is encapsulating .
The description indicates that this is a method that takes a different value and manipulates a private field that has another function. That is, access to the field is indirect. This is usually recommended whenever it makes sense. Whenever possible it is better to have methods that do something more specific than a method that only serves to make an assignment.
Now all public methods, or even fields that may be public, are part of a contract that you have defined as the consumer of this class. You can move as much as you like in any type of method, including getters and setters as long as you do not break this agreement. One of the things you should not do is change the signature of the method. But do not even need it, just create a new method with a new signature (even if it has the same name) that does what you want now and keep both versions. If so, note this method as obsolete to avoid who is using it should look for the alternative. But do not delete something that is publicly available.
Should you always do this? No. If you can guarantee that you will have no problems, you can remove what is no longer used. If the class is only used internally you can tinker with all the code that consumed it, or else you can guarantee that nothing has consumed this method, change. You, look for the affected codes, do what you have to do and be happy. Do not pay attention to who gets the rule without knowing your real case.
If you do not break contracts, change as you wish.
But notice that I do not know what your case is. So I'm not saying what to do. I am only giving the subsidy to have a critical thinking, to know where it gives problem and where it does not give, now you analyze your case and make a decision.
Some things that might help:
There is nothing wrong with changing get and set . The get and set are just a name pattern adopted in Java to access the internal information of an object.
For example, when setting apelido in a Pessoa class, you may want to handle extra spaces, validate if the nickname respects the size limit, etc. within set of nickname. That is, you pass on the responsibility for the class itself to handle this, which is perfectly valid from the point of view of object orientation.
There may be an convention within the application in which a convention is working that set and get must return exactly the value of the fields in which they match. Maybe this class you've changed is just to load data from side to side. In general, this type of convention with get and set is very common in projects, but there is no problem in changing their behavior, it even depends on the context in which that class is found.
I had made the change of a setter from a List. I do not received a list by parameter, but an object of the type, and within the method I made an add on the list, this spared me a few lines of code
Your idea makes perfect sense. It just seems to me that calling this set method was not the best decision. It could be a adicionar or add , since you are not setting a list for the class, you are adding an element in the inner list ( add ) from class. In fact, maybe the% method of% of this set should not even exist. Anyway, they are just examples of how there are various situations.
