Private vs. Public members in practice (how important is encapsulation?) [closed]

Answer 1

As someone having to maintain several-year-old code worked on by many people in the past, it's very clear to me that if a member attribute is made public, it is eventually abused. I've even heard people disagreeing with the idea of accessors and mutators, as that's still not really living up to the purpose of encapsulation, which is "hiding the inner workings of a class". It's obviously a controversial topic, but my opinion would be "make every member variable private, think primarily about what the class has got to do (methods) rather than how you're going to let people change internal variables".

Answer 2

I prefer to keep members private as long as possible and only access em via getters, even from within the very same class. I also try to avoid setters as a first draft to promote value style objects as long as it is possible. Working with dependency injection a lot you often have setters but no getters, as clients should be able to configure the object but (others) not get to know what's acutally configured as this is an implementation detail.

Regards, Ollie

Answer 3

I find lots of getters and setters to be a code smell that the structure of the program is not designed well. You should look at the code that uses those getters and setters, and look for functionality that really should be part of the class. In most cases, the fields of a class should be private implementation details and only the methods of that class may manipulate them.

Having both getters and setters is equal to the field being public (when the getters and setters are trivial/generated automatically). Sometimes it might be better to just declare the fields public, so that the code will be more simple, unless you need polymorphism or a framework requires get/set methods (and you can't change the framework).

But there are also cases where having getters and setters is a good pattern. One example:

When I create the GUI of an application, I try to keep the behaviour of the GUI in one class (FooModel) so that it can be unit tested easily, and have the visualization of the GUI in another class (FooView) which can be tested only manually. The view and model are joined with simple glue code; when the user changes the value of field x, the view calls setX(String) on the model, which in turn may raise an event that some other part of the model has changed, and the view will get the updated values from the model with getters.

In one project, there is a GUI model which has 15 getters and setters, of which only 3 get methods are trivial (such that the IDE could generate them). All the others contain some functionality or non-trivial expressions, such as the following:

public boolean isEmployeeStatusEnabled() {
    return pinCodeValidation.equals(PinCodeValidation.VALID);
}

public EmployeeStatus getEmployeeStatus() {
    Employee employee;
    if (isEmployeeStatusEnabled()
            && (employee = getSelectedEmployee()) != null) {
        return employee.getStatus();
    }
    return null;
}

public void setEmployeeStatus(EmployeeStatus status) {
    getSelectedEmployee().changeStatusTo(status, getPinCode());
    fireComponentStateChanged();
}

Answer 4

I would argue that this question does mix-up the concept of encapsulation with 'information hiding'
(this is not a critic, since it does seem to match a common interpretation of the notion of 'encapsulation')

However for me, 'encapsulation' is either:

• the process of regrouping several items into a container
• the container itself regrouping the items

Suppose you are designing a tax payer system. For each tax payer, you could encapsulate the notion of child into

• a list of children representing the children
• a map of to takes into account children from different parents
• an object Children (not Child) which would provide the needed information (like total number of children)

Here you have three different kinds of encapsulations, 2 represented by low-level container (list or map), one represented by an object.

By making those decisions, you do not

• make that encapsulation public or protected or private: that choice of 'information hiding' is still to be made
• make a complete abstraction (you need to refine the attributes of object Children and you may decide to create an object Child, which would keep only the relevant informations from the point of view of a tax payer system)
  Abstraction is the process of choosing which attributes of the object are relevant to your system, and which must be completely ignored.

So my point is:
That question may been titled:
Private vs. Public members in practice (how important is information hiding?)

Just my 2 cents, though. I perfectly respect that one may consider encapsulation as a process including 'information hiding' decision.

However, I always try to differentiate 'abstraction' - 'encapsulation' - 'information hiding or visibility'.