why use interfaces?

[serkan sendur]

I have never found a logical explanation to make my mind about using interfaces in c#. Does any one know a robust benefit of using interfaces? please explain to me in a structural manner.

[Narue]

Wow, I was just explaining interfaces to a coworker the other day. Freaky.

>Does any one know a robust benefit of using interfaces?
Consider the concept of data hiding. Let's say you want to provide a class to some client code, but don't want to give them full access. One way to restrict access without limiting the functionality of your class is to implement an interface and require the client code to get objects through a factory:

using System;

namespace JSW {
	public class Program {
		static void Main() {
			IFoo myfoo = FooFactory.GetFoo();
			Bar mybar = new Bar();

			myfoo.Print();
			mybar.Print();
			mybar.Test();
		}
	}

	// Restricted type for clients
	public interface IFoo {
		void Print();
	}

	// Factory for clients
	public class FooFactory {
		public static IFoo GetFoo() {
			return new Bar();
		}
	}

	// Fully functional type for us
	internal class Bar: IFoo {
		public void Print() {
			Console.WriteLine( "Foo!" );
		}

		public void Test() {
			Console.WriteLine( "Test" );
		}
	}
}

This is especially useful when interfacing with COM.

Another benefit of interfaces is team development. If you have a dozen programmers working on different pieces of code that need to connect, it's best to define interfaces for the connections. As long as the programmers write according to the interfaces, everything will link together nicely regardless of personal choices and style.

Yet another benefit is that with interfaces you can use a class without having defined it first. For example, if you have a class that does a lot of intricate work and won't be finished before the rest of the project, the rest of the project can use an interface to it and avoid being stalled by the development of that one class.

Personally, I like the guarantees that interfaces provide. If a class implements IDisposable, I know not only that the objects can be disposed without getting compiler errors, but that they should be disposed. This keeps my code consistent and robust. You can provide similar guarantees in your code simply by adhering to an interface.

[Ramy Mahrous]

A great article which makes you understand when to use abstract classes and when you use interfaces
Interfaces: http://fci-h.blogspot.com/2008/03/oop-design-concepts-interfaces_05.html

Abstract classes: http://fci-h.blogspot.com/2008/03/oop-design-concepts-abstract-classes.html

[Jugortha]

I think that in addition to what has said in http://fci-h.blogspot.com/2008/03/oo...rfaces_05.html about interfaces witch i find very interesting in fact.
I can add other think
Interfaces are comming to the world to avoid the multiples inheritences concept adopted for example by C++ language that causes somes problems and confusions when using this concept and that brings some troubles to the the OOP paradigm it self
I give you a concrete example:
You know this kind of jet that can either fly and navigates throw the sea like the H-4 Hercule jet modelhttp://tuxthepenguin.free.fr/img/Lun.jpg
This kind of object is a jet however it has an additional functionality that can be found in the boat object to avoid the double inheritance from boat and jet objects to define the H-4 we do as so:

class jet
{
....
fly()
{// some code here}
....
}
class boat, INavigate
{
.....
navigate()
{// some code here}
......
}
interface INavigate
{
navigate();
}
class H4 : Jet,INavigate
{
.....
new fly()
{// some code here}
......
navigate()
{// Some implementations here}

}

[serkan sendur]

Wow, I was just explaining interfaces to a coworker the other day. Freaky.

>Does any one know a robust benefit of using interfaces?
Consider the concept of data hiding. Let's say you want to provide a class to some client code, but don't want to give them full access. One way to restrict access without limiting the functionality of your class is to implement an interface and require the client code to get objects through a factory:

using System;

namespace JSW {
	public class Program {
		static void Main() {
			IFoo myfoo = FooFactory.GetFoo();
			Bar mybar = new Bar();

			myfoo.Print();
			mybar.Print();
			mybar.Test();
		}
	}

	// Restricted type for clients
	public interface IFoo {
		void Print();
	}

	// Factory for clients
	public class FooFactory {
		public static IFoo GetFoo() {
			return new Bar();
		}
	}

	// Fully functional type for us
	internal class Bar: IFoo {
		public void Print() {
			Console.WriteLine( "Foo!" );
		}

		public void Test() {
			Console.WriteLine( "Test" );
		}
	}
}

This is especially useful when interfacing with COM.

Another benefit of interfaces is team development. If you have a dozen programmers working on different pieces of code that need to connect, it's best to define interfaces for the connections. As long as the programmers write according to the interfaces, everything will link together nicely regardless of personal choices and style.

Yet another benefit is that with interfaces you can use a class without having defined it first. For example, if you have a class that does a lot of intricate work and won't be finished before the rest of the project, the rest of the project can use an interface to it and avoid being stalled by the development of that one class.

Personally, I like the guarantees that interfaces provide. If a class implements IDisposable, I know not only that the objects can be disposed without getting compiler errors, but that they should be disposed. This keeps my code consistent and robust. You can provide similar guarantees in your code simply by adhering to an interface.

thanks, it took me one year to fully understand that concept, but now it is time to mark this as solved. i dont understand many things until i use them intentionally. in my new project i make use of interfaces a lot, so i really understood the conception. i remember reading a application design book which badly mentions about interfaces(how rigid they are and deserve great care at the initial stage of application design and such), but i dont see any harm at all.

[thoughtcoder]

Actually, interfaces were invented as a joke. April fools!

[Sam.ars]

I have never found a logical explanation to make my mind about using interfaces in c#. Does any one know a robust benefit of using interfaces? please explain to me in a structural manner.

Interface in object answer to one simple requirement facilitate mostly used functionality
you whant to give only what is use full to the user so using your object become simpler
if your class offer 40 functionality and one of your user commonly uses 3 of theme you dont whant to show him all of them it create noise. take an oo course.