Is an analog, say, a USB interface? Where your computer (the program) has a
USB port (the interface) that can hook up to a multitude of devices
(multiple classes) like video cams, hds, digicams, mice, etc?
Lastly, if I'm right or if I'm wrong, how does one implement an interface in
C#? Are they used frequently? Is it a C# only feature? What reasoning
goes in behind creating an interface? What syntax is required?
Thanks,
Eric
No - physical devices have nothing to do with interfaces (in the language
terminology), and the analogy isnt really close.
Think of it more like a contract that says : 'By implementing IMyInterface
my class guarantees that it will provide a DoMyThing method'
interface IMyInterface
{
void DoMyThing();
}
public class MyClass : IMyInterface
{
public void DoMyThing()
{ ...
}
}
Other languages have then, yes they are used frequently, and the reasoning
is that by specifying an interface you are guaranteeing a set of
functionality from a class.
"eeeric" <n...@real.addy> wrote in message
news:MfVV9.36961$H76.2...@news1.east.cox.net...
Interfaces are a general programming concept implemented practically
everywhere (not everywhere, but almost). Interfaces are the basis for COM,
and help in general to allow for extensibility in a framework.
Your analogy is correct in that USB is an interface. A USB port
basically says "I accept things that are of this type, and will follow this
established protocol". An interface says the same thing, in that it says
that there is an underlying implementation of the methods and properties
defined on the interface.
What makes it extensible is that you might have an interface that
defines a contract for expected behavior, and currently use one particular
implementation for that interface. When your needs change, you can change
the implementation of the interface to produce different results.
For example, say you had an interface, ILog, which had one method,
LogMessage. This method is called by your application when it needs to log
some information somewhere. You have a class named TextFileLog which
implements ILog, and the implementation of LogMessage stores the string
passed into a file. Say the file is becoming too big to manage, and you
figure a database would be a better solution. Instead of gutting the code
that would make the call, all you have to do is create a different class
that implements ILog and store that in your app instead. The implementation
of LogMessage would take the string and then store it in a database.
As for where it is used, interfaces are used in a number of places in
the framework. Also, COM is dependent on the concept of interfaces, you
can't do anything in COM without them.
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- nicholas...@exisconsulting.com
"eeeric" <n...@real.addy> wrote in message
news:MfVV9.36961$H76.2...@news1.east.cox.net...
"eeeric" <n...@real.addy> wrote in message
news:MfVV9.36961$H76.2...@news1.east.cox.net...
> Hi, I'm not quite sure if I know what an interface is.
An interface defines behaviour, a type implements an interface and
implements that behaviour. If you view an interface as behaviour you cannot
go wrong.
> Lastly, if I'm right or if I'm wrong, how does one implement an interface
in
> C#?
interface ITest
{
void Method();
}
class TestClass : ITest // implements this behaviour
{
public void Method(){} // MUST provide the method
}
>Are they used frequently?
All over the place, look in the .NET reference for entries that start in I.
> Is it a C# only feature?
No, they are a .NET feature, even VB.NET can define and use them! <g>
> What reasoning goes in behind creating an interface? What syntax is
required?
There are several reasons for interfaces, which you may or may not need.
First, interface defines a behaviour in a way that is not coupled to a type.
In the code above ITest could be defined in one assembly and TestClass in
another. A remote object could use the ITest behaviour and hence the remote
object assembly needs the ITest assembly. The client could implement
TestClass and so it too needs access to the ITest assembly, however, the
client can pass an instance of TestClass to the remote object - the remote
object does not need access to the TestClass assembly because it is only
interested in the ITest behaviour.
This feature is how COM (DCOM) worked, because object users know nothing
about the actual details of the implementation, they only know about the
_behaviour_.
This feature is used extensively in the .NET library, even for classes not
intended for remoting. Its a way of saying 'I support this behaviour' if you
implement an interface or 'I need this behaviour' if a method takes an
interface as a parameter.
One other thing about interfaces is that if you choose you can indicate that
a method is _only_ called through an interface. In the example above I could
write:
TestClass t = new TestClass();
t->Method(); // call through object reference
ITest i = (ITest)t;
i->Method(); // call through an interface reference
Its not immediately obvious that Method is part of the ITest behaviour,
however, if I write:
class TestClass : ITest // implements this behaviour
{
public void ITest.Method(){} // MUST provide the method
}
The _only_ way that I can call TestClass.Method is through an interface
reference.
Richard
http://www.geocities.com/jeff_louie/OOP/oop9.htm
Regards,
Jeff
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!