Click here to Skip to main content
15,908,172 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi, I am trying to learn programming in C#. I had previous, limited knowledge of Visual Basic. I am really struggling to get my head around OOP. I have several books but all seem to get to the important OOP stuff and race over it, or at least for me.

I have just got through the inheritance part which all made sense. I understand the reasoning behind it, I'm now up to Interfaces but no matter how hard I try, I can not understand a) why you need them or b) how to implement them.

I really desperately want to learn but for the life of me I can not get my head round this. I would really appreciate it if somebody would take the time to explain it in nice easy terms for me.

----Edit----
Ok, so I think I understand what they are used for now. They are used like a template to ensure that any class that implements it contains all of the methods and properties declared in the interface. They are not used when you need to inherit from more than one parent (as I previously thought).

So to summarize what I was reading on one of those links, if I had a program that calculated the area of a shape:

I have one class for calculating area for a circle and one for triangle. The methods - say GetArea() are different but have the same function and return the same value. I could then create an interface IShapeArea which declares the methods. This then ensures that the Circle and triangle Classes have the exact same names and return types. Also, if I wanted to add a Square class, I would again have to follow the same naming convention.

It seems to be a way of forcing consistency. Would that be an accurate assessment?
Posted
Updated 12-Oct-11 1:48am
v2
Comments
BobJanova 12-Oct-11 10:18am    
Regarding your edit: It is a way of declaring that a class supports a particular interface (in the non-keyword sense, i.e. a set of ways you can call it), so that your code can call it in those declared ways. So yes, it enforces consistency but in a way which makes it possible to call those methods.

It is also used to declare multiple facets of an object, which is related to but also different to multiple inheritance ('parentage' in your words). You can implement multiple interfaces, which is a way of saying 'I am an X, and also a Y, and a Z' (similar to inheritance), but those are different views on this object – all the implementation is in one class. (For example a List is an IList but also an IEnumerable, ISerializable etc.)

Ok, if you have inheritance sorted, then Interfaces aren't too difficult.

I assume you know about foreach in C#? And that you can give it any form of Collection (List<T>, array, and so forth)?

This works because all Collections implement an Interface called IEnumerable - indeed, you can declare your own class, implement the IEnumerable interface and it will work happily in a foreach.
This happens because when you implement an interface, you provide a set of routines that define it: The equivalent of FindFirst and FindNext for IEnumerable. So when foreach needs to find the first element in the list, it calls the IEnumerable FindFirst method (which you implemented in your class) and your version gets called. The same for FindNext each time it goes round the loop again.

What interfaces do is allow a class to implement a number of behaviors and act as if the class was derived from the interface (sort of). Since C# will only let you derive from a single class, (but an unlimited number of interfaces) it allows behaviour that seems like multiple inheritance.

The difference between an Interface and a class is also pretty simple: when you declare an interface, you are not allowed to declare any code - just the bare-bones of the properties and methods. The actual code must be filled in by the class that implements the interface.

To declare an interface is simple: I won't demo it, because MSDN does a much better job. http://msdn.microsoft.com/en-us/library/87d83y5b(v=vs.80).aspx[^]

They are a bit difficult to get your head round, but they are important, and you have probably already used them a lot more than you think! :laugh:
 
Share this answer
 
You use an interface when you want to say 'I want something with this behaviour, but I don't care how it's implemented'. The example of IEnumerable and foreach loops that Griff mentioned is an excellent one – it doesn't matter what the internal representation of something is or how it does it, if it implements IEnumerable it can be used by a foreach loop.

You'd want to create your own interfaces if you find places where you know you want to be passed an object with some operations, but you don't want to specify how those operations are done. ('Runtime polymorphism' just means that the actual code that gets run at runtime is different depending on object type.) For example, in my work we have some graphing code, and as part of that we create data series. Instead of the series needing to know how to look up data, I created an IDataProvider which provides hooks for providing data, and the series asks that. Elsewhere, deep in complicated bits of the application, some classes implement IDataProvider and find the appropriate data (in different ways in different places).

That leads onto the next point, interfaces (and abstract base classes, in some cases, if there is a generic minimal functionality that makes sense without dependencies) help with modularisation and dependency reduction. Because all you need to specify is what you want something to be able to do, an interface has almost no dependencies (only on the types used in the declarations; generally you want to restrict those to Framework types and types in the current project, if possible, but sometimes types from 'lower' layers are needed too).
 
Share this answer
 
I found this[^] a fairly nice explanation.
Concept of Interface[^] could help you a little as well.

From a programming point of view, here[^] are some differences between abstract classes and interfaces.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900