Showing posts with label paradigm. Show all posts
Showing posts with label paradigm. 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.

Saturday, March 28, 2009

When Multiple Inheritance is bad

We all see and know that Multiple inheritance is one of the most classy features of C++. Something that was sorely missed in Java which did not allow. Well recently I realized that its actually a good thing if we just stick with single inheritance. Why, well the reason is simple.

 Diagram1

So now say you are the creator of all the classes, A,B,C, X and Y.  In that case your best approach would be if it was such that there was single inheritance. In that case you would have several benefits. For example if there was such a case that at some point of time, you need to use some function in B from class Y, you would not be able to do it. A single inheritance would provide you the extra flexibility to do operations on the object C in the base classes.

Well this is debatable that you should always stick to single inheritance or not. My take is that one hat does not fit all. So based on the situation, we need to take a call and do what best solves the problem at hand.

Friday, October 24, 2008

I know this code does not work as expected

Well I came across this amazing piece of code which does not crash as expected.

#include <stdio.h>
#include <stdlib.h>

int main()
{
    int i;
    int array[4];
    for(i=0; i<=8; i++)
    {
        array[i]=0;
    }

  return 0;
}

This seems to be perfectly ok code. Obviously it falters at the point where I set value to the array at index 4 - 8. Everyone would generally expect it to crash, but amazingly it did not. I tried it on wxDevcpp and it runs in an infinite loop. I was amazed at why it did. Its interesting to know what happened.

Let me first explain what actually happened. Casual observation revealed that the for loop runs forever. It seems that value of i is reset to 1 each time it reaches 7. Wow this is amazing. But what happened.

What happened is simple. Our incorrect program overwrites 'i' when it tries to put zero at array[7]. That because &array[7] is same as &i. Why? well thats because our amazing manner in which local variables are stored in the stack. So what happens is i  is there in the stack some place above array and we happen it make is zero each time.

Amazing simple reason why this kind of crappy thing happens.

Monday, February 25, 2008

Multiparadigm Programming

I had never ever known if any term like that ever existed in this world. But recently I did. Now what it actually means is that instead one we use several programming paradigms to the best of effect while coding.

As Leda designer Tim Budd holds it: The idea of a multiparadigm language is to provide a framework in which programmers can work in a variety of styles, freely intermixing constructs from different paradigms. := (wikipedia)

From what I understood is that C++ provides us means to make use of objects and design patterns as well as give us the ability to make use of Templates. That is to say that we make use of OOPS as well as generic programming paradigms makes C++ really powerful.