Do setter and getter methods breaks encapsulation? [closed]

Question

It is told that we should avoid setters and getters. There are various school of thoughts about it, but according to me using these breaks encapsulation. Why? because it tells the world about the internals of an object. For example:

class Point {
  private int x;
  private int y;

  void setx(int x) {...}
  int getx() {...}
  ... 
}

The object should just expose the behavior providing the clear abstraction to the client.

class Point {
  private int x;
  private int y;

  int coordinate(int x) {...} // 0, 1, 2, 3
  ... 
}

so, is this true that these accessor and setter methods breaks encapsulation?

Answer 1

Although getters and setters are actually meant to implement Encapsulation itself, but it depends a lot on the situation itself.

• Bad OO design: public fields.
• Sort of bad OO design : when getters and setters are used, even when
  not required
• Great OO design : used only where they're really required - and that to expose the behaviour of your class instead of a tool to manipulate the data.

Answer 2

From here:

Having getters and setters does not in itself break encapsulation. What does break encapsulation is having a getter and a setter for every data member (every field, in java lingo). That is one step away from making all data members public.

The point of encapsulation is not that you should not be able to know or to change the object's state from outside the object, but that you should have a reasonable policy for doing it.

Consider an example of a class Person. Let's say a person has a name, a social security number, and an age. Let's say that we do not allow people to ever change their names or social security numbers. However, the person's age should be incremented by 1 every year. In this case, you would provide a constructor that would initialize the name and the SSN to the given values, and which would initialize the age to 0. You would also provide a method incrementAge(), which would increase the age by 1. You would also provide getters for all three. No setters are required in this case.

In this design you allow the state of the object to be inspected from outside the class, and you allow it to be changed from outside the class. However, you do not allow the state to be changed arbitrarily. There is a policy, which effectively states that the name and the SSN cannot be changed at all, and that the age can be incremented by 1 year at a time.

Now let's say a person also has a salary. And people can change jobs at will, which means their salary will also change. To model this situation we have no other way but to provide a setSalary() method! Allowing the salary to be changed at will is a perfectly reasonable policy in this case.

By the way, in your example, I would give the class Fridge the putCheese() and takeCheese() methods, instead of get_cheese() and set_cheese(). Then you would still have encapsulation.

You can also refer: Why getter and setter methods are evil