Java – Is encapsulation still one of the elephants OOP stands on

javaobject-oriented

Encapsulation tells me to make all or almost all fields private and expose these by getters/setters. But now libraries such as Lombok appear which allow us to expose all private fields by one short annotation @Data. It will create getters, setters and setting constructors for all private fields.

Could somebody explain to me what is the sense of hiding all fields as private and after that to expose all of them by some extra technology? Why do we simply not use only public fields then? I feel we have walked a long and hard way only to return to the starting point.

Yes, there are other technologies that work through getters and setters. And we cannot use them through simple public fields. But these technologies appeared only because we had those numerous properties – private fields behind public getters/setters. If we had not the properties, these technologies would develop another way and would support public fields. And everything would be simple and we wouldn't have any need for Lombok now.

What is the sense of the whole this cycle? And has encapsulation really any sense now in real life programming?

Best Answer

If you expose all your attributes with getters/setters you are gaining just data structure which is still used in C or any other procedural language. It is not encapsulation and Lombok is just making to work with procedural code less painful. Getters/setters as bad as plain public fields. There is no difference really.

And data structure is not an object. If you will start creating an object from writing an interface you will never add getters/setters to the interface. Exposing your attributes leads to spaghetti procedural code where manipulation with data is outside of an object and spread allover the codebase. Now you are dealing with data and with manipulations with data instead of talking to objects. With getters/setters, you will have data-driven procedural programming where manipulation with that done in the straight imperative way. Get data - do something - set data.

In OOP encapsulation is an elephant if done in right way. You should encapsulate state and implementation details so that object has full control on that. Logic will be focused inside object and will not be spread all over the codebase. And yes - encapsulation is still essential in programming as the code will be more maintainable.

EDITS

After seeing the discussions going on I want to add several things:

It doesn't matter how many of your attributes you expose through getters/setters and how carefully you're doing that. Being more selective will not make your code OOP with encapsulation. Every attribute you expose will lead to some procedure working with that naked data in imperative procedural way. You will just spread your code less slowly with being more selective. That doesn't change the core.
Yes, in boundaries within the system you get naked data from other systems or database. But this data is just another encapsulation point.
Objects should be reliable. The whole idea of objects is being responsible so that you don't need to give orders that are straight and imperative. Instead you're asking an object to do what it does well through the contract. You safely delegate acting part to the object. Objects encapsulate state and implementation details.

So if we return to the question why we should do this. Consider this simple example:

public class Document {
    private String title;

    public String getTitle() {
        return title;
    }
}

public class SomeDocumentServiceOrHandler {

    public void printDocument(Document document) {
        System.out.println("Title is " + document.getTitle());
    }
}

Here we have Document exposing internal detail by getter and have external procedural code in printDocument function which works with that outside of the object. Why is this bad? Because now you just have C style code. Yes it is structured but what's really the difference? You can structure C functions in different files and with names. And those so called layers are doing exactly that. Service class is just a bunch of procedures that work with data. That code is less maintainable and has many drawbacks.

public interface Printable {
    void print();
}

public final class PrintableDocument implements Printable {
    private final String title;

    public PrintableDocument(String title) {
        this.title = title;
    }

    @Override
    public void print() {
        System.out.println("Title is " + title);
    }
}

Compare with this one. Now we have a contract and the implemantation details of this contract is hidden inside of the object. Now you can truly test that class and that class is encapsulating some data. How it works with that data is an object concerns. In order to talk with object now you need to ask him to print itself. That's encapsulation and that is an object. You will gain the full power of dependency injection, mocking, testing, single responsibilities and a lot bunch of benefits with OOP.

Related Solutions

Java – When are Getters and Setters Justified

Having getters and setters does not in itself break encapsulation. What does break encapsulation is automatically adding a getter and a setter for every data member (every field, in java lingo), without giving it any thought. While this is better than making all data members public, it is only a small step away.

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.

Some data members may be entirely internal to the object, and should have neither getters nor setters.
Some data members should be read-only, so they may need getters but not setters.
Some data members may need to be kept consistent with each other. In such a case you would not provide a setter for each one, but a single method for setting them at the same time, so that you can check the values for consistency.
Some data members may only need to be changed in a certain way, such as incremented or decremented by a fixed amount. In this case, you would provide an increment() and/or decrement() method, rather than a setter.
Yet others may actually need to be read-write, and would have both a getter and a setter.

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.

public class Fridge {
  private List objects;
  private Date warranty;

  /** How the warranty is stored internally is a detail. */
  public Fridge( Date warranty ) {
    // The Fridge can set its internal warranty, but it is not re-exposed.
    setWarranty( warranty );
  }

  /** Doesn't expose how the fridge knows it is empty. */
  public boolean isEmpty() {
    return getObjects().isEmpty();
  }

  /** When the fridge has no more room... */
  public boolean isFull() {
  }

  /** Answers whether the given object will fit. */
  public boolean canStore( Object o ) {
    boolean result = false;

    // Clients may not ask how much room remains in the fridge.
    if( o instanceof PhysicalObject ) {
      PhysicalObject po = (PhysicalObject)o;

      // How the fridge determines its remaining usable volume is a detail.
      // How a physical object determines whether it fits within a specified
      // volume is also a detail.
      result = po.isEnclosedBy( getUsableVolume() );
    }

     return result;
  }

  /** Doesn't expose how the fridge knows its warranty has expired. */
  public boolean isPastWarranty() {
    return getWarranty().before( new Date() );
  }

  /** Doesn't expose how objects are stored in the fridge. */
  public synchronized void store( Object o ) {
    validateExpiration( o );

    // Can the object fit?
    if( canStore( o ) ) {
      getObjects().add( o );
    }
    else {
      throw FridgeFullException( o );
    }
  }

  /** Doesn't expose how objects are removed from the fridge. */
  public synchronized void remove( Object o ) {
    if( !getObjects().contains( o ) ) {
      throw new ObjectNotFoundException( o );
    }

    getObjects().remove( o );

    validateExpiration( o );
  }

  /** Lazily initialized list, an implementation detail. */
  private synchronized List getObjects() {
    if( this.list == null ) { this.list = new List(); }
    return this.list;
  }

  /** How object expiration is determined is also a detail. */
  private void validateExpiration( Object o ) {
    // Objects can answer whether they have gone past a given
    // expiration date. How each object "knows" it has expired
    // is a detail. The Fridge might use a scanner and
    // items might have embedded RFID chips. It's a detail hidden
    // by proper encapsulation.
    if( o implements Expires && ((Expires)o).expiresBefore( today ) ) {
      throw new ExpiredObjectException( o );
    }
  }

  /** This creates a copy of the warranty for immutability purposes. */
  private void setWarranty( Date warranty ) {
    assert warranty != null;
    this.warranty = new Date( warranty.getTime() )
  }
}

C# Automatic Properties – Should They Be Used?

At a first glance, these two lines may look the same:

public string A;
public string B {get; set;}

but they're not the same at all. As you'll know, if you use a public field and in the future you need to add some logic when getting or setting the value, you can't (unless you break the interface that you're providing to others). You can't, because the value isn't encapsulated.

With an automatic property, instead, you can add more logic whenever you want, without the need to change the interface that your class provides. Just replace the automatic property with a standard one. Or, vice-versa, you can replace the standard property with an automatic one. To an external user, nothing changes.

So no, you're not even remotely breaking encapsulation. You're just using an handy syntactic sugar.

Best Answer

Related Solutions

Java – When are Getters and Setters Justified

C# Automatic Properties – Should They Be Used?

Related Topic