0

Member variables of a class are typically hidden from the outside word (i.e., the other classes), with private access control modifier. Access to the member variables are provided via public assessor methods. This follows the principle of information hiding. That is, objects communicate with each others using well-defined interfaces (public methods). Objects are not allowed to know the implementation details of others. The implementation details are hidden or encapsulated within the class. Information hiding facilitates reuse of the class.

I have a question why set member variables as private and access these variables via public method is secure than direct access to member variables with public modifier. These 2 ways achieve the same result, meaning it both changes the values of member variables. Can anybody explain to me more clearly! Thanks,

vqtuyen
  • 15
  • 1
  • 5

2 Answers2

9

Because information hiding is not a security measure. It's a human-oriented measure for improving understanding.

The point of making a field private is not to prevent it from being changed. If an attacker wants to change values, well, if they have access to your program's process, they can change the values easily, no matter how the source code defined those values. It's all just bits in memory or in a cache somewhere anyway.

Then what is the point? Information hiding makes it easier to reason about your program when someone else (or you, two months down) has to understand it or change it. By not exposing the exact fields that a class is composed of, it becomes easier to understand what purpose it serves, whether to use it or not, which methods to call etc. What would you rather do - call a method hitBrakes() or write flags.frictionCoefficient &= 0x487FD3?

But that's a large difference. Is a small difference such as the one between car.setPrice(12345) and car.price = 12345 really worthwhile? Oh yes, it is. By programming an accessor rather than exposing a public field, you have given yourself the option of changing the implementation of that accessor some day. Maybe it becomes necessary to include validating logic into that accessor, or even to make it inoperable and just retained for backward compatibility. With a public field, you can do none of those things without breaking client code.

And this is why information hiding is good - not because someone else must not see it, but because you don't want to see it. Information that isn't public cannot become a constraint on future development.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
  • 2
    In particular, car.price = -12345 is almost certainly a mistake, but will not be detected. Whereas, in car.setPrice(-12345), a well-written setPrice function should detect the error and act accordingly - perhaps throwing an exception. – Simon B May 09 '17 at 09:19
0

I'd like to add this to the good answer of @KilianFoth

getter/setter methods as described in your quote violate information hiding principle.

In general we have two kinds of objects:

  • pure data containers (aka Value Objects or Data Transfer Object)

    These object have no logic of their own (except very simple validations). For such classes we don't want to hide the inner structure because thats what they are all about. We could accept public properties here but most frameworks dealing with VOs/DTOs expect them to have getter/setter methods.

  • business logic implementations

    These objects implement the logic of your programs. We want this to be flexible to use. Therefore we need information hiding for them and this in turn means we should avoid getter/setter methods.

Timothy Truckle
  • 2,336
  • 9
  • 12
  • 1
    Value Objects actually do contain behavior. They are domain objects which, unlike entities, do not have an identifier but are identified using their internal values. They are not dumb property bags like DTOs. – Andy May 09 '17 at 12:08