My recommendation: Avoid getters and especially setters whenever possible. Try to make classes immutable and assign all attributes in the constructors.
Then I ran into problems with libraries that expect the Beans convention.
Yes, unfortunately.
Another benefit of classes adhering to the Beans convention: in an IDE, you can easily find out all the properties of a library's class if you just type in the first three letters: get.
So you want to understand the internals of the class. In a well-designed library this should not be neccessary.
By the way, one of the reasons why I have to work this weekend are classes with plenty of getters and setters which I need to modify.
BTW, having no setters and passing in the fields‘ values in the constructor alone doesn’t make your objects immutable. And if you e.g. want to implement value objects in Java, that are immutable, you need getters.
My recommendation: Avoid getters and especially setters whenever possible. Try to make classes immutable and assign all attributes in the constructors.
Yes, unfortunately.
So you want to understand the internals of the class. In a well-designed library this should not be neccessary.
By the way, one of the reasons why I have to work this weekend are classes with plenty of getters and setters which I need to modify.
BTW, having no setters and passing in the fields‘ values in the constructor alone doesn’t make your objects immutable. And if you e.g. want to implement value objects in Java, that are immutable, you need getters.
As always, it depends. In general, I do try to avoid it, but there are definitely valid cases for it (e.g. parameter objects).
UI libraries for example carry a lot of state on their objects.
Sorry to hear you have to work on weekends.