Showing posts with label interface. Show all posts
Showing posts with label interface. Show all posts

Saturday, October 24, 2009

An example of Interface pattern in use

Interface pattern is a interesting pattern and only recently I realized the value of using it and where people put it into use.

One real interesting use of this that I found was in using callback functions for components.

Say you want to use a component A1 in a class B. But this component A1 needs to get some information from its user, class B, then we need a callback. How does one make sure that the right callback is provided by the implementer. Well interface pattern provides a simple solution for this.

To make to use of interface pattern, we need to implement an abstract class A2. This class should have the function which we want to use as callback as a pure virtual function. Now each class which needs to use component A1, should inherit A2 and implement the desired callback function in A2.

Example, implementation of this is as follows

class A2
{

public:

        void CallBackFunc() = 0;

}

class A1
{

public:

        A2 *user;

         A1(A2 *userClass)
        {

               user = userClass;

        }

        void action()
        {

              user->CallBackFunc();

        }

}

class B : public A2
{

       B()
       {

             A1 *newObj = new A1(this);

       }

        void CallBackFunc()
        {

             //Do something here

              return;

        }

}

Thursday, July 9, 2009

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.