We Keep Coding

Why instance variable in Java should be private if the Class has only getters and setters [duplicate]

This question already has answers here:
Why use getters and setters/accessors?
(37 answers)
Closed 8 years ago.
I had been asked the following question in an interview and i am curious to know the answer.
There are two classes as following,
public class EmployeeA{
public int empId;
}
public class EmployeeB{
private int empId;
public void setEmpId(int empId){this.empId = empId;}
public int getEmpId(){return empId;}
}
There are two classes where one class has a public instance field and other have a private field with getters and setters. In this case, which is better implementation and why?
[I have learned that making instance variable private is the better idea. But in both cases i can modify the value of empId attribute. ]

The one-word answer they're probably looking for is "encapsulation".
By encapsulating the private field value, you have the opportunity to change the logic on how the value is set/retrieved in the future. Say, for example, you want to validate on set and filter on retrieval (get). By encapsulating the value, your creating an API which allows for better maintenance moving forward.

Maybe a bit off-topic, although people usually talk about "encapsulation" when talking about "getter/setter", "getter/setters" are actually still far from proper encapsulation.
This famous "why getter and setter methods are evil" is something worth to read. When we say getters and setters are evil, it doesn't mean that we should expose variable directly. It is about further hiding internal data by providing meaningful behavior in class, instead of providing accessors for properties. Although there are a lot of cases we still need accessors, this is something that worth giving attention when you are designing.
Going back to your question, if it is me, I will answer: providing getters and setters provides a minimal level of encapsulation and allow us to do extra work or derives data when we are setting and getting properties. However, for a proper encapsulation, I would rather design the Employee class to provide proper behaviors, instead of simply acting as a value object which only provides bunch of getters/setters.

The accesssor (getter) and mutator (setter) are JavaBean requirement but not all classes in Java must follow this design pattern. Why not creating this class as immutable by having a constructor that take the id (or even better, a static factory). You can then provide an accessor for the the id. That is generally not a good idea to be able to change the id of an object, if the id is used in a Map as the key and you change it, good luck to retrieve you object... Make the class immutable solve this kind of problem.

Model class properties should private or public? [duplicate]

This question already has answers here:
Why Not Use Public Member Functions
(3 answers)
Closed 9 years ago.
I have question which has been going around in my mind since long.
My Model class should have properties private or public? (Below code is written in PHP but question applies in general for any language)
class Xyz extends Model {
public function __call() {
}
public $description;
public $title;
}
In above example I have public properties $description and $title. Should I make them private?
I update my model as follows
$x = new Xyz();
$x->title('Hello');
$x->description('Blah blah');
$x->save();
I can update and get them by using magic method __call. So why do we need to keep them public? I can make them private. But as I see all the frameworks around keep model properties public.
Any thoughts?
UPDATE:
In answers, everyone is saying follow encapsulation and use private methods. Good but no one has the answer why some PHP frameworks have model properties public ? There should be some reason, isn't it?

As per OOP, we need to follow encapsulation. Please make your properties private and have public accessors and mutators. but, it depends that your accessors and mutators can have other modifiers as well. But, The properties should be always private.

Class fields should always be private. Getters and setters for the fields should be public. Aside from being standard, it is also good to have it this way so that you have the control to do what ever you want to the values that the client classes wants to set to you private fields.
For example, if you want to persist an object to a database, and one column is stated to be not null, and you are not sure if your client class will really return a non-null value, you can handle the null check inside the setter so that the values that you are about to persist to the db contains no null field, as what the table of your db demands.

The fields should always be private as per OOP encapsulation principle. Now the thing is with the getter and setter accessor methods.
The getter is usually safe to make it public. The only downside of it is that you will have to maintain backward compatibility between versions, as this will be part of the public contract of the class. So if the field is something that is part of the implementation rather than interface, than maybe you want to keep it protected.
As for the setter the better question is if to create one or not. If you want to keep your class immutable (or at least some parts of it) with all the advantages and disadvantages that comes from it, then you'll not be creating a setter at all.

You have to make all properties as private in model class and if you have to encapsulate their value then you have to use appropriate getters and setters to get and set their values.

private String or public static String?

At my internship one of my colleagues gave me a hint. I want to know if this is good practice.
What I was doing was creating classes that are used only for the values they contain and don't have any functions that actually do something (apart from having getters, setters and a constructor). I declared my variables like this:
public class ObjectIUse{
Private String name;
public ObjectIUse(String name){
this.name = name;
}
public String getName(){
return name;
}
}
So I'm not using a setter because it should always stay the same. My colleague said that I can also do it this way:
public class ObjectIUse{
public final String name;
public ObjectIUse(String name){
this.name = name;
}
}
Because now we don't need to have any getters or setters because it is public, however it can also never be changed because it is final.
Which would be better? Or would it maybe be preferable to still make it private but also final? I mean all of the options work, obviously. I just want to know which is better and why.

Make the variable private, because by doing so you'll be encapsulating the variable in your class. This has many benefits, information hiding is among one, which you'll learn if you go to the above link.
If you want it to never change after creation, then make it final too.

This works now because a String is immutable. But what happens when you expose the reference to a mutable class and that class is not thread safe ?. You cant even return a defensive copy if you want to.
Not to mention this also breaks encapsulation. Use a private variable and getters.

The idea of not providing a setter method to a variable makes it a read-only field, that said, it means we can only read but not write, so making it a constant by the use of the final keyword summarizes it all.
I think a constant is better. final keyword improves performance. Read more here

You should definitely have a getter and make your field private. That is what we call encapsulation.
Also by making it final and so not having a setter, your object is immutable, whic is a very good thing for parallel programming.

A proper use of encapsulation principle is to make all class fields private and access them via setters and getters. Other than that, you might want to add any additional logic when you're calling getName(). While second variant is sometimes used, the first one is better. Hope this helps.

Which would be better? Or would it maybe be preferable to still make
it private but also final?
If you want to be successful developer, you should program correctly, efficiently and the most important securely. Security and performance is on the first place.
When you make it public you will break encapsulation that is very important and has many benefits. Every time you want to get property of Object, getters will become your friend.
Generally you shouldn't have direct access to properties of Object(only in extrem cases but also these can be solved in better way). Getters and Setters are designated for these purposes - preserve encapsulation and deal with objects securely.
final variables are usually used for data which are unchangeable during a time.

I guess their reasoning is that having it public keeps the code simpler. Java gets criticised for being too verbose in situations like this. Over a language such as Javascript where this would (normally) always be public.
But that simplicity is a trade-off against having secure, stable and extendable code.
To see why that's important, take a look at a large-scale Javascript project that has been written with everything as public. Each class's code might be simple... but their relationships, and the resulting architecture, end up being a nightmare to maintain.

I think it's depends. For example: if you use getter - you can override it. Sometimes it very usefull.

What is the point of getters and setters? [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why use getters and setters?
I have read books on Java, saying that it is good to create setters and getters for variables such as x and y. For example:
public int getX(){
return x;
}
public void setX(int x){
this.x = x;
}
But what is the difference from that and
...(shape.x)... // Basically getX()
and
shape.x = 90; // Basically setX()
If setters and getters are better, what practical problems would arise?

Multiple reasons:
If you allow field access like
shape.x = 90
then you cannot add any logic in future to validate the data.
say if x cannot be less than 100 you cannot do it, however if you had setters like
public void setShapeValue(int shapeValue){
if(shapeValue < 100){
//do something here like throw exception.
}
}
You cannot add something like copy on write logic (see CopyOnWriteArrayList)
Another reason is for accessing fields outside your class you will have to mark them public, protected or default, and thus you loose control. When data is very much internal to the class breaking Encapsulation and in general OOPS methodology.
Though for constants like
public final String SOMETHING = "SOMETHING";
you will allow field access as they cannot be changed, for instance variable you will place them with getters, setters.
Another scenario is when you want your Class to be immutable, if you allow field access then you are breaking the immutability of your class since values can be changed. But if you carefully design your class with getters and no setters you keep the immutability intact.
Though in such cases you have to be careful in getter method to ensure you don't give out reference of objects(in case your class have object as instances).
We can use the private variables in any package using getters and setters.

Using getter and setter functions allow for constraints and encapsulation. Lets say x is the radius. shape.x = -10 would not make much sense. Also, if someone tries to set an illegal value, you can print an error, set a default value, or do nothing.
It is good practice to make member variables private so they cannot be modified directly by programs using them.
Mutator functions
Encapsulation

A lot of people have mentioned encapsulating the specifics of the implementation, which to me is the biggest reason to use getters and setters in a class. With this, you also get a lot of other benefits, including the ability to throw out and replace the implementation on a whim without needing to touch every piece of code that uses your class. In a small project, that's not a big benefit, but if your code ends up as a well-used (internal or public) library, it can be a huge benefit.
One specific example: complex numbers in mathematics. Some languages have them as a language or framework feature, others don't. I will use a mutable class as an example here, but it could just as easily be immutable.
A complex number can be written on the form a + bi with real and imaginary parts, lending itself well to [gs]etRealPart and [gs]etImaginaryPart.
However, in some cases it's easier to reason about complex numbers on polar form re^(iθ), giving [gs]etRadius (r) and [gs]etAngle (θ).
You can also expose methods like [gs]etComplexNumber(realPart, imaginaryPart) and [gs]etComplexNumber(radius, angle). Depending on the argument types these may or may not need different names, but then the class' consumer can use either as fits its needs.
The two forms are interchangeable; you can fairly easily convert from one to the other, so which form the class uses for internal storage is irrelevant to consumers of that class. However, consumers may use either form. If you choose the form a+bi for internal representation, and expose that using fields rather than getters and setters, not only do you force the class consumers to use that form, you also cannot later easily change your mind and replace the internal representation with re^(iθ) because that turns out to be easier to implement in your particular scenario. You're stuck with the public API you have defined, which mandates that specifically the real and imaginary parts are exposed using specific field names.

One of the best reasons I can think of for getters and setters is the permanence of a class's API. In languages like python you can access members by their name and switch them to methods later. Because functions behave differently than members in java once you access a property thats it. Restricting its scope later breaks the client.
By providing getters and setters a programmer has the flexibility to modify members and behavior freely as long as the adhere to the contract described by the public API.

Another good reason to user getter and setter can be understand by the following example
public class TestGetterSetter{
private String name ;
public void setName(String name){
this.name = name ;
}
public String getName(){
return this.name ;
}
}
The point of getters and setters is that only they are meant to be used to access the private variable, which they are getting or setting. This way you provide encapsulation and it will be much easier to refactor or modify your code later.
Imagine you use name instead of its getter. Then if you want to add something like a default (say the default name is 'Guest' if it wasn't set before), then you'll have to modify both the getter and the sayName function.
public class TestGetterSetter{
private String name ;
public void setName(String name){
this.name = name ;
}
public String getName(){
if (this.name == null ){
setName("Guest");
}
return this.name ;
}
}
There is no requirement for getters and setter to start with get and set - they are just normal member functions. However it's a convention to do that. (especially if you use Java Beans)

Let's say, hypothetically, you find a library that does a better job of what you have been doing in your own class (YourClass). The natural thing to do at this point is to make YourClass a wrapper interface to that library. It still has a concept of "X" which your client code needs to get or set. Naturally, at this point you pretty much have to write the accessor functions.
If you neglected to use accessor functions and let your client code access YourClass.x directly, you would now have to rewrite all of your client code that ever touched YourClass.x. But if you were using YourClass.getX() and YourClass.setX() from the beginning, you will only need to rewrite YourClass.
One of the key concepts of programming, and especially object oriented programming, is hiding implementation details so that they're not used directly by code in other classes or modules. This way, if you ever change the implementation details (as in the example above), the client code doesn't know the difference and doesn't have to be modified. For all your client code knows, "x" might be a variable, or it might be a value that is calculated on the fly.
This is an oversimplification and doesn't cover all the scenarios where hiding implementation is beneficial, but it is the most obvious example. The concept of hiding implementation details is pretty strongly tied to OOP now, but you can find discussions of it going back decades before OOP was dreamed up. It goes back to one of the core concepts of software development, which is to take a big nebulous problem, and divide it into small well-defined problems which can be solved easily. Accessor functions help keep your small sub-tasks separate and well-defined: The less your classes know about each other's internals, the better.

There are lots of reasons. Here are just a few.
Accessors, getters in particular, often appear in interfaces. You can't stipulate a member variable in an interface.
Once you expose this member variable, you can't change your mind about how it's implemented. For example, if you see a need later to switch to a pattern like aggregation, where you want the "x" property to actually come from some nested object, you end up having to copy that value and try to keep it in sync. Not good.
Most of the time you are much better off not exposing the setter. You can't do that with public fields like x.

Before get into the answer, we gotta know something prior...! "JavaBeans".
JavaBeans are java classes that have properties. For our purpose, think of properties as private instance variables. since they're private, the only way they can be accessed
from outside of their class is through 'methods'in the class.
The methods that change a propertiy's value are called setter methods, and the methods that retrieve a property's value are called getter methods.

I would say that neither the getters/setters nor the public members are good Object Oriented design. They both break OOP Encapsulation by exposing an objects data to the world that probably shouldn't be accessing the properties of the object in the first place.

This is done by applying the encapsulation principle of OOP.
A language mechanism for restricting access to some of the object's components.
This means, you must define the visibility for the attributes and methods of your classes. There are 3 common visibilities:
Private: Only the class can see and use the attributes/methods.
Protected: Only the class and its children can see and use the attributes/methods.
Public: Every class can see and use the attributes/methods.
When you declare private/protected attributes, you are encouraged to create methods to obtain the value (get) and change the value (set). One example about visibility is the [ArrayList][2] class: it has a size property to know the actual size of the inner array. Only the class must change its value, so the code is something like
public class ArrayList<E> {
private int size;
private Object[] array;
public getSize() {
return this.size;
}
public void add(E element) {
//logic to add the element in the array...
this.size++;
}
}
In this example, you can see that the size value can change only inside the class methods, and you can get the actual size by calling it in your code (not mutating it):
public void someMethod() {
List<String> ls = new ArrayList<String>();
//adding values
ls.add("Hello");
ls.add("World");
for(int i = 0; i < ls.size(); i++) {
System.out.println(ls.get(i));
}
}

Getters and setters encapsulate the fields of a class by making them accessible only through its public methods and keep the values themselves private. That is considered a good OO principle.
Granted, it often seems like redundant code if it does nothing more than setting or returning a value. However, setters also allow you to do input validation or cleanup. Having that in one place improves data integrity for your objects,

Because we are using Object oriented programming language.
Here we are using Data hiding and encapsulation.
The variable should not directly accessible from out side world (for achiving data hiding) so we will create it private so
shape.x
is not correct.
Getter and setter method are used to get and set the value of x which is the way to achive encapsulation.

Is it bad to have public variables in a non-static class?

I am writing a game and I have a class for the input which contains booleans for all the different keys. I create an instance of this class in the main game class. Is it ok for the booleans to be public, or should I access them with accessors?

Instead of having a boolean for each key, it would be more readable and easier to code if you had a private Map<String, Boolean> keyStates, with all keys initialized to false. Then your accessors might be:
public void setPressed(String keyName) {
keyStates.put(keyName, true);
}
public void setReleased(String keyName) {
keyStates.put(keyName, false);
}
public boolean isPressed(String keyName) {
return keyStates.get(keyName);
}
The general reason for having accessor methods rather than public variables is that it allows the class to change its implementation without requiring changes in the classes that interact with its members. For example, with the above, you can now add code to count or log key presses, or change the underlying type of Map used, without exposing any of this to the outside.
This is not personal preference. Encapsulation and Interfaces are integral parts of OO Software Engineering, and are the primary design reasons that the Internet is possible from a technical POV.

Generally I would recommend using getters and setters as it is cleaner, more organized, and more readable. This will also help if you have a lot of different programmers looking at your code. My outlook is to always make your variables private unless you need to expose them for a specific reason. If performance is really an issue in your game then making your variables public will help a little by reducing function calls.

It's mainly a personal taste thing - I'm sure you'll find people arguing on both sides, and I'd say it's not black or white but depends on how "big" the class is.
The rationale for using getters and setters is so that you abstract out the actual representation as a field, in order to give you the freedom to start presenting this as e.g. a derived value without changing your interface. So really it comes down to how valuable the interface to this class is to you.
If it's part of your first-class public interface, then definitely use getters and setters. At the other extreme, if it's a simple data holder like a tuple that's used solely within a single class (e.g. to map database rows before transformation into another class), then I wouldn't hesitate to use fields; there's no real value to the interface as it's only being used internally.
So how many classes/packages would use this class? If it's a private, "local" class then I don't think there's anything wrong with just using the fields, and updating your callers if this ever needs to change.
Accessing fields is much easier to justify if they're final too, which is often the case with this sort of object.

It's not bad, but usually you'll want to encapsulate the state of an object.

Standard practice is to make member variables either protected or private with getters/setters that follow java bean convention. This tends to be somewhat verbose, but there is a very nice library (www.projectlombok.org) out there that generates the getters/setters/constructors/toString/hashCode/equals methods for you.

It is always a good java programming practice to declare the class variables as private and access them with public getter and setter methods unless its really needed to declare them as public .
If you are using an IDE , then its just a click away to generate getters and setters for class variables/member variables .

And now that you have been told over and over to use getter and setters, and because you are in Java (where IDEs help you make getters/setters trivially, and everyone clearly uses them), read over this thread to help add some balance to your usage of them:
Getters and Setters are bad OO design?