Link to home
Start Free TrialLog in
Avatar of ytgprasad
ytgprasad

asked on

data hiding

As you all know data hiding is one of the concepts of OO programming languages. Can you tell me what does it mean by hiding and how is it useful?
ASKER CERTIFIED SOLUTION
Avatar of Deckmeister
Deckmeister

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of ytgprasad
ytgprasad

ASKER

to Deckmeister: You answer is excellent. But I have a doubt,

suppose we have a function  f() like this

void f()
{
 int x;
 int y

....

}

the variable x and y are also hidden from those who use f. Does this also mean data hiding.
Mh, in a way. Compare the use of local variables in function against global variables. In the first case only the function is accessible, its local variables not. If the implementation (code) of the function changes nothing happens. In the second case (global vars), if we change the implementation of the function, for instance by removing y, all the code that uses that y has to be rewritten.

That is important about data-hiding (encapsulation), being able to change the implementation of one part of the programm (a class) without having to change all the code that uses that part. If you put data members in the public part (read 'interface') you can no longer modify those members without also changing the class' interface and breaking code that uses that interface.
To Kangaroo: taking into consideration what you said

let us take the same example of mine in the previous comment:

file f.c

void f()
{
int x;
int y;
..
..
..
}
suppose this is compiled to f.o this f.o is linked in some other program program and so on.

now suppose f.c is changed to
void f()
{
int x;
..
..
..
}
Deleted variable y and compiled to y.o; this y.o is linked and so on.

Do you notice one thing we are not changing any other code eventhough implementation of f.c is changed.

So should we call this also data hiding, since modification of implementation of one part is not reflecting in change of other parts like those which use the f().


To Kangaroo: taking into consideration what you said

let us take the same example of mine in the previous comment:

file f.c

void f()
{
int x;
int y;
..
..
..
}
suppose this is compiled to f.o this f.o is linked in some other program program and so on.

now suppose f.c is changed to
void f()
{
int x;
..
..
..
}
Deleted variable y and compiled to y.o; this y.o is linked and so on.

Do you notice one thing we are not changing any other code eventhough implementation of f.c is changed.

So should we call this also data hiding, since modification of implementation of one part is not reflecting in change of other parts like those which use the f().


I totally agree with KangaRoo.

I just want to add that data hiding in
C++ can be even more complex :

- x and y in your example are hidden.
  You do the same with functions of a
  class. But you also hide member
  variables of the class (where you
  surely would have global variables in
  C - or variables with a larger scope).

- it is not only possible to hide member
  variables in a class. Member functions
  can also be hidden.
  So you are able to write so-called
  service functions (that do a specified
  job but that don't have to be seen or
  used by common users).
To Deckmeister: you mean to say, any thing hidden like private variables, functions,local variable in the functions from the user of the class also mean data hiding.
To ytgprasad

Well, I would say that your second
example is also a kind of data hiding.

But if you read books about C++ or OOP
in general, you will probably not see
such examples explained as data hiding.

Traditionally, this is simply explained
as the scope of the variables.

PS: excuse me for my average English
Mh, more or less. I consider data-hiding a special case of 'encapsulation', the case where you are hiding data-members.
I see no need to seperate this in functions and data.

This encapsulation (and data-hiding) protects 'user' code from changes in the implementation of what it uses. Anything that is hidden can be changed, without any user knowing about it.
Excuse me for the time you waited for my
answers; I had a lot of work.

You are right. I think the same.
what my colleagues says is that: in C++ or any other object oriented languages the private members are hidden from users and interface (public functions)are provided to handle these private members. This way the private part is hidden from accidental changes. This is called data hiding.

Where as that of function that I had been discussing is merely scope of a variable as Deckmeister said.
Do you guys agree with my previous comment. If so tell me to whom I should award points
What I am trying to show is that encapsulation and data-hiding is not restricted to private members. You can use scoping rules to the same effect.

>> This way the private part is hidden from accidental changes

One primary goal, IMHO, is not just to protect the datamembers, it is to protect the (public) user from having to adapt to changes in the implementation. To protect him from having to know how to maintain the data.
Deckmeister off course. His answer was correct and the first. I was merely trying to 'expand' the view.

Agree, with one change:
>> This way the private part is hidden from accidental changes

should become:

