Confusion regarding encapsulation

  • Thread starter I_am_learning
  • Start date
  • Tags
    Confusion
In summary, encapsulation in object-oriented programming helps to protect and control access to data within a class. It prevents accidental changes to data and allows for easier maintenance and updates. While encapsulation may not always be necessary, it can be beneficial in cases where data needs to be protected or manipulated in specific ways. It also allows for intellectual property protection and can improve the overall organization and structure of code.
  • #1
I_am_learning
682
16
I am reading on Object Oriented Programming and I feel a bit uncomfortable with the concept of Encapsulation.
"Encapsulation helps encapsulate data so that code outside of the class can't change it accidentally."
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
 
Technology news on Phys.org
  • #2
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.
 
  • #3
I_am_learning said:
If a programmer wants to change property of an object, he knows what he is doing.

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.
 
Last edited:
  • #4
I_am_learning said:
I am reading on Object Oriented Programming and I feel a bit uncomfortable with the concept of Encapsulation.

Encapsulation helps encapsulate data so that code outside of the class can't change it accidentally.

AlephZero said:
The point of encapsulation is to define exactly what things are "properties of an object" and what are not.
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.
 
  • #5
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.
 
  • #6


mfb said:
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.

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 ?
 
Last edited:
  • #7
I_am_learning said:
If I made the class, then I know what accessing an internal variable will do.
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.

Can some one give me an example where I must encapsulate property of my own classes that I intend to use myself alone?
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.
 
  • #8
D H said:
This function was never designed for external use. You knew this six months ago, but that detailed design knowledge is long gone.
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.
 
  • #9
rcgldr said:
Encapsulation doesn't solve all of this problem.
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).
 
  • #10
I_am_learning said:
If I made the class, then I know what accessing an internal variable will do.
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?
 

What is encapsulation?

Encapsulation is a principle in object-oriented programming that involves keeping the internal workings of a class or object hidden from the outside world. This is achieved by setting certain data and methods to be private, meaning they can only be accessed and modified by other methods within the same class.

Why is encapsulation important?

Encapsulation helps to improve the security and maintainability of code. By hiding the internal workings of a class, it reduces the likelihood of unintended modifications and helps to prevent external code from directly accessing sensitive data. It also allows for easier updates and changes to be made to the code without affecting other parts of the program.

How does encapsulation relate to data abstraction?

Encapsulation and data abstraction are closely related concepts in object-oriented programming. Data abstraction involves presenting only essential information to the user, while hiding the implementation details. Encapsulation helps achieve data abstraction by controlling access to the internal data and methods of a class.

What is the difference between encapsulation and information hiding?

Encapsulation and information hiding are often used interchangeably, but there is a subtle difference. Encapsulation refers to the process of hiding the internal workings of a class, while information hiding refers to the result of that process. In other words, encapsulation is the mechanism, while information hiding is the end result.

What are some examples of encapsulation in real-world applications?

Encapsulation can be found in many real-world applications, such as banking systems, where sensitive user information is hidden from external access. It is also commonly used in software development, where classes and objects are encapsulated to prevent unintended modifications and maintain the integrity of the code.

Similar threads

  • Programming and Computer Science
Replies
9
Views
1K
  • Programming and Computer Science
Replies
10
Views
2K
Replies
10
Views
904
  • Programming and Computer Science
Replies
5
Views
3K
  • Programming and Computer Science
Replies
18
Views
5K
  • Programming and Computer Science
Replies
2
Views
2K
  • Programming and Computer Science
Replies
2
Views
2K
  • Programming and Computer Science
Replies
4
Views
1K
  • Programming and Computer Science
Replies
13
Views
3K
Back
Top