I learned most of what I know about C# from books (Head First, Pro C#, etc..) And everytime I get into the books or online resources to the part about interfaces I read through it, but nothing ever sticks in my head. I just cannot find a time in a program
where I would actually NEED interfaces. Its most likely due to the fact that I still (after almost 6 months of learning) cannot get my head around WHY they do what they do, and a practical time when to use them.
This is really hitting me hard since I am starting on MVC3, I am getting into IEnumerator's and IEnumerables and its getting lost on me. Can someone give me any pointers, poiint me in the right direction, or just any advice for how to better grasp this concept?
Simply...explain it like im 5. Thanks.
interfaces in java and c# (or vb) are basically alternative to multiple inheritance
If you dont have an OO based structure in your application, then u'll hardly want to use them.
The most important functionality using interfaces, to me
is the forcing of method implementation, that ensures integrity of the application.
So an interface has some methods, whose implementation must be provided by all the classes that use (implement) these interfaces
I am talking about standards here, for instance, ley say I develop an OO database management system (Just like SQL Server or
MySQL) but having OO features, then I want to follow a famous standard known as ODMG (Object Data Management Group)
SO ODMG provides some interfaces that must be used for any OO DBMS vendor to claim his product as ODMG complaint
Suppose I am that vendor, so if I really want to list my DBMS product under ODMG standard, I must implement all the
methods that are there in ODMG library, otherwise my DBMS product will not qualify to be a valid ODMG complaint product
Perhaps I talked about a large-contexed scenraio, but this happens in S/W houses as well, one senior team can develop interfaces
that must be implemented, So to force the standardization across all products from this S/W house any programmer if uses
some smart in-built class library having interfaces, will be forced to provide a definition (body) of all the methods defined in interfaces
Hence all the products will be better in quality and level of satsifaction, that is established by the S/W house across different product domains
So, they are basicly methods and properties inside an interface, that can be inherited to another... why not just inherit the abilities like a class? I guess thats my problem is I cannot think of a reason to go with interfaces when you can just use classes.
it's complicated ... it's easy to say "an interface allows multiple inheritance" after a fashion ... it's just as easy to state that an interface is a
contract*.
You may wish to refer to:
"Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries", Second Edition,Krzysztof Cwalina; Brad Abrams;Addison-Wesley
Professional,October 22, 2008;
Print ISBN-10: 0-321-54561-3, Print ISBN-13: 978-0-321-54561-9, Web ISBN-10: 0-321-54567-2, Web ISBN-13: 978-0-321-54567-1, Pages in Print Edition: 480
4.3. Choosing Between
Class and Interface
In general,
classes are the preferred construct for exposing
abstractions.
The main drawback of interfaces is that they
are much less flexible than
classes when it comes to allowing for evolution of APIs. After you ship an
interface, the set of its members is fixed forever. Any additions to the
interface would break existing types that implement the
interface.
A class offers much more flexibility. You can add members to
classes that have already shipped. As long as the method is not
abstract (i.e., as long as you provide a default implementation of the method), any existing derived
classes continue to function unchanged.
note: while the book is mainly applicable to designing API's, much of its information is also applicable generically.
g.
* 1.9 Interfaces
An interface defines a contract that can be implemented by classes and structs.
An interface can contain methods,
properties, events, and indexers.
An interface does not provide
implementations of the members it defines—it merely specifies the members that must be supplied by classes or structs that implement the interface.
4.2.5 Interface types
An interface defines a
contract.
A class or struct that implements an interface must
adhere to its contract.
ALLmethods,
properties, events, and indexers contained in an
interface MUST be implemented; for the
implementation of an interface to be legal, the interface MUST adhere 100% to all aspects of the
contract.
B-) Please help me by completing my school survey about computer programmers on my website. Thank you!!! Gerry Lowry +1 705-429-7550 wasaga beach, ontario, canada
Forget all the theory, the books, the differences between classes and so on.
Seriously.
Now go find your CD or DVD player.
Put your favourite CD or DVD in the drive.
Press the Play button.
NOW you understand interfaces.
You see, you just consumed one of the most recognisable interfaces, that of a media player, without a second thought. You can see that the interface is just a logically related group of methods (Play, Pause, Rewind, Fast Forward, Stop, etc.). You realise
that there can be no base implementation (a base class), because that wouldn't make sense across the range of online media players, remote controls, actual devices, etc., all of which need completely different functionality (some fire lasers at spinning discs,
others just decode bits from streams)
What these implementations all share is the idea of Play, Pause, Rewind and so on.
And really that is all an interface is: a logically related set of ideas.
Sure, there are some plus bits.
An interface is also a contract. When you press Play, you clearly understand that it will not overwrite or delete the content.
And you also know that you cannot know what lies behind the interface. You don't care about the spindle speed of a drive, the frequency of the laser, or whether your iPod is powered by Martians! And it is this property of interfaces that makes it possible
to mock them for testing, or to decorate them (the GoF Decorator pattern) or to support proxying for COM/DCOM/Remoting/Web Services.
So, to conclude:
An interface is a contract.
An interface is a logically related group of methods (which might also include events and properties, in .NET speak)
An interface hides implementation detail from a client
Classes, on the other hand, define implementations. And then you fall foul of implementation details, such as .NET only allowing you to define a single base class and other nasties.
Now onto the theory side, if you can still be bothered! :-)
Consider the following.
You have to implement a military simulation. You have units such as Infantry, Artillery and Armor (Tanks). Then you have to factor in Mobile Infantry (move like Armor, but fight like Infantry), Airborne Infantry (move some of the time like Infantry, some
of the time like Aircraft, and always fight like Infanty), Engineers (might be mobile, might not, but will fight like Infantry at a push). Then there are Marines (Move on Ships, or Planes, fight like Infantry, unless they are Marine Armored Units - oh my!)
There is no way that you can do this properly following good OO practices, such as DRY and SOLID, just using classes and inheritance: but with interfaces, it becomes a breeze (Google the GoF State and Strategy patterns; you'll see what I mean).
And finally on to pertinent theory (for this forum, at least).
Why IHttpHandler and IHttpModule?
Because we know, in the case of IHttpHandler, that there is a thing we need to do (ProcessRequest)*, but we have absolutely no idea how to do it. And we have no idea what the base class of something that handles requests might be. Hence it is an interface.
Same argument for IHttpModule. There's a neat contract that we can define for extensibility in the ASP.NET pipeline, but again we have no idea what the implementation might be.
* we can ignore the concept of reusability for this discussion
Yeah, if you dont want to use interfaces just dont do that !
Go with classes, that will be fair enough OO based model in your project
Later in future, you may want something different, and perhaps then u need to use interfaces
I have developed different projects myself, and never created a single interface, still enjoyed very good OO
structure with classes, abstract classes, structures, enums
You must be the luckiest developer alive. I simply can't develop code without relying on IDisposable, IEnumerable, IList, IHttpHandler, IHttpModule, IClientChannel, IUnknown, IClassFactory and all their friends.
Obviously, the design principles that underpin those interfaces don't apply to your projects. Wow. I wish I had your job!
ilovemyherbz
Member
3 Points
2 Posts
Need a better explanation of interfaces
Mar 13, 2012 04:55 PM|LINK
I learned most of what I know about C# from books (Head First, Pro C#, etc..) And everytime I get into the books or online resources to the part about interfaces I read through it, but nothing ever sticks in my head. I just cannot find a time in a program where I would actually NEED interfaces. Its most likely due to the fact that I still (after almost 6 months of learning) cannot get my head around WHY they do what they do, and a practical time when to use them.
This is really hitting me hard since I am starting on MVC3, I am getting into IEnumerator's and IEnumerables and its getting lost on me. Can someone give me any pointers, poiint me in the right direction, or just any advice for how to better grasp this concept? Simply...explain it like im 5. Thanks.
usman400
Contributor
3493 Points
721 Posts
Re: Need a better explanation of interfaces
Mar 13, 2012 05:40 PM|LINK
interfaces in java and c# (or vb) are basically alternative to multiple inheritance
If you dont have an OO based structure in your application, then u'll hardly want to use them.
The most important functionality using interfaces, to me
is the forcing of method implementation, that ensures integrity of the application.
So an interface has some methods, whose implementation must be provided by all the classes that use (implement) these interfaces
I am talking about standards here, for instance, ley say I develop an OO database management system (Just like SQL Server or
MySQL) but having OO features, then I want to follow a famous standard known as ODMG (Object Data Management Group)
SO ODMG provides some interfaces that must be used for any OO DBMS vendor to claim his product as ODMG complaint
Suppose I am that vendor, so if I really want to list my DBMS product under ODMG standard, I must implement all the
methods that are there in ODMG library, otherwise my DBMS product will not qualify to be a valid ODMG complaint product
Perhaps I talked about a large-contexed scenraio, but this happens in S/W houses as well, one senior team can develop interfaces
that must be implemented, So to force the standardization across all products from this S/W house any programmer if uses
some smart in-built class library having interfaces, will be forced to provide a definition (body) of all the methods defined in interfaces
Hence all the products will be better in quality and level of satsifaction, that is established by the S/W house across different product domains
ilovemyherbz
Member
3 Points
2 Posts
Re: Need a better explanation of interfaces
Mar 13, 2012 07:29 PM|LINK
So, they are basicly methods and properties inside an interface, that can be inherited to another... why not just inherit the abilities like a class? I guess thats my problem is I cannot think of a reason to go with interfaces when you can just use classes.
gerrylowry
All-Star
20577 Points
5721 Posts
Re: Need a better explanation of interfaces
Mar 13, 2012 08:30 PM|LINK
@ ilovemyherbz
it's complicated ... it's easy to say "an interface allows multiple inheritance" after a fashion ... it's just as easy to state that an interface is a contract*.
You may wish to refer to:
"Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries", Second Edition, Krzysztof Cwalina; Brad Abrams; Addison-Wesley Professional, October 22, 2008; Print ISBN-10: 0-321-54561-3, Print ISBN-13: 978-0-321-54561-9, Web ISBN-10: 0-321-54567-2, Web ISBN-13: 978-0-321-54567-1, Pages in Print Edition: 480
4.3. Choosing Between Class and Interface
In general, classes are the preferred construct for exposing abstractions.
The main drawback of interfaces is that they are much less flexible than classes when it comes to allowing for evolution of APIs. After you ship an interface, the set of its members is fixed forever. Any additions to the interface would break existing types that implement the interface.
A class offers much more flexibility. You can add members to classes that have already shipped. As long as the method is not abstract (i.e., as long as you provide a default implementation of the method), any existing derived classes continue to function unchanged.
note: while the book is mainly applicable to designing API's, much of its information is also applicable generically.
g.
* 1.9 Interfaces
An interface defines a contract that can be implemented by classes and structs.
An interface can contain methods, properties, events, and indexers.
An interface does not provide implementations of the members it defines—it merely specifies the members that must be supplied by classes or structs that implement the interface.
4.2.5 Interface types
An interface defines a contract.
A class or struct that implements an interface must adhere to its contract.
http://msdn.microsoft.com/en-us/library/ms228593.aspx
"C# Language Specification"
ALL methods, properties, events, and indexers contained in an interface MUST be implemented; for the implementation of an interface to be legal, the interface MUST adhere 100% to all aspects of the contract.
DMW
All-Star
15943 Points
2353 Posts
Re: Need a better explanation of interfaces
Mar 13, 2012 10:25 PM|LINK
Forget all the theory, the books, the differences between classes and so on.
Seriously.
Now go find your CD or DVD player.
Put your favourite CD or DVD in the drive.
Press the Play button.
NOW you understand interfaces.
You see, you just consumed one of the most recognisable interfaces, that of a media player, without a second thought. You can see that the interface is just a logically related group of methods (Play, Pause, Rewind, Fast Forward, Stop, etc.). You realise that there can be no base implementation (a base class), because that wouldn't make sense across the range of online media players, remote controls, actual devices, etc., all of which need completely different functionality (some fire lasers at spinning discs, others just decode bits from streams)
What these implementations all share is the idea of Play, Pause, Rewind and so on.
And really that is all an interface is: a logically related set of ideas.
Sure, there are some plus bits.
An interface is also a contract. When you press Play, you clearly understand that it will not overwrite or delete the content.
And you also know that you cannot know what lies behind the interface. You don't care about the spindle speed of a drive, the frequency of the laser, or whether your iPod is powered by Martians! And it is this property of interfaces that makes it possible to mock them for testing, or to decorate them (the GoF Decorator pattern) or to support proxying for COM/DCOM/Remoting/Web Services.
So, to conclude:
An interface is a contract.
An interface is a logically related group of methods (which might also include events and properties, in .NET speak)
An interface hides implementation detail from a client
Classes, on the other hand, define implementations. And then you fall foul of implementation details, such as .NET only allowing you to define a single base class and other nasties.
Now onto the theory side, if you can still be bothered! :-)
Consider the following.
You have to implement a military simulation. You have units such as Infantry, Artillery and Armor (Tanks). Then you have to factor in Mobile Infantry (move like Armor, but fight like Infantry), Airborne Infantry (move some of the time like Infantry, some of the time like Aircraft, and always fight like Infanty), Engineers (might be mobile, might not, but will fight like Infantry at a push). Then there are Marines (Move on Ships, or Planes, fight like Infantry, unless they are Marine Armored Units - oh my!)
There is no way that you can do this properly following good OO practices, such as DRY and SOLID, just using classes and inheritance: but with interfaces, it becomes a breeze (Google the GoF State and Strategy patterns; you'll see what I mean).
And finally on to pertinent theory (for this forum, at least).
Why IHttpHandler and IHttpModule?
Because we know, in the case of IHttpHandler, that there is a thing we need to do (ProcessRequest)*, but we have absolutely no idea how to do it. And we have no idea what the base class of something that handles requests might be. Hence it is an interface.
Same argument for IHttpModule. There's a neat contract that we can define for extensibility in the ASP.NET pipeline, but again we have no idea what the implementation might be.
* we can ignore the concept of reusability for this discussion
Dave
usman400
Contributor
3493 Points
721 Posts
Re: Need a better explanation of interfaces
Mar 14, 2012 04:28 AM|LINK
Yeah, if you dont want to use interfaces just dont do that !
Go with classes, that will be fair enough OO based model in your project
Later in future, you may want something different, and perhaps then u need to use interfaces
I have developed different projects myself, and never created a single interface, still enjoyed very good OO
structure with classes, abstract classes, structures, enums
DMW
All-Star
15943 Points
2353 Posts
Re: Need a better explanation of interfaces
Mar 14, 2012 07:10 AM|LINK
usman400
You must be the luckiest developer alive. I simply can't develop code without relying on IDisposable, IEnumerable, IList, IHttpHandler, IHttpModule, IClientChannel, IUnknown, IClassFactory and all their friends.
Obviously, the design principles that underpin those interfaces don't apply to your projects. Wow. I wish I had your job!
Dave
usman400
Contributor
3493 Points
721 Posts
Re: Need a better explanation of interfaces
Mar 14, 2012 08:36 AM|LINK
DMW
Nah ur getting the wrong message, I am talking about creating my own itnerfaces
as per the discussion with thread starter
DMW
All-Star
15943 Points
2353 Posts
Re: Need a better explanation of interfaces
Mar 14, 2012 09:40 AM|LINK
So am I.
As I said, the design priciples that underpin those features of .NET underpin my code. And thus I find myself defining interfaces frequently.
Clearly, they don't impact you, which is why I think you're lucky.
Dave
srinanthuram
Contributor
6800 Points
1549 Posts
Re: Need a better explanation of interfaces
Mar 14, 2012 12:16 PM|LINK
hi
u like this
http://solve-dotnet.blogspot.in/2012/02/when-to-use-abstract-class-and.html
thank u