Hi!Can you give where c++ abstract class concept gives benifit to software developer?
I mean in what situations he can use that abstract class concept.
Abstract classes - or abstract base classes as they have to be inherited from to create types that can be instantiated - are useful whenever a developer (of any gender) wishes to define a common way of interacting with objects of a set of types but does not have specific implementations for all the defined operations (or any of the operations when modelling an interface). Such situations will become apparent during the development process.
Interfaces in particular are a powerful abstraction as they help de-couple code, allowing making the only thing common between sections of code the (abstract) interfaces. One section of code does not need to know about the specifics of another, only the interface(s) it supports.
As an example I recently defined a set of abstract base class types that defined I/O operations for reading and writing binary values to general purpose IO (GPIO) pins - in this case the language used was Python not C++ - I mention this example to show that abstract (base) classes are not just a C++ concept (although for languages like Python are less useful due to their different approach to types).
The classes were deliberately similar to some Python library IO abstract base classes (ABCs) used for file IO and the like - although not all things translated to the GPIO cases I was concerned with. In my case, as a GPIO pin could be either input (read from) or output (written to) but not both at the same time I separated the read and write cases into separate sub-abstract base classes. The root abstract base class defined only common operations such as close and a set of operations to query the capabilities of a GPIO I/O object such as closed, readable, writable. There were no sane common base implementations for any of these operations so they were all abstract - pure virtual in C++ terms. However, the reader and writer sub-ABCs that added either an abstract (pure virtual) read or an abstract write operation to the existing operations, also defined some of the query operations as in these cases a reader will be readable and not writable and a writer writable but not readable. However, concrete implementations still need to define how to close an open GPIO object, how to determine if the object is closed, and of course a read or write operation.
A C++ example I have used a couple of times before in AllExperts answers is that of an abstract base class used to define the interface to a 2D board game renderer, which is simplified from some of my own code circa 2003/2004. See:
for one such answer (the other is so old AllExperts seems no longer to have it around).
I reproduce, slightly updated, some of that answer for you here. You might like to read the original answer anyway as it makes some additional points I am not going to repeat here:
( ::CWindowGc & aGc
, ::TRect const & aRegion
) = 0;
( ::CWindowGc & aGc
, ::TPoint const & aCell
, ::TUint32 aNewState
, ::TUint32 aPrevState
) = 0;
The code that makes use of game renderers pass around MGameRenderer pointers and uses them to make calls to the MGameRenderer operations. Somewhere there is a factory object that creates objects of specific implementations of MGameRenderer e.g. by using new. The factory returns them as a MGameRenderer pointer:
MGameRenderer * CRenderer::NewGameRenderer
( ::TInt aGameDimension
, ::TRect const & aGameRect
return new CGameRenderer( aGameDimension, aGameRect );
Again this is a simplification of the actual situation. The CGameRenderer class provides implementations for DrawBoard and DrawCell. In the program I provide a basic implementation that draws the game board and the board cells using simple 2D graphics operations such as drawing lines and circles. A fancier implementation might use pre-drawn graphics or even animations for the board and cell states. The renderers are built as separate components so such additional renderers could be written, built and installed at a later date and the user would select the one they wish to use from the set of installed renderers.
Another example would be database interaction. A common way of interacting with relational databases is not that difficult imagine - after all they tend to do similar things in similar ways. However the specifics of interacting with different relational database systems is almost certainly going to be different for each RDBMS (Oracle, MySQL, Postgres, Sybase SQL Server, MS SQL Server, IBM DB2, Informix, SQLite, etc,).
Hope this gives you some hints at least.