Sign in to follow this  
Silly_con

Interface classes

Recommended Posts

Silly_con    136
What's the goal of interface classes ? I have seen it named with and I (IMaterial, IShader ...) and it has pure virtual methods and no variables, can anyone tell me how can be made interface classes, whats the goal, and the advantages/disadvantages ? thnx

Share this post


Link to post
Share on other sites
PnP Bios    494
Well, Silly, the goal of an interface class it to well... act as an interface. Say you have 5 different ways to plot a pixel on a screen, as dictated by the hardware.
Instead of the programmer having to prepare a method to deal with each one, he can create an interface class, and then the children classes can inherit the methods for the interface class, and handle all of the drawing code internaly.
then you do something like this.

class interface;
class d1:public interface;
class d2:public interface;
class d3:public interface;

interface *draw;
draw = new d1;
draw->render;

ok... not so clean, but it should help you get the idea.

Share this post


Link to post
Share on other sites
snk_kid    1312
You need to becareful using the term interface class in actually describes something else which is related thou, but i know what your refering to you mean interfaces or interface types.

First way to understand an interface is to understand what the term interface itself means:

Quote:

1 : a surface forming a common boundary of two bodies, spaces, or phases <an oil-water interface>
2 a : the place at which independent and often unrelated systems meet and act on or communicate with each other <the man-machine interface> b : the means by which interaction or communication is achieved at an interface


So basically an interface defines a procotol that allows two or more usually un-related parties to communicate on common grounds.

In the context of programming an interface not only defines a protocol but defines a type actually an abstract data type (ADT) and a type only where as a class is not only not only a type but also its implementation/representation roled into one.

what makes an ADT an ADT and why do we make them?

well usually we find types in the problem domain or a range of problem domains that can be representated by infinite or a range of different data structures but its definition makes no suggestion to how its representated. How-ever its definition does define its behaviours or operations that is always the same or invariant regard-less of how we represent it.

Take an example a stack its definiately an ADT, the operations of a stack are always push & pop but we can implement a stack with anything an array, linked-list, a binary tree if your crazy.

Eventually we have to commit to some representation and this will effect the space & time efficency of these operations, but we would like to be able to reuse and extend a stack using any implementation with-out having to force change client's code so we make it an interface type and implement the interface with a thew different implementations by default say an array stack and linked-list stack and allow clients to make there own implemenations if they wish, all clients do is just pass around a pointer to the interface type this gives an invariant interface to variant representation (its not the only way either) nobody cares what representation it refers to they just wont to use a stack.

Another reason for using interface types is in the context of multiple inheritance when interfaces extend interfaces or when a class implements more than one interface its refered to multiple interface inheritance also known as super-type sub-type inheritance, it is generally a much cleaner solution & easier to maintain than to multiple implementation inheritance also known as super-class sub-class inheritance and some languages have banned multiple implementation inheritance compleletly (i don't agree with it) and only allow to multi-inherit from interfaces.

I think the reason to this is people tend to get the wrong idea about type inheritance, type inheritance is a static relationship and the main point of type inheritance is to extend behaviours not state there are better ways to have state/data inhertiance which doesn't invole or need type inhertiance.

how do we define an interface in c++?

make a abstract base class (ABC) with no implementation e.g.


struct IFoo {

virtual void bar() = 0;
virtual ~IFoo() {};

};


Foo defines a protocol that must be implementated.

Disadvantages are you over do it in the wrong place and overlook better more efficent alternatives to write ADTs.

[Edited by - snk_kid on October 17, 2004 1:43:11 PM]

Share this post


Link to post
Share on other sites
Silly_con    136
I undertand your good explanation, I have only a few questions more, interfaces have constructors/destructors and have to be reimplemented in inherit class too ?
The data (variables) is declared in interface or in inherit class ?

Share this post


Link to post
Share on other sites
snk_kid    1312
Quote:
Original post by Silly_con
I have only a few questions more, interfaces have constructors/destructors


the concept of interfaces has no notion of constructors/destructors they are language features (although the thing your modelling may have the notion of de/initialization that works differently for all implementations), i probably confused the matter by writing a virtual destructor i did that because of the way the c++ language works if you don't declare it as virtual then you try call delete on an interface pointer then the instance it refers to wont be destroyed properly.

Although it is true that in c++ all classes/structures always have constructors/destructors either explicitly defined by your-self or implicitly by the compiler as interfaces have no data members there is nothing to construct/destroy so you can imagine they don't exist but rule of thumb if a class/structure has a method declared virtual then its destructor should be declared virtual aswell, implicitly defined destructors doesn't make them virtual by default.

Quote:
Original post by Silly_con
and have to be reimplemented in inherit class too ?


in c++ class & struct constructors can never be virtual there-for cannot forced to be implemented or overriden by sub-types but are either explicitly or implicitly called from sub-type's constructor initializer list but as an interface has nothing to do then you have nothing to worry about, if you don't write one one is automatically generated.

Quote:
Original post by Silly_con
The data (variables) is declared in interface or in inherit class ?


You don't generally say a class inherits from an interface because they don't inherit anything you say a class/es implements/realizes an interface/s

interfaces have no data members & methods have no definition.

If where asking because you wonted "to have your cake and eat too" implement code reuse aswell as elegant solution then can you either

1. make something that is known as a mix-in class, this class implements one or more interfaces and privately/protectedly inherits implementation from some base imp class e.g.


//interface
template < typename T >
struct IStack {

virtual void push(const T&) = 0;

/* ... */

virtual ~IStack() {}

};

template < typename T >
struct llist_imp { //implementation

/* .... */

void add(const T& t) { /* ... */ }

};

template < typename T >
class stack_list : public IStack<T>, private llist_imp<T> {

/* ... */

public:

void push(const T& j) {
add(j); //code-reuse, using llist_imp<T>::add
}

};

int main() {

IStack<int>* s = new stack_list<int>();

s->push(30);

delete s;

return 0;

}


Then you can just re-use the code of llist_imp to implement IStack (warning that is just an example).

or

2. Have an interface then have an abstract class implement some of the interface and some representation to share for commmon sub-types e.g.


//interface
template < typename T >
struct List {

virtual void add(const T&) = 0;

/* ... */

virtual ~List() {}

};

template < typename T >
struct abstract_list : public List<T> {

/* implements some/all of the interface, may have some representation * /

};

template < typename T >
struct array_list : public abstract_list<T> {

/* concreate class, can redefine some behaviour that is more appropriate */

};

template < typename T >
struct linked_list : public abstract_list<T> {

/* concreate class, can redefine some behaviour that is more appropriate */

};

template < typename T >
void foo(List<T>& l, const T& t) { //polymorphic behaviour
l.add(t);
}

int main() {

List<int>* l = new array_list<int>();
List<int>* s = new linked_list<int>();

foo(*l, 30);
foo(*s, 33);

delete l;
delete s;

}


Last thing i forgot about interfaces, interface are also generally (not always) adjective nouns like Comparable, Cloneable, Renderable etc.

I prefer to not over use interfaces, i do a mix of interface & generic programming and generics/templates probably outweigh interfaces in my code but they work nice together.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this