This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
indeed. There is a strong school of thought that says you shouldn't generally have setters at all, just getters, and set every field through the constructor only (essentially making as many objects immutable as possible).
You could say you're providing the option of increased security when using setters as you can write them to provide for example validation (or even authorisation), though you certainly don't have to.
Encapsulation is what is provided by OOP, not security. I suspect what you mean is encapsulation.
Making an object immutable is no different security-wise, or encapsulation-wise then having mutators. Whether you are passing data through a constructor gains no "security" benefits over passing it to a mutator. There are plenty of benefits to using immutable classes but are related to performance and memory usage.
"Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration."- Stan Kelly-Bootle
Well, that would depend on your definition of security. If I define it as "I instantiate an object and I want to prevent you from changing it" then immutable is more secure than a setter. If I mean "I want to let you change it within some domain of values" then a setter with validation is more secure than a public variable. And if I mean "I don't want you to know this variable even exists" ... what implementation would you choose?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi