Confusion regarding encapsulation

I_am_learning

I am reading on Object Oriented Programming and I feel a bit uncomfortable with the concept of Encapsulation.
And I keep wondering, how can someone 'accidentally' COMPOSE code (to change data) ? We far more frequently accidentally mistype and misspell than accidentally compose code. If a programmer wants to change property of an object, he knows what he is doing. Programmer do know what they are doing in lots of other places, then why here are they distrusted?
And Its kind of funny when programmers first hide (encapsulate) the data and then start to make methods to read and set the data. Sort of like Breaking your own leg and then making a wheelchair.
Concept of Encapsulation feels like a great conspiracy! :D

rcgldr

I'm not sure about the argument about avoiding changing data "accidentally". The same argument was made in early versions of Pascal that didn't allow math to performed on bytes (characters), requiring they be copied to integers in order to peform math and then copied back.

Having static internal variables for a method or set of methods that aren't meant to be accessed externally would make the most sense.

Another argument for encapsulation is that if some aspect of the data element changes that would normally affect the code accessing that data element, the call interface using the get and set methods could remain the same.

Some concepts of encapsulation pre-date object oriented languages. For example, in a classic "C" windows program, the main loop receives messages as parameter, and the user code doesn't have to deal with the internal message queing system or free pool. I've worked on projects that do a similar thing for multi-threaded applications. The "user" message function interfaces pass data via a user structure (the parameter is a pointer to the structure) to receive or send inter-thread messages, without having to deal with the internal thread and free pools for system messages. An internal change to the message system from a circular fifo to a linked list fifo would not affect the send and receive message functions.

AlephZero

The point of encapsulation is to define exactly what things are "properties of an object" and what are not.

Obviously the programmer who is writing the code for the class that defines the object can do anything he/she wants. But in the real world most programmers who use the class don't have any access to its source code, and don't know how its data is stored internally.

Often it is better that programmers who use an object don't know how it is implemented. For example, a class that controls access to something with user names and passwords shouldn't allow any programmer to get a list of all the user names and passwords on the system, by accessing the way the data is stored internally!

A different type of example would be a class that stores dates and times. There will probably be "get/set" methods for several different formats (12 or 24 hour clock, different time zones, names of days/months in different languages, even completely different calendars like western/chinese/jewish/islamic, etc). Internally, the class probably stores all date and times in just ONE format, but the programmer using the class doesn't need to know what that format is, and shouldn't be writing code that depends on knowing what it is.

An analogy to all this is driving a car. All modern cars have the same basic set of controls - steering wheel, accelerator and brake pedals, etc. You can USE the car to get from A to B by accessing those "properties", without knowing how they are actually implemented - for example whether the steering is power assisted with a hydraulic system or an electric motor, or whether the brakes are mechanical or use regenerative braking to recover energy.

rcgldr

I think the issue is the statement from the article or book about changing data accidentally. In addition, many articles introducing the concept of encapsulation use poor examples, where encapsulation doesn't accomplish much. Your statement about "properties of an object" is a much better example.

mfb

As another example, changing one parameter might have other consequences in the class - or the range is limited in some way and the Set method will check this. If you have direct access to the internal variable, you could insert meaningless values.

I_am_learning

If I made the class, then I know what accessing an internal variable will do.

I agree on encapsulating property on classes that are for distributing to public for the sake of hiding the internal mechanism I.e as a means of intellectual property protection. But I doubt that someone can guess internal mechanism simply by looking at the internal properties.
Can some one give me an example where I must encapsulate property of my own classes that I intend to use myself alone? Certainly, I don't need to prevent myself from doing things. If there is no meaning of setting or getting certain property, then I won't do so. I find lots of my friends first making some important property private and then writing getter and setter functions. Yes, like in the date example given above, it makes sense, but when the getter and setter function just relay the data as it is, then what's the point.

I also agree on encapsulating data that have 0 meaning outside. Atleast its no harm. Also in IDE where you are provided with dropdown list of public property, hiding such meaningless (for outside world) property will help unclutter the list. But for data you use, what's the point of hiding and then using getter ?

D H

That's not the issue. The main issue is other programmers who use your class. Another issue is that even you as the author of a class should not be touching internal variables when you are operating outside of the bounds of the class.

Suppose you make everything public, all the data, all the methods. At some point you'll finish developing some class. Six months later you find you need to use that class somewhere else. Your wrote the code for yourself, so there's no design document, there's few if any notes, there's nothing but the code. You need some function, and there it is. The problem: This function was never designed for external use. You knew this six months ago, but that detailed design knowledge is long gone.

You have just toasted your own code.

rcgldr

Encapsulation doesn't solve all of this problem. You could have a set function that returns a status to indicate if the set was sucessful or not, but without documentation about the restriction on what the set function allows, it's still an issue. The advantage of the set function is that if there's a failure, it's detected at the time the value is being set, rather than being caught or causing problems later. There's still the problem that the failing case may never occur during testing, but only in during actual usage, so it's important that the released program include error handling to indicate where in the code any error occurred.

D H

Of course it doesn't. There are no silver bullets. "There is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity." That's the abstract of "No Silver Bullet — Essence and Accidents of Software Engineering" by Frederick P. Brooks, Jr., IEEE Computer, 20:4 (1987).

mfb

Even if you know this exactly, every time you need it and even years in the future: Do you want to care about that every time you access this variable somewhere?
On a more abstract level: Do you want to remember which parameters really need set/get functions and where you can access parameters directly?