Interfaces???

  • Thread starter Thread starter Adie
  • Start date Start date
A

Adie

Hi, can anyone have a go at explaining what an "Interface" is used for
and what exactly it is?

[attributes] [modifiers] interface identifier [:base-list]
{interface-body}[;]

MSDN is a little abstract for my level of knowledge.

Thanks!
 
Adie said:
Hi, can anyone have a go at explaining what an "Interface" is used for
and what exactly it is?

[attributes] [modifiers] interface identifier [:base-list]
{interface-body}[;]

MSDN is a little abstract for my level of knowledge.

You were basically looking in the wrong section. Look under
"interfaces" in the index and there's a "tutorial" section which should
help you.
 
Adie,
Hi, can anyone have a go at explaining what an "Interface" is used for
and what exactly it is?

In OO-terminology we have stereotypes. A stereotype is an aspect of an
entity that is not necessarily related to its class. Let me give a
real-world example (well, sort of...). Say you have these classes in your
problem domain:

Dog, Plant, GirlFriend, Grandma, Car, Employer, Colleague.

Each may have its own inheritence root or some may share common roots like
Relative, Pet or PersonAtWork. Your class hierarchy may be quite complex and
will be based on some model that works for you when you want to make useful
software.

Now you may recognize some behavior you want to implement like receiving
money or paying. Being an OO-dude you would think up classes like Provider
and MoneySucker. Cool... But then what? If GirlFriend and Car are
MoneySuckers and Employer is a Provider, doesn't that conflic with the class
model you already have?

Provider and MoneySucker aren't really classes, they merely define behavior.
And you want to slap them on any class you find appropriate, independent of
their place in your class hierarchy. Provider and MoneySucker are
interfaces:

interface Provider
{
void PayMe();
void FeedMe();
}

interface MoneySucker()
{
void ShakeMeDown();
}

You can now implement these interfaces in any class you find appropriate.
The "contract" is defined once only. Since interfaces are types you may
iterate through all of your providers to collect money. When you need money
you don't really care about your objects being reletives, friends or
colleagues or whatever, while in the process of obtaining money you want to
treat them as providers.

Like you have your class tree, you may also have your interface tree.
Interfaces can inherit from base interfaces like classes. You will never
implement anything in an interface itself though, they merely define groups
of method signatures. If a class claims to implement an interface the
compiler will make sure that every method is indeed implemented and can be
called.

Cool huh?

Martin.
 
Back
Top