Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
![](/static/devrant/img/pipeless-devrant-banner-white.png)
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
I sometimes follow this approach if I set some validation inside the setVal function
-
tkdmatze4436y@gitpush
no validation in the setter here
just plain
public final void setVal(final String val) {
this.val= val;
} -
@tkdmatze in this case you can start with:
1. The need for getter and setter so that out side world directly modify the var, but instead setters are used so that the world give their value and if the class needs certain requirements then they are validated inside the setter
2. Constructor is assigning values for the first time and not updating an existing value, so that directly modifying that var is safe without using setter (assuming someday you add validation so that he doesn't ask what if we add validation later on)
That's what I could think of, hope they are enough -
curlyDev4726yIsn't the setter role to set a variable and the whole idea is that you change in only one place?
So its actually good. If you vhange the variable name you just need to change in the setter not in constructor as well. -
@Kifflom @curlyDev for me I find it bad using it in a constructor if there is no validation inside the setter function, it is not that it negatively effect the code but assume there are read only vars that are only set during init of the class, imagine having:
this.setX()
this.y =
it is a mess to read IMO -
tkdmatze4436y@Kifflom
to give it a little more context, its a DTO, an immutable object, properties have XML-Validation Annotations
the only way it is initalised, is through the constructor, setters are unnecessary because never used until the change now ... but other dev wanted them ...
Validation is done object wise not propertywise after the object is created via constructor -
Litarvan2276yCalling instance functions from the constructor is officially wrong, as not all the variables are initialized
-
sSam15016y1. If the class is not final no public method should call another public method. By public I mean non-private and constructor also counts as a method. The reason is pretty simple. Imagine someone extends your class and changes behavior of that setter. The behavior of constructor will change too, but the person who overrode the setter will not expect that and will get weird unexpected bugs. Or if he wants the constructor to stay the same and override the setter he might not be able to do that at all.
2. Calling function will be a little bit slower than just assigning the value directly. -
it it is c# and using properties with properties changed notification, you do not want to have notifications before the object is constructed.
other dev changed constructor from
public A(String val){
this.val = val;
}
to
public A(String val){
this.setVal(val);
}
this feels bad in many ways, but need some arguments to convince him that its wrong
rant
java setter constructor