3 Replies - 2292 Views - Last Post: 11 May 2011 - 12:55 PM Rate Topic: -----

#1 Zdrenka   User is offline

  • D.I.C Head
  • member icon

Reputation: 7
  • View blog
  • Posts: 116
  • Joined: 24-November 09

Understanding Interfaces

Posted 10 May 2011 - 05:20 PM

Hey guys,
I guess the title says it all really, I understand that interfaces only contain signatures of methods but im not to sure what the actual use is for interfaces, all I can guess is you use them to set which methods need to be in a class...although im not sure, iv read what's on MSDN but im having some trouble understanding it.
Is This A Good Question/Topic? 0
  • +

Replies To: Understanding Interfaces

#2 lordofduct   User is offline

  • I'm a cheeseburger
  • member icon


Reputation: 2668
  • View blog
  • Posts: 4,786
  • Joined: 24-September 10

Re: Understanding Interfaces

Posted 10 May 2011 - 05:54 PM

When you write a class you have two parts... the interface and the implementation. All objects usually have this even in the real world. The implementation is hidden away from the user, instead you access the object through its interface.

For example a VCR/DVD/Blu-Ray player (depending your era) has an interface that consists of an input hole to insert the video, some buttons to tell it to play/pause/stop/eject/etc, and lastly some outputs that feed out some image that is sent to your TV.

This is its interface. The way it interacts with the rest of the world. Because if we made all the insides accessible it'd be a rather complicated device and worst there'd be no consistency between them. Instead all of that (the implementation) is hidden inside the box. And each device implements the job they do differently. Not just the big difference like VCR to DVD, but even the little differences like between samsung's version vs jvc's version which may use different parts and even slightly different techniques to create superior qualities or cheaper prices.

Now when the DVD player and subsequently the Blu-Ray player came out. Notice how it integrated very easily into your existing entertainment system? The input, operation buttons, and output followed a basic standard that already existed. This allowed the operation of it to be rather intuitive. Shit the DVD player even kept the rewind button despite the lack of a necessity for it.

This relationship we call the interface, well in programming we actualized it. We created a type of syntax to represent this 'contract' we've created. We defined a 'video play-back device'. Of which similar class types that don't necessarily come from the same family of technologies can have an explicit relationship created between them.

The Interface construct was invented to essentially create a literal way to describe something we already had been describing in programming for a long time (think abstract classes).

Languages like Java or those under the .Net umbrella use this more explicit definition to facilitate a more controlled inheritance. You can't inherit from multiple classes because it may create dualities between the implementations of different types, but you can implement multiple interfaces. Because there is no actual code (implementation) behind the various interfaces, there is no conflict if you implement two similar interfaces. Instead you end up with one function for that similarity between interfaces, and you write one implementation for it (you can still gain inheritance through what is called 'composition')


Note, the name 'interface' was chosen because they describe the 'interface' of a type explicitly. This might cause some herp a derp in thinking about the 'name'. I like to compare it to saying "a screwdriver screws a screw".

This post has been edited by lordofduct: 10 May 2011 - 06:04 PM

Was This Post Helpful? 4
  • +
  • -

#3 Curtis Rutland   User is offline

  • (╯□)╯︵ (~ .o.)~
  • member icon


Reputation: 5106
  • View blog
  • Posts: 9,283
  • Joined: 08-June 10

Re: Understanding Interfaces

Posted 10 May 2011 - 07:01 PM

*
POPULAR

To add to what lordofduct said in more concrete programming terms:

The most important use of interfaces is a way of "grouping" classes that can perform certain actions or conform to certain behaviors.

For instance, IDisposable. Any class that implements this interface will always have a Dispose method. Because of this, in situations where we only care about disposing objects, we can disregard all the other things about it and focus on that. With that in mind, the C# developers created a construct called using. Any IDisposable object created with a using statement is disposed when you leave the statement's scope. Without that interface, we'd have no way of knowing if an object even could be disposed.

A similar example is IEnumerable. Any class that implements this is a collection that can be iterated across. Because of this, we can use foreach loops. Anything that implements IEnumerable can be used in a foreach loop. Also, LINQ makes extensive use of IEnumerables as well, with it's extension methods. Again, it doesn't matter what type of collection it is. It doesn't matter if it's a Dictionary, an Array, a List, an ObservableCollection, or some completely custom class that you made up. We know that it'll have a method called GetEnumerator, and using that enumerator, you can iterate across the items the collection represents.

All interfaces are similar, though most of them aren't directly related to language constructs like I've mentioned. INotifyPropertyChanged, for instance, will always have an event called PropertyChanged, which you should implement to fire when any property that needs to be tracked changes. Think of the infinite combinations of classes that could implement this. There's no way, without interfaces, you could deal with them in a generic sense. Having the interface, you can say "I don't care what kind of object this is. As long as it's implementing this interface, I know that I'll be told when it's properties change, and I can expect that." It's frequently used in WPF/Silverlight in the MVVM pattern, when you bind an object to a XAML template. The event fires, and the UI catches that event and updates itself accordingly.

Now, some of what can be done with interfaces can also be done with inheritance. The problem with inheritance is that you can only inherit from one base class. So, if I want my class to be an enumerable that can also be disposed, what would I do? It's possible that one of those could be a base class for the other, but that wouldn't make sense, since not all disposables are collections, and not all collections are disposable. With that in mind, Interfaces were made. It's possible to implement several behaviors.

Think of it this way: inheritance implies an "is a" relationship. A square "is a" rectangle, but a circle is not. An interface is more of a "can" relationship. A piece of paper "can" be disposed of, but so can a battery and a diaper and a sandwich. None of those things have a common parent, but they all share a common trait.

For what it's worth, if you're mostly delivering stuff to an end-user, you'll mostly use classes that already implement interfaces, rather than create your own. Middleware, though, you'll become intimately familiar with them.

Important note: it's not just methods that an interface can define. It's also properties, delegates, events, and indexers. As I mentioned earlier, INotifyPropertyChanged's only contract is an event. IList demands that you implement an indexer.

This post has been edited by Curtis Rutland: 10 May 2011 - 07:08 PM

Was This Post Helpful? 5
  • +
  • -

#4 Zdrenka   User is offline

  • D.I.C Head
  • member icon

Reputation: 7
  • View blog
  • Posts: 116
  • Joined: 24-November 09

Re: Understanding Interfaces

Posted 11 May 2011 - 12:55 PM

thanks guys,
that was extremely helpful, I feel I now have a much better understanding of interfaces. iv been trying to understand them for a while, I think one of the main problems was that I couldn't think of a time when I would use them, but thanks to your advice I can see why a company would use them.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1