The importance of Interface classes

I am sure you might have heard about interfaces. But then why do you need them. You anyways are going to implement those classes. Why take the unnecessary overhead of writing interfaces for them as well.

Actually its not necessary to write a interface class for all classes that you write. But there are certain cases when its much much better if you have them in place.

First what are interface classes. Well this is a base class which has pure declaration of all the public methods need in the target class. All these methods are make pure virtual functions. No implementation is added to this class. For example if you write a class Time, you would want to declare an interface named, ITime. So the class declarations would be as follows.

class ITime 
{
      public : int getHour() = 0;
                   int getMinute()= 0;
                   int getSecond()= 0;
                   void setHour(int hour)= 0;
                   void setMinute(int min)= 0;
                   void setSecond(int sec)= 0;
};
class Time: public ITime
{
      public : int getHour() = 0;
                   int getMinute()= 0;
                   int getSecond()= 0;
                   void setHour(int hour)= 0;
                   void setMinute(int min)= 0;
                   void setSecond(int sec)= 0;
      private: int m_hour, m_min, m_sec;
};

The interface class has no implementation but the concrete class does. Concrete class contains all additional private member variables needed as well as constructors and destructors, as needed.

When do you need it? For classes which are instantiated at a few locations but used at a lot of other places, it makes sense to create interfaces for them.

But why do all this circus. Well the reason is pretty straight forward, to allow users of this class not care about whatever is there in the actual implementation. All internally used methods and variables are not known to the user of this class. Also since the concrete class headers are not included at all places where this class is being used, changes in internal implementation need not lead to compilation of each of the other classes. Only if something is changed in Interface class, recompilation would take place in all places else its a faster process.

This is more or less what I understand as a need for Interfaces. Please do let me know if you think otherwise.

const Vs #define, what to use and when

const one of the features which was not present in C but was introduced in C++. Its interesting to know why would anyone use const to declare constant values and not #defines which are being used since ages and have done the work more or less without much trouble.

Well the problem with #define is that its a preprocessor directive. Which means it needs to be put in a .h file for sharing among different files. But if it just needs to be used in a single cpp file, it works like a charm. But imagine that you need to include it in several files. Then you are in a big mess. If you make a simple change in that .h file, the build process will compile all files that include the header file. Which in case of big projects can mean a lot of headache.

So welcome to const. This can help you get rid of this problem. Since these const variables are actually compiled and not used as in case of header files. There is no need to compile all files using const variables, provided you make use of forward declarations  in the cpp files.

Const does not mean that it does not have any downside. It does have a problem. If you have a large number of declarations they all take some memory and you now understand what it can lead to. But in most cases, const is actually better than #define. But you need to take that call.

Note: The above is based on my understanding. If you think otherwise, do let me know why.