why use interfaces?

Question

serkan sendur 821 Banned

18 Years Ago

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.

.net:c#

6 Contributors
6 Replies
1K Views
2 Years Discussion Span
Latest Post 16 Years Ago Latest Post by Sam.ars

Dani AI

Generated 10 Months Ago

A concise, practical add-on to the points from and : interfaces are best thought of as small, stable contracts you depend on — not as a default for every class. Use them when they add clear value; avoid them when they only add indirection.

When to create an interface

You need to swap implementations (production vs test, different platforms, plugins).
Multiple unrelated types share a role (a logging or persistence role, for example).
You want a stable ABI/contract between assemblies or team boundaries.
You need to decouple callers from concrete behavior (enables dependency injection and mocking).

Small example (dependency injection + testability):

public interface ILogger {
    void Log(string message);
}

public class Processor {
    private readonly ILogger _logger;
    public Processor(ILogger logger) { _logger = logger; }
    public void Run() { _logger.Log("started"); }
}

This keeps Processor ignorant of concrete loggers and makes unit tests trivial.

When not to use interfaces

Do not create an interface for every class by default. If there will only ever be one implementation and no need for testing hooks, an interface may be unnecessary.
Prefer an abstract base class when you need shared code and a common implementation.
Be aware of versioning: adding members to an interface breaks implementers (C# 8+ added default interface methods to mitigate this, but use them sparingly).

Rules of thumb: keep interfaces small and role-focused (Interface Segregation), program to the interface, name with the I prefix, and use explicit interface implementation if you want methods hidden from the concrete type's public surface.

All 6 Replies

Narue 5,707 Bad Cop

18 Years Ago

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 401 Postaholic

18 Years Ago

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

Reply to this topic

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Jugortha -1 Junior Poster · Answer 1 · 2008-03-20T04:14:36+00:00

I think that in addition to what has said in 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 821 Banned Featured Poster · Answer 2 · 2009-04-01T03:38:53+00:00

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 167 Junior Poster · Answer 3 · 2009-04-01T03:45:40+00:00

thoughtcoder 167 Junior Poster

17 Years Ago

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

serkan sendur commented: wtf? +0

nav33n commented: Are you out of your mind ? -2

ddanbe commented: Are you I a bad state of mind at the moment? Don't worry it can happen to all of us. -1

John A commented: I'm John A and I approve this post. +18

hirushan commented: stupid comment +0

Sam.ars 0 Newbie Poster · Answer 4 · 2010-08-20T02:15:19+00:00

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.

why use interfaces?

Dani AI

Recommended Answers Collapse Answers

All 6 Replies

Recommended Answers