I have been trying to understand what interfaces actually are, and in theory I have digested the definition very well. But when it comes to actually using them, some questions come to my mind.
Most resources define interface this way:
“An interface is a contract between itself and any class that implements it. This contract states that any class that implements the interface will implement the interface's properties, methods and/or events. An interface contains no implementation, only the signatures of the functionality the interface provides. An interface can contain signatures of methods, properties, indexers & events.”
This is very easy to understand, but my question is that if interfaces are (according to this definition) some sort of a blueprint or contract between themselves and classes, what would actually happen if I define this interface,
interface ITest {
int SomeTestVariable { set; get;}
int SomeTestMethod ();
}
make a class that implements this interface as well as all its methods
class Test: ITest {
int SomeTestvariable { set; get;}
int SomeTestMethod () {
return 1;
}
}
and after all the methods and properties have been implemented then I remove it.
class Test {
int SomeTestvariable { set; get;}
int SomeTestMethod () {
return 1;
}
}
Now I must have a class which has used this blueprint or contract. So what would be difference between writing this blueprint on a piece of paper and making an interface?
The advantage is that you can write the interface, and write code that uses the interface before anyone has ever written an implementation of it.
Sure, if you already have the only class that will ever implement the interface coded before you ever use that interface, the interface did you no good, but what if you haven't written the implementation yet (also consider the case that there is more than one type that is implementing the interface)?
A simple example is writing a simple Sort
method. I could write a Sort
implementation for every single possible type of data, or I could write a sort method that assumes that every single item implements a IComparable
interface and can compare itself. Then my Sort
method can write code using that interface long before you've ever written the object you want to compare.
Servy's answer is a solid explanation but - as you've asked for examples - I will take your interface and extend it into a conceivable (if slightly contrived) scenario.
Assume your interface ITest
is in place (I've sneakily switched SomeTestMethod
to return a bool in my example). I could now have two different classes:
// Determines whether an int is greater than zero
public class GreaterThanZeroTest : ITest
{
public int SomeTestVariable { get; set; }
public bool SomeTestMethod()
{
return SomeTestVariable > 0;
}
}
// Determines whether an int is less than zero
public class LessThanZeroTest : ITest
{
public int SomeTestVariable { get; set; }
public bool SomeTestMethod()
{
return SomeTestVariable < 0;
}
}
Now let's say that we have a separate class that runs tests. We could have the following method:
public bool RunTest(ITest test)
{
return test.SomeTestMethod();
}
Maybe this method is called by other members of this class designed to run tests in batches, produce statistics etc.
Now, you can create all kinds of "test" classes. These can be arbitrarily complex but - as long as they implement ITest
- you will always be able to pass them to your test executer.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With