interface is an higher level of abstraction which means it can contain only the declarations
ex:
interface sample
public sub print()
public sub sum()
end interface
we can implement the interface in a class by using the implements keyword
ex
public class sampintrface()
{
implements sample
public sub sum()
{
code to print sum
}
}
we dont have interface in c++ only in java and dot net
this is done in dotnet
What is the meaning of interface and implementation in c++? explain in datail?
The First Version
First, some macros are defined in a header file that you'll probably want to include in your precompiled headers:
//
// CppInterfaces.h
//
#define Interface class
#define DeclareInterface(name) Interface name { \
public: \
virtual ~name() {}
#define DeclareBasedInterface(name, base) class name :
public base { \
public: \
virtual ~name() {}
#define EndInterface };
#define implements public
By using these macros, you can declare an interface in the following way:
//
// IBar.h
//
DeclareInterface(IBar)
virtual int GetBarData() const = 0;
virtual void SetBarData(int nData) = 0;
EndInterface
Then, you can declare a class that implements this interface with something like the following:
//
// Foo.h
//
#include "BasicFoo.h"
#include "IBar.h"
class Foo : public BasicFoo, implements IBar
{
// Construction %26amp; Destruction
public:
Foo(int x) : BasicFoo(x)
{
}
~Foo();
// IBar implementation
public:
virtual int GetBarData() const
{
// stuff...
}
virtual void SetBarData(int nData)
{
// stuff...
}
};
Easy, isn't it? Without much effort, you now are able to use interfaces in C++. However, because they aren't directly supported in the language, you are supposed to follow some rules that can't be automatically enforced at compilation time. After all, all that the compiler can see is the use of plain old multiple inheritance and abstract base classes. Here are the rules you need to follow, along with some recommendations:
* When declaring a class, use the first base class for "structural" inheritance (the "is a" relationship) if there is one, as you normally do. (For example: CFrameWnd derives from CWnd, CBitmapButton derives from CButton, YourDialog derives from CDialog, and so on.) This is especially important if you are deriving from MFC classes; declaring them as the first base class avoids breaking MFC's RuntimeClass mechanism.
* Use additional base classes for interface implementation, as many as you want or need. (For example: class Foo : public BasicFoo, implements IBar, implements IOther, implements IWhatever, ...)
* Do not declare any member variables inside the interfaces. Interfaces are intended to express behavior, not data. Besides, this helps to avoid some problems if you were to use multiple "structural" inheritance and happened to be deriving more than once from the same interface.
* Declare all the member functions in the interfaces as virtual pure (in other words, with "= 0"). This ensures every instantiable class that declares to implement an interface does it for all its functions. It's okay to partially implement an interface in an abstract class (in fact, it will be abstract anyway if you do so) as long as you implement the remaining functions in the derived classes you actually intend to instantiate. Because the interfaces offer no "basic" implementation, you need to be sure everyone that receives a pointer to some interface will be able to call any of its members; declaring all your interface members as virtual pure will enforce this at compile time.
* Do not derive your interfaces from anything but other interfaces. You can use the DeclareBasedInterface() macro for that. Normal classes can choose to implement the basic interface or the derived (extended) one; the latter of course means implementing both.
* Assigning a pointer to a class that implements some interface to a pointer to that interface requires no casting, because you will be actually casting to a base class. Doing it the other way though (from an interface pointer to a pointer to the class implementing it), will require an explicit cast, as you will be casting to a derived class. Because you will in fact be using multiple inheritance (even if for virtually every other practical need, you can think of it as single inheritance plus interface implementations), these casts can't be done the "old" way because they may need different actual memory values. However, enabling Run-Time Type Information (/GR compiler option) and using dynamic casts works fine and it's of course safer anyway.
* Further, the use of dynamic_cast will give you a way to ask any object or interface whether it implements a given interface or not.
* You need to be careful to avoid name conflicts between functions in different interfaces because it isn't easy to detect and resolve those conflicts should you have a class implementing both.
Evaluation
When I posted about the above technique in my recently created blog, one of the readers expressed some concerns in the following terms:
* Why bother with the macros? They don't enforce anything, and they don't improve readability any more than these old standbys:
#define begin {
#define end }
* Maybe that's useful as a crutch for Java/C# developers, but if a developer needs a crutch like this, they have other problems.
If you look closely at the DeclareInterface and DeclareBasedInterface macros, you'll note that there is at least something that is being enforced there: Every class implementing an interface will have a virtual destructor. You may or may not think this is important, but there are cases when the lack of a virtual destructor will cause problems. Consider the following code, for instance:
DeclareInterface(IBar)
virtual LPCTSTR GetName() const = 0;
virtual void SetName(LPCTSTR name) = 0;
EndInterface
class Foo : implements IBar
{
// Internal data
private:
char* m_pName;
// Construction %26amp; Destruction
public:
Foo()
{
m_pName = NULL;
}
~Foo()
{
ReleaseName();
}
// Helpers
protected:
void ReleaseName()
{
if (m_pName != NULL)
free(m_pName);
}
// IBar implementation
public:
virtual const char* GetName() const
{
return m_pName
}
virtual void SetName(const char* name)
{
ReleaseName();
m_pName = _strdup(name);
}
};
class BarFactory
{
public:
enum BarType {Faa, Fee, Fii, Foo, Fuu};
static IBar CreateNewBar(BarType barType)
{
switch (barType)
{
default:
case Faa:
return new Faa;
case Fee:
return new Fee;
case Fii:
return new Fii;
case Foo:
return new Foo;
case Fuu:
return new Fuu;
}
}
};
As you can see, there's a factory to which you can ask to create an IBar implementation, depending on a BarType parameter. After using it, you are expected to delete the object; so far, so good. Now, consider how this is used in the main function of some application:
int main()
{
IBar* pBar = BarFactory::CreateBar(Foo);
pBar-%26gt;SetName("MyFooBar");
// Use pBar as much as you want,
// ...
// and then just delete it when it's no longer needed
delete pBar; // Oops!
}
What happens at the delete pBar line depends on whether the actual class of that object has a virtual destructor or not. If Foo doesn't have a virtual destructor, the compiler will only generate a call to IBar's implicit empty destructor; the destructor for Foo won't be called, and thus you'll have a memory leak. The virtual destructors in the interface declaration macros are there to avoid this situation; they ensure every class implementing an interface will also have a virtual destructor.
Now, if you are going to use DeclareInterface, it kind of makes sense to also use EndInterface to match with it, rather than a closing brace with no apparent opening one to match. The need for the Interface and implements macros, which resolve to class and public, respectively, could be objected as superfluous, but I find them to better express the actual intent of the code. If I write Foo : public IBar, you can only read some inheritance there and nothing else. If on the other hand, I write Foo implements IBar, you can see it for its actual value and intent: the implementation of the interface concept, and not just any kind of class inheritance. I do find value in that.
Reply:An interface shows high level of abstraction which means it can only contain the declaration of methods without actual implementation or use
The interface methods need to be implemented outside th interface
Reply:interface is what you can see, like the interface of windows has lots of icons you can click on and a desktop...
implementation is making your program. to implement something is to make it. so like if it says "how will you implement your program" it means "how will you make it so it works"
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment