17
I recently came across a friend saying that it is not advisable to change getters and Setters.
I had made the modification of a Setter 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 on the list, it saved me some lines of code, but I was in doubt:
Is it so worth investing in good programming practices for details so small that they won’t make a difference in performance or code complexity?
13
First, it seems to me 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 in a field, eventually do 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, i.e., access to the field is indirect. That’s 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 with which you will be the consumer of this class. You can move as much as you want in any type of method, including getters and setters, provided you do not break this contract. One of the things you should not do is change the signature of the method. But you don’t have to, just create a new method with a new signature (even if it has the same name) that does what you want now and maintains both versions. If this is the case, write down this method as obsolete to avoid who is using it and look for the alternative. But don’t erase something that’s 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 mess with all the code that consumed it, or you can guarantee that nothing consumed this method, change. You, search for the affected codes, do what you have to do and be happy. Don’t pay attention to those who keep setting rules without knowing your real case.
If you don’t break contracts change how you want.
But note that I don’t know what your case is. So I’m not saying what you should do. I’m just giving you the grant to have a critical thought, to know where it goes wrong and where it doesn’t, now you analyze your case and make a decision.
Some things that might help:
1
There’s nothing wrong with changing the get and set. The get and set are just a default name adopted in Java to access the internal information of an object.
For example, when setting a apelido in a class Pessoa, you may want to treat extra spaces, validate if the nickname respects the limit size, etc within the set of the nickname. That is, you pass the responsibility to the class itself to treat this, which is perfectly valid from the point of view of object orientation.
Maybe it exists within the application in which is working a species one convention that set and get must return exactly the value of the fields in which they correspond. Maybe this class you changed is just to load data from side to side. Anyway, in general, this type of convention with get and set is quite common in projects, but there is no problem in changing their behavior, it depends even on the context in which that class is.
I had made the change of a Setter of a List. In it I did not received a list per parameter, but an object of the type, and within the method I made an add on the list, it saved me some lines of code
Your idea makes perfect sense. It just seems to me to call this method set was not the best decision. It could be a adicionar or add, because you’re not defining (set) a list for the class, you are adding (add) an element in the class internal list. Including, perhaps, the very method of set of this List nor should exist. Finally, they are just examples of how there are various situations.
Browser other questions tagged java oop method getters-setters
You are not signed in. Login or sign up in order to post.
Maybe it’s a duplicate: Getters and setters are an illusion of encapsulation?
– Math
@Math I believe I did not duplicate, this question refers to encapsulation, my doubt is whether it is a crime as they say make a change in the methods asuhsau advisors
– Felipe Paetzold
The rationale for not changing getters and setters is when your classes are used by third parties (for example, if they are part of a library intended to be used in other applications). You should be careful not to break the compatibility in the code that makes use of this library. Other than that there is no harm in changing getters and setters when you find that this can bring benefit to your code.
– Piovezan
The comment from @Piovezan perfectly and completely answers the question. Just one more detail: a Setter that adds the argument to a list seems strange. Suddenly this was the reason for your friend’s questioning. Not that this Setter is necessarily wrong, suddenly there’s a good reason, but maybe it’s worth it to question this particular point. As for changing a Setter, it is simply what was said by Piovezan; nothing more, nothing less.
– Caffé