1

I'm learning Java and the basics of OOP. Imagine I'm making a Person class. A person has of course a firstname and a lastname, that's why I declare two private variables in the Person class, being firstname and lastname. Both getting their initial value in the constructor. Now, how do you decide wether they both need a public getter and a setter, or only a getter and not a setter? Do you take this decission based on the kind of functionalities your application should have?

For example if you are building an application for the local sportsclub to keep track of their members (each member is a person object). Within the application there is a button to create a new member. if you push this button you have to fill in a firstname and a lastname and push the button 'create and add to club'. Behind the scenes there is a person object created. The application can show a list of all members and delete a member and thats all it can do.

Now there is no functionality like change firstname or lastname of a member. Could this be a reason why I should not have a setter for firstname and lastname? So if I created a member maked a typo in his firstname, I first have to delete him and then create him again without the typo. If the application had a button 'change name' I should need a setter or a method like changeName or something because I want to alter an already existing object.

Is this the correct mindset or has functionality nothing to do with encapsulation?

Ps. I know it's simple example but it's just to base my question on.

Thanks

progmatico
  • 4,714
  • 1
  • 16
  • 27
Matthieu105
  • 23
  • 3
  • 2
    Your example seems to be more about the concept of mutability/immutability than with the concept of encapsulation. Either way, at least in your particular example, I'd say your application's functionality should NOT dictate how your class are designed. – Federico klez Culloca Oct 02 '20 at 15:43
  • 1
    See [Why use getters and setters/accessors?](https://stackoverflow.com/questions/1568091/why-use-getters-and-setters-accessors). If you understand why to use them at all, you will come to understand which you need. – Raedwald Oct 02 '20 at 15:47
  • 1
    See [What is meant by immutable?](https://stackoverflow.com/questions/279507/what-is-meant-by-immutable). – Raedwald Oct 02 '20 at 15:48
  • As a general rule, don't give the client program access to anything it doesn't need. If the particular design of a program does not require that a particular value be mutable, then declare it `final` and leave out the setter method. There's no standard that requires setter methods simply for the heck of it. – qwerty Oct 02 '20 at 18:27
  • 2
    I would say in more than 95% of the cases you will have private attributes with both public getter and setter. It is just about visibility and accessibility. That's all. Unless you want the attribute to be used internally within the class only, that way you can do without the getter and setter. – user3437460 Oct 02 '20 at 18:43
  • 1
    This is a matter of opinion and personal taste. There is no rule about whether to include a setter or not. You might even include them 'just in case', or because you are using a framework that dictates objetcs to have setters, etc. You can do it because of the functionality or because you like it that way – fps Oct 02 '20 at 18:48

1 Answers1

1

You make that kind of decisions based on the character of attributes. Are they public (used by external to the object/class entities?). Are they private (for object/class internal use only?). Should they be read-only after construction? When they are read-only "to the public", you don't need a public setter. If internally you still want to change them, you probably can access them directly without going through a setter.

It also makes sense to be able to fix an erroneous attribute without having to destroy the object and recreate it.

progmatico
  • 4,714
  • 1
  • 16
  • 27