This way the private part is hidden from accidental changes and the 'user' is protected from changes in the implementation.
ytgprasad, asked me to look at this, and I'm not sure why.  The information seems to be good.

I would defintely agree that local variables are a form of data hiding.  As I said in the other question, data hiding and encapsulation are made easier by OOP, but they can be done in non OOP languages.  This would be an example of that.

>> I consider data-hiding a special case
>> of 'encapsulation',
I would call it an "exntesion of encapsulation".  In encapsulation you are grouping together (to soem extent) data and code that work together and seperatig them (to some extent) from data and code that is idependant.  With data hididing you are just doing this to an extreme.  You are saying that this data is only associated with this code.  No code outside of this needs to ever access the data.

>> I am trying to show is that encapsulation
>> and data-hiding is not restricted to private
>> members.
Definitely.  Its not even restricted to OOP.  I used these techniques in assembly before I ever even heard of the terms.  Now in a non-OOP language--especially assembly--you can easily break encapsulation and other rules.  (intentionally or by mistake.)  C++ makes it harder to do this by mistake (although it does not make it harder to do intentionally) for this reason it tends to be easier and more reliable to use these sort of techniques from an OOP language.
Every one is saying local variables also a form of data hiding. Then what do you mean by OOP languages have data hiding and other concepts which was not there previously in procedural languages.
Hi again,

I've found this definition of data
hiding :

"Data hiding is a characteristic of object-oriented programming. Because an object can only be associated with data in predefined classes or templates, the object can only "know" about the data it needs to know about. There is no possibility that someone maintaining the code may inadvertently point to or otherwise access the wrong data unintentionally. Thus, all data not required by an object can be said to be "hidden.""
----------------------------------------
Sources: Robert Lafore, Object-Oriented Programming in C++, Waite Group Press, Corte Madera, CA, USA, (1995)

So, although data hiding techniques
existed before OOP, they are a key
element of OOP.
Moreover, you don't only have the possibility to hide variables, but
also entire functions or procedures.
As shown at

http://itc.fgg.uni-lj.si/~zturk/pouk/kth/oo-intro/soh022.htm

data hiding applies to entire objects, that's why it is an important point of OOP.
If you use C or another provedural language, you cannot perfectly hide variables common to many functions.
>> Every one is saying local variables also a form
>> of data hiding. Then what do you mean by OOP
>> languages have data hiding and other concepts
>> which was not there previously in procedural
>> languages.
Data hiding is not a feature only of OOP languages.  In fact there is no feture of OOP languages that cannot be implimented in a procedural language.  The best proof of this I can offer is that the original C++ compiler, called cfront, simply converted the user's C++ code to the equivalent C code.  OOP doesn't really add new abilities  like abstraction and  data hiding and virtual functions.  Those all exist in C, it is only that C++ has made it far easier for the programmer to use them and far harder to use the incorrectly.  

I use data hiding in assembly!  I create structures that (well in C/C++) it would look like

struct SomeStruct
{
   int A;
   int B;
}

How do I hide B without using "private" (which isn't available)?  I do it like so

struct SomeStruct
{
    int A; // explanation of A's purpose.
    int B; // Access to B is restricted to the XXXXX
            // class of procedures.
};

That is data hidding.  Yes a non-XXXXX procedure CAN access B, the assembler won't detect it as an error, so it is less reliable than C++'s data hidding, but it is the same concept.  And by the way, C++'s is not any safer against intentional "illegal" access to privates.  for example

class Cls
{
  private:
  int A;
}

function1 (Cls &Obj)
{
    int i = Obj.A;  // ERROR not allowed.
}

struct Str
{
 int A
}

function 2(Cls &Obj)
{
   
    int i = (*(Str*)&Obj).A;  // Now it is allowed.
}

(That is guaranteed to compile, but there is no guarantee that this will work correctly at run-time, although it will work correctly on virtually all C++ compilers.)
int i = (*(Str*)&Obj).A;  // Now it is allowed is not working.
Why?  Compiler error?  If so what?  Run-time error?  If so what OS and compiler?
Think you left out class Str

class Str
{
   public: int A;
};
No, I did it as a struct that appears before the function.
Ah, missed it.
to nietod : Now I am understading more correctly you comment saying

>>it is only that C++ has made it far easier for the programmer to use them and far harder to use the incorrectly.  

your example is very good. Thank you.