Regarding Encapsulation

[vinay garg]

Hi,

I have a doubt regarding the concept of encapsulation.

Isn't C language also does the encapsulation by 'struct' data type?

I am trying to relate this concept to understand C++ encapsulation.


-vinay

[hamsterman]

Encapsulation is when you hide things (implementation details) from whoever uses your class. A struct merely groups several variables.

[vinay garg]

the data variables and the functions present in the struct can only be called by the struct variable. and no other variable in the system. Isn't it data hiding?

[Ortonas]

Okay, example; imagine, you have a game which has a player which caries a rocket launcher. Rocket launcher's fire rate is let say, 20 rockets a second. Which means, at the same time you will have on screen defiantly more than one rocket. You have GUNS class and GUNSOBJECTS class. On guns class you have code something like

//Blah blah blah...
//Uhh! Player just shot a rocket!
GUNSOBJECTS[?]->spawnRocket();

The question mark is the problem. You cannot put in a static number, because the new rocket will keep replacing old rocket. You could put in a counter, but if you do that, you need to have separate function which would track statuses of GUNSOBJECTS classes and it would return a free instance number. Problem solved? Kinda. It would do the job, but the problem is - what if not only GUNS class wants to create a GUNOBJECT ? Maybe you have bot which also has a rocket launcher? Maybe rockets will be launched by the level? In all those cases you will have to drag that GUNOBJECTS instance tracker which is completely necessary. So, the better way would be to have additional class called GUNOBJECTSENCAPSULATED which would deal with appropriate instance calling and would also call certain functions.
So, now, with encapsulated ROCKETOBJECTS, whatever wants to fire a rocket, they would laterally need just to write a line of code such as

//Blah blah blah...
//Uhh! Player just shot a rocket!
GUNSOBJECTS->spawnRocket();

And that is it.
That is just simple example. There are way better ways to deal with such objects like having and objects manager and using the polymorphism and things like that.

[hamsterman]

Well, in C++, struct is no different from class, but traditionally, a struct looks like

struct Foo{
   int foo;
};

And now the code

int main(){
   Foo f;
   f.foo = 7;
}

will work. It would not work if you replaced struct with class of just specified private access rights.

[mik2718]

The word is 'interface'

Forget about the data members, these are the problem not the solution.

The interface is the public section of constructors and methods made available to the user of the class (which may be you with a different hat on). Getting this interface right is the main problem in class design.

Building on Ortans' example suppose we have an abstract weapon class which is just an interface

class Weapon
{
public:
  virtual missile fire() = 0;
  virtual void reload(int amount) = 0;
  virtual int ammoLeft() const = 0;
};

We can then derive concrete weapons from this, e.g. Gun, MissileLauncher etc. A Player has a Weapon and this can be any class derived from Weapon with a 100% guarantee that it will work because the data is private and the Player operates the Weapon only through the interface with no under the table direct manipulation of the Weapons internal data possible.

Also, we can invent new Weapons, derived from Weapon, and put them into the game and they will work with no change to the existing game code required. That's encapsulation.