Abstract class vs. Interface

[ami]

Hello,

I read about interfaces and it says :-

...
An interface is not a class. When we create an interface, we are basically creating a set of methods without any implementation that must be overridden by the implemented classes.
...

But, isn't this what we do when we create abstract pure virtual class ? Can someone please tell me what is the difference ?

Many thanks.

[Danny]

Essentially, an interface *is* an abstract class but there is a slight difference between the two terms. An abstract class is one that has at least one pure virtual function. You cannot instantiate such a class even if the rest of its member functions are fully defined:

class A
{
public:
 virtual ~A()=0; //pure virtual, hence the class is abstract
 virtual int f() { return 0;} //not pure, but still, A is abstract
};

By contrast, an interface defined all of its member functions as pure virtual. It has no data members and only public member functions. Often, it's a struct, not a class, to emphasize the fact that its member functions are all public:

struct File
{
virtual  ~File()=0;
virtual int Open(int mode)=0;
virtual int Close()=0;
virtual int Delete()=0;
virtual int Rename(const char*)=0;
};

An interface is not a C++ term. It's borrowed from other languages or design concepts. In C++, an interface means: the public members (data and functions) of the class.

[ami]

Many thanks for that Danny.

How would you go about data hiding in "interfaces" if they are all public ? (I don't mean the C++ interface as you refered to the data members and functions of a class, but similarly to one as you say borrowed from C# or Java) ?

Also, in other words, is this type of design just like some sort of a template for other programmers to inherit from your 'struct' and implement each method later in the inheritance ?

Thanks for your help.

[jonnin]

The interface is the user level, there is no data to hide (thats all inherited or whatever). Its just a wrapper to expose to the user the names of the objects that can be created and the methods that can be called by the user --- think of it as the wrapper you put around a library that you sell to someone to enable them to call what they need while everythign else in the system is hidden from them simply by not being included in the wrapper class/struct/whatever.

It may or may not have virtual functions that the user can over-ride, some do and some do not. When you buy a library, most of the functions are not virtual, for example, they do the stuff that you spent good money to have done for you, it doesnt make sense to buy a bunch of empty functions that you write yourself... =)

[hendrixj]

Danny,
You have a parameter defined for your destructor. What does that mean?

[Danny]

Danny,
You have a parameter defined for your destructor. What does that mean?

Oops, just a typo. I had a constructor in mind...

[hendrixj]

This may or may not help:
- In general inheritance of a base class (abstract or not) is used to implement a "isa" relationship: a square is a rectangle, a robin is a bird, etc.
- Sometimes however, objects have similar behaviors without actual sharing a "isa" relationship. A pure virtual base class (called interface in some circles/languages) is an abstraction of what several non-related classes *do* as opposed to *are*.
- Bot birds and airplanes *fly*, but they don't inherit from a common ancestor.

Many objects need to save themselves to output streams and restore themselves from input streams. Sometimes this is described in a pure abstract class:

class Serializable
{
    virtual bool serialize(std::ostream&)=0;
    virtual bool deserialize(std::istream&)=0;
};

Multiple inheritance of these "interfaces" is less error-prone (at least some would say) than multiple inheritance of meaty classes.
There are plenty of practical and philosophical arguments on this topic.

[Danny]

Many thanks for that Danny.
Also, in other words, is this type of design just like some sort of a template for other programmers to inherit from your 'struct' and implement each method later in the inheritance ?

Thanks for your help.

yes, that's exactly the point. Interfaces are a means of enforcing a certain set of services, without specifying the implementation. So you never have data members in interfaces -- data members usually belong to the implementation. Take for example the File interface. It's just a means of guaranteeing that everything that's called a file supports certain services, even if the file in question isn't a physical disk file.