I know some C and a bit of C++. But some concepts, i do not get it. What means abstraction in C++ context? What is advantages of encapusulation? I just see it as waste of memory and cpu power. Thanks in advance.

Abstraction is a means for removing fine grained details and placing them behind higher level concepts. For example, taking a commonly used set of procedures and generalizing them into a function that can be called instead is abstraction.

Here is an example, let's say we want to do a lot of conversions from degrees to radians. I could either litter my code with the corresponding calculations or I can wrap the concepts in functions and call those instead.

template <class variable_type>
variable_type toDegrees(variable_type val){
return val*(180.0/PIE);
}

template <class variable_type>
variable_type toRadians(variable_type val){
return val*(PIE/180.0);
}

...elsewhere...
ourRadians = toRadians(degreeAngle);
ourDegrees = toDegrees(radianAngle);

vs littering your code with this every time you need to make a conversion:

ourRadians = val*(3.14159265358979323846/180.0);
ourDegrees = val*(180.0/3.14159265358979323846);

We've technically abstracted the value PI (cutely referred to as PIE) and the functions themselves in the first example and none if it in the second. Clearly the first example where we actually call the functions is much easier to read and deals with the more abstract idea of calling a well named function to perform the task instead of duplicating code.

This is a relatively simplistic example, if our functions were 100 lines, let's say, it would be foolish to replicate that code everywhere we needed it. But the main idea of abstraction isn't exactly the same as code re-use, the important thing about the concept of abstraction is that you take implementation details and hide them behind a more simplistic interface which leads to your next question.

What are the advantages of encapsulation? Well, there are a few. Encapsulation is the idea of holding similar information in a structure and it is often used alongside the term Data Hiding (abstraction is a similar idea, but used more broadly) which is the idea that you should produce an interface for what you are doing and hide the actual data structures that represent the tasks you request.

Let's say we come up with a more efficient method of performing radian and degree conversions somehow. If we have the equation littered everywhere in code it becomes a nightmare to update the way we do it. Similarly if you reveal implementation details of something you immediately incur a dependency on a method of doing that thing. Instead if you can provide a common interface you are given the freedom to change the implementation and as long as it performs an equivalent task there is no reason for the calling code to understand exactly how a task is being done.

Next, it makes it a lot easier to read code if you present a common level of abstraction at each juncture in your application code. For example, in the main loop of your program you will want to have only the very highest level of abstraction in your function calls. You shouldn't be worried about setting and checking state values directly. You should instead be controlling the flow of information and delegating to the proper functions to dictate the order things are done.

The next level down you might worry about the organization of things that you're going to be rendering, gathering input from the user and passing that off to the appropriate controls, and calling updates on the state of objects one more level down.

The next level down we've got a lower level of abstraction where we actually call the draw functions of the individual objects, pass the input to the specific structures and distribute that accordingly.

The next level down we may worry about individual rendering calls to whatever rendering system we use, acting upon the input given, updating the application state etc.

The final level we have the most implementation specific stuff going on, draw calls to opengl or directx and other things of that level of concern. The further down you get the wider concerns branch out.

Here is a diagram:


As you can see in this pyramid diagram, the number of things you have to worry about at each junction is much lower than if we re-wrote the diagram flat (which is what happens when we impose no data hiding or encapsulation.) If we look at this in terms of concerns at each level in this example we can see each branch as being dependant upon what is directly under it.

Each branch would be a problem domain we have to be aware of to use the current level properly. So at the top we need to be aware of two branches and no more. On the next level down of each of those branches in this diagram we only need to be aware of two things as well and so on. In this way a problem can be thought of as a series of smaller problems which can be more easily analyzed. Obviously some levels would have more and fewer than two branches each, but you can contrast this with the following (which has the same number of dashes as the above diagram each representing a concern. The only difference is that we flatten it out so that we assume the user must be well versed in the -entire system- in order to be effective in making modifications.)




The benefits of these ideas is much more clearly conveyed when you consider projects above the size of entry level code examples to display language ideas. Basically anything over 500 lines and you're going to immediately notice huge issues which may not cause you too much grief until you go over 1000 lines or so. From there it's almost exponential slow-down of implementation as you work on a teetering Jenga(tm) tower of code. This is assuming you take the stance that data hiding/encapsulation and abstraction are a "waste of memory and cpu power." which is in itself a pretty daft over-simplification.

Often you can improve performance by properly wrapping similar concepts together in a more abstract interface as common things can be simplified by giving the compiler hints as to what and how it can optimize. Beyond this, you should always focus on maintainability of code first and run-time second. Where performance is needed additional optimization may be required, but you should only favor performance over maintainability (which is closely related with readability) in mission critical low-level code that has a properly abstracted interface so that it can be easily swapped out when you have to port to other systems.

These topics are all much larger than I have presented here, but this should get you an answer to your question. For further reading: Wikipedia Knows and click through to things such as scope, transparancy and inheritance articles.

[Edited by - M2tM on January 10, 2009 3:35:11 AM]