Why do we study classes and objects?

Pages: 123
There are many features that classes bring to c++ out of which data hiding is one such feature.
From what are we hiding the data?
If we need to hide data from a external program shouldn't we actually make sure that the program data is encrypted?
When i asked the question about data hiding to my teacher he said that we need to protect data of one class from another class.That to me makes no sense because if i write two classes: Class a and class b.
Why would i write code in class b which creates unnecessary problems to my class a data members?

Note: I can write cpp programs using classes and objects...infact my exams are over as well.. But i still want this is all about.
Thanks.

From what are we hiding the data?


This question is going to bring opinionated answers.

In my experience with classes and objects, I often hide data from myself so I cause less errors when reading/writing data in memory. By making data private only certain methods that are contained by the class can manipulate this data.

Imagine a bank terminal, that doesn't hide your pin while trying to access your bank. A lot can go awry with just 4 public digits.

It's a bit of a crude example. I'm sure those with more experience can give you further information.


shouldn't we actually make sure that the program data is encrypted?

Encrypted doesn't mean private, or hidden. It means encrypted.

Besides in some cases they do encrypt the data, but then you will have efficiency problems, if you have to decrypt something to read it, then change, then encrypt it again before you store it.
Private (hidden) data sends message that it is implementation detail and you should not rely on it and should use public interface instead.
Example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
class Polynome2 //Represent polynome ax^2 +bx + c
{
public:
    //public interface
    int& getA() {return a;}
    int& getB() {return b;}
    int& getC() {return c;}

    //this should be private , but we forgot to mark it such
    int a;
    int b;
    int c;
};

//Bad function: depends on implementation
void foo(Polynome2& baz)
{
    baz.a = baz.b = baz.c = 0;
}

//Good function: depends on interface
void bar(Polynome2& baz)
{
    baz.getA() = baz.getB() = getC() = 0;
}
Now imagine that we found out that having three distinct variables causes slowdown and decided to use array instead:
1
2
3
4
5
6
7
8
9
10
11
class Polynome2 //Represent polynome ax^2 +bx + c
{
public:
    //public interface
    int& getA() {return coeff[0];}
    int& getB() {return coeff[1];}
    int& getC() {return coeff[2];}

    //this should be private , but we forgot to mark it such
    int coeff[3];
};
Now bad function foo does not compile and good function bar works fine.

Tight coupling with implementation makes it extremely hard to modify classes (as you would need to modify everything using it) and replace one with other (as you need not only to implement interface, but find out which internals are used by other classes).

Also it might lead to class invariant violation: vector usually holds two pointers: to the beginning and end of buffer. What if somebody swap those two around? Most of vector functions will stop working correctly. And it would lead to serious problems when you will try to delete memory by that new pointer.

So data hiding in OOP saves you from accidently doing something you are not supposed to do. It will not prevent you from doing something deliberately, but if something happens, it would be completely your fault.
This might make more sense to look at it in terms of a GUI. Each window is a class. Suppose you have a window with a text box for a name and another with the same text box for a different name. Would it not make sense to have those text boxes separate some how? Sure you could have name_txt1 and name_txt2 if they are in the same class, but how would you keep track if you had many classes and they related to different things in different windows?

It has nothing to do with encryption, it has to do with localizing data. It is the same principal as variables having scope.
From what are we hiding the data?

You're misunderstanding data hiding. When you declare variables as private in a class, you're not hiding the data from other programs, you're hiding the data from other classes and code in YOUR program.

As other have explained, by providing interfaces in your class, you are providing controlled methods by which the private variables in your class can be modified. Compare this with a global variable that can be modified willy-nilly all over your program. That is a nightmare to maintain.

if i write two classes: Class a and class b. Why would i write code in class b which creates unnecessary problems to my class a data members?

You wouldn't (or shouldn't). The fact that you're asking the question, indicates that you understand why you should not do that.

We see all the time on this forum where a begginner has made his class variables public either because he is too lazy to properly encapsulate them, or doesn't understand why he should do so.

Megatron 0 wrote:
In my experience with classes and objects, I often hide data from myself so I cause less errors when reading/writing data in memory.

Bingo.

Megatron 0's pin code example is a situation where data should be encrypted within a class. In an ATM or POS device, the class representing the pin pad should accept the digits entered by the user and immediately encrypt them, storing only the encrypted pin within the class. The clear pin should never be stored within the device to prevent it being discovered by memory scraping malware (aka the Target hack). Ensuring the pin is always encrypted and is only accessed through a known interface is easy if it is stored in a private variable in a class representing the pin pad (or even a class representing just the pin) and the only access is to the encrypted pin via public methods of the class.

So, what i got to know from all the above answers is that: We hide data of one class from the functions of other classes.
Classes helps provide a structure to the program's data and functions.So, will I understand how "actually" this data hiding is so great, by coding programs using classes and objects?
So, will I understand how "actually" this data hiding is so great, by coding programs using classes and objects?

That is really going to depend on your grasp of the language and the concepts behind it.

To really appreciate data hiding, I feel that one needs to feel the pain of debugging a program where the data is not hidden and is being modified all over the place in the program. IMO, only then can you truly appreciate why data hiding is important.

I coded in several non-OO languages before learning C++. Those languages gave me a great grasp on programming concepts, but since those were not OO languages they did not provide data hiding, encapsulation and the other features of C++. Once I saw what C++ could provide in terms of improving the correctness of my programs, I never wanted to go back to those languages.

I coded in several non-OO languages before learning C++. Those languages gave me a great grasp on programming concepts, but since those were not OO languages they did not provide data hiding, encapsulation and the other features of C++. Once I saw what C++ could provide in terms of improving the correctness of my programs, I never wanted to go back to those languages.

I think that when the coding increases to about 10k+ lines, we need these features.
Thank you all for your response.
10k lines is a very arbitrary number. Programs as small as a few hundred lines can benefit from data hiding.
I write programs with upto 1k lines of code. I wrote a library management software but never had to worry about hiding my data. All were global variables. I used structs without the data hiding feature for data.
To really appreciate data hiding, I feel that one needs to feel the pain of debugging a program where the data is not hidden and is being modified all over the place in the program

+1.
I cannot agree with this enough.

I write programs with upto 1k lines of code. I wrote a library management software but never had to worry about hiding my data. All were global variables. I used structs without the data hiding feature for data.

PO, does anyone else develop on your projects?

I think that when the coding increases to about 10k+ lines, we need these features.

I don't care if it's 10k lines or 10 lines, encapsulation is incredibly important.
Last edited on
Nah... No one updates my cpp code.It was just for experience.
Last edited on
Nah... No one updates my cpp code

I had a feeling you'd say that.
:P
never had to worry about hiding my data.

A bad practice.
All were global variables.

Another bad practice.
I used structs without the data hiding feature for data.

If any programmer working for me did not use data hiding, he wouldn't be working for me for long.

Last edited on
Yes! AbstractionAnon. But, I wont use data hiding just for the sake of it. I will code the rest of my programs without data hiding and classes and objects. When, I have the maturity to understand why data hiding is necessary Ill start using it.
When, I have the maturity to understand why data hiding is necessary Ill start using it.


Kinda shooting yourself in the foot there lad, you will appreciate it by using it.

Kinda shooting yourself in the foot there lad

Dude I am still a beginner. I haven't done a lot of programming. By that sense I am still immature, when it comes to programming. Certainly many of the C++ concepts evolved because of deficiencies of C.
If I can feel the deficiencies, I will switch to classes and objects.

It's like you're learning Spanish for example, and saying "yep, i know my spelling's all wrong, but i won't worry about that until i get the verbal pronunciation's correct first".
dude, whats the big deal. Thats how i study.
Until i understand why I should switch to something I dont switch.

At first i didnt even use functions, except main().
When i began to feel to much irritation, I switched to functions...and now i cant live without them.

Dont just jump on concepts unnecessarily without understanding why you should adopt them.
Pages: 123