11

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?

vivek
  • 2,807
  • 5
  • 31
  • 44
  • 1
    How are you suppose to control access? What about calculated fields? "properties" (or setters/getters) simply tell the world what the object can do and how it might achieve it, how those results are processed/generated are unknown, the object becomes a black box, you put something, you get something, how that works isn't important to the caller – MadProgrammer Jan 15 '16 at 06:13
  • [*"Encapsulation is an Object Oriented Programming concept that binds together the data and functions that manipulate the data, and that keeps both safe from outside interference and misuse"*](https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwj5gIT5lKvKAhWBFqYKHYEWDJsQFggeMAE&url=http%3A%2F%2Fwww.tutorialspoint.com%2Fcplusplus%2Fcpp_data_encapsulation.htm&usg=AFQjCNHROM-INJ0YTp4oUBJwze-RZT7eXA&sig2=2lGGqo5CCINlc3RwNCZghw&bvm=bv.112064104,d.dGY) which suggests that the setters/getters are part of the "function" of the data – MadProgrammer Jan 15 '16 at 06:15
  • Possible duplicate of [Why use getters and setters?](http://stackoverflow.com/questions/1568091/why-use-getters-and-setters) – m.aibin Jan 15 '16 at 06:15
  • @m.aibin I think you need to understand the context of the question fellas. I know there is a minute difference but there is a difference. – vivek Jan 15 '16 at 13:14
  • Question a little different, but you will find exact the same answer in it. – m.aibin Jan 15 '16 at 15:11
  • @m.aibin I think its a good idea to map many questions to many answers. The link of probable answers is helpful to some new readers. No question answer pair can be unique according to me, rest its up to you. – vivek Jan 15 '16 at 17:21

2 Answers2

18

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

Community
  • 1
  • 1
Rahul Tripathi
  • 168,305
  • 31
  • 280
  • 331
14

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.
Ashutosh Agarwal
  • 183
  • 8
  • Good answer. I think some use cases would be awesome for @vivek. For data transfer objects public fields or all getters and setters are not so bad. It is also common to only have getters on object that we dont want others to modify, hence immutable. – Perpetualcoder Jan 15 '16 at 06:27
  • This answer is just copied answer of @Jon Skeet, from the similar question. – m.aibin Jan 15 '16 at 15:11