Develop Reference

Noob question: in C# why would a user rely upon an empty method from an interface? [duplicate]

The reason for interfaces truly eludes me. From what I understand, it is kind of a work around for the non-existent multi-inheritance which doesn't exist in C# (or so I was told).
All I see is, you predefine some members and functions, which then have to be re-defined in the class again. Thus making the interface redundant. It just feels like syntactic… well, junk to me (Please no offense meant. Junk as in useless stuff).
In the example given below taken from a different C# interfaces thread on stack overflow, I would just create a base class called Pizza instead of an interface.
easy example (taken from a different stack overflow contribution)
public interface IPizza
{
public void Order();
}
public class PepperoniPizza : IPizza
{
public void Order()
{
//Order Pepperoni pizza
}
}
public class HawaiiPizza : IPizza
{
public void Order()
{
//Order HawaiiPizza
}
}

No one has really explained in plain terms how interfaces are useful, so I'm going to give it a shot (and steal an idea from Shamim's answer a bit).
Lets take the idea of a pizza ordering service. You can have multiple types of pizzas and a common action for each pizza is preparing the order in the system. Each pizza has to be prepared but each pizza is prepared differently. For example, when a stuffed crust pizza is ordered the system probably has to verify certain ingredients are available at the restaurant and set those aside that aren't needed for deep dish pizzas.
When writing this in code, technically you could just do
public class Pizza
{
public void Prepare(PizzaType tp)
{
switch (tp)
{
case PizzaType.StuffedCrust:
// prepare stuffed crust ingredients in system
break;
case PizzaType.DeepDish:
// prepare deep dish ingredients in system
break;
//.... etc.
}
}
}
However, deep dish pizzas (in C# terms) may require different properties to be set in the Prepare() method than stuffed crust, and thus you end up with a lot of optional properties, and the class doesn't scale well (what if you add new pizza types).
The proper way to solve this is to use interface. The interface declares that all Pizzas can be prepared, but each pizza can be prepared differently. So if you have the following interfaces:
public interface IPizza
{
void Prepare();
}
public class StuffedCrustPizza : IPizza
{
public void Prepare()
{
// Set settings in system for stuffed crust preparations
}
}
public class DeepDishPizza : IPizza
{
public void Prepare()
{
// Set settings in system for deep dish preparations
}
}
Now your order handling code does not need to know exactly what types of pizzas were ordered in order to handle the ingredients. It just has:
public PreparePizzas(IList<IPizza> pizzas)
{
foreach (IPizza pizza in pizzas)
pizza.Prepare();
}
Even though each type of pizza is prepared differently, this part of the code doesn't have to care what type of pizza we are dealing with, it just knows that it's being called for pizzas and therefore each call to Prepare will automatically prepare each pizza correctly based on its type, even if the collection has multiple types of pizzas.

The point is that the interface represents a contract. A set of public methods any implementing class has to have. Technically, the interface only governs syntax, i.e. what methods are there, what arguments they get and what they return. Usually they encapsulate semantics as well, although that only by documentation.
You can then have different implementations of an interface and swap them out at will. In your example, since every pizza instance is an IPizza you can use IPizza wherever you handle an instance of an unknown pizza type. Any instance whose type inherits from IPizza is guaranteed to be orderable, as it has an Order() method.
Python is not statically-typed, therefore types are kept and looked up at runtime. So you can try calling an Order() method on any object. The runtime is happy as long as the object has such a method and probably just shrugs and says »Meh.« if it doesn't. Not so in C#. The compiler is responsible for making the correct calls and if it just has some random object the compiler doesn't know yet whether the instance during runtime will have that method. From the compiler's point of view it's invalid since it cannot verify it. (You can do such things with reflection or the dynamic keyword, but that's going a bit far right now, I guess.)
Also note that an interface in the usual sense does not necessarily have to be a C# interface, it could be an abstract class as well or even a normal class (which can come in handy if all subclasses need to share some common code – in most cases, however, interface suffices).

For me, when starting out, the point to these only became clear when you stop looking at them as things to make your code easier/faster to write - this is not their purpose. They have a number of uses:
(This is going to lose the pizza analogy, as it's not very easy to visualise a use of this)
Say you are making a simple game on screen and It will have creatures with which you interact.
A: They can make your code easier to maintain in the future by introducing a loose coupling between your front end and your back end implementation.
You could write this to start with, as there are only going to be trolls:
// This is our back-end implementation of a troll
class Troll
{
void Walk(int distance)
{
//Implementation here
}
}
Front end:
function SpawnCreature()
{
Troll aTroll = new Troll();
aTroll.Walk(1);
}
Two weeks down the line, marketing decide you also need Orcs, as they read about them on twitter, so you would have to do something like:
class Orc
{
void Walk(int distance)
{
//Implementation (orcs are faster than trolls)
}
}
Front end:
void SpawnCreature(creatureType)
{
switch(creatureType)
{
case Orc:
Orc anOrc = new Orc();
anORc.Walk();
case Troll:
Troll aTroll = new Troll();
aTroll.Walk();
}
}
And you can see how this starts to get messy. You could use an interface here so that your front end would be written once and (here's the important bit) tested, and you can then plug in further back end items as required:
interface ICreature
{
void Walk(int distance)
}
public class Troll : ICreature
public class Orc : ICreature
//etc
Front end is then:
void SpawnCreature(creatureType)
{
ICreature creature;
switch(creatureType)
{
case Orc:
creature = new Orc();
case Troll:
creature = new Troll();
}
creature.Walk();
}
The front end now only cares about the interface ICreature - it's not bothered about the internal implementation of a troll or an orc, but only on the fact that they implement ICreature.
An important point to note when looking at this from this point of view is that you could also easily have used an abstract creature class, and from this perspective, this has the same effect.
And you could extract the creation out to a factory:
public class CreatureFactory {
public ICreature GetCreature(creatureType)
{
ICreature creature;
switch(creatureType)
{
case Orc:
creature = new Orc();
case Troll:
creature = new Troll();
}
return creature;
}
}
And our front end would then become:
CreatureFactory _factory;
void SpawnCreature(creatureType)
{
ICreature creature = _factory.GetCreature(creatureType);
creature.Walk();
}
The front end now does not even have to have a reference to the library where Troll and Orc are implemented (providing the factory is in a separate library) - it need know nothing about them whatsoever.
B: Say you have functionality that only some creatures will have in your otherwise homogenous data structure, e.g.
interface ICanTurnToStone
{
void TurnToStone();
}
public class Troll: ICreature, ICanTurnToStone
Front end could then be:
void SpawnCreatureInSunlight(creatureType)
{
ICreature creature = _factory.GetCreature(creatureType);
creature.Walk();
if (creature is ICanTurnToStone)
{
(ICanTurnToStone)creature.TurnToStone();
}
}
C: Usage for dependency injection
Most dependency injection frameworks work when there is a very loose coupling between the front end code and the back end implementation. If we take our factory example above and have our factory implement an interface:
public interface ICreatureFactory {
ICreature GetCreature(string creatureType);
}
Our front end could then have this injected (e.g an MVC API controller) through the constructor (typically):
public class CreatureController : Controller {
private readonly ICreatureFactory _factory;
public CreatureController(ICreatureFactory factory) {
_factory = factory;
}
public HttpResponseMessage TurnToStone(string creatureType) {
ICreature creature = _factory.GetCreature(creatureType);
creature.TurnToStone();
return Request.CreateResponse(HttpStatusCode.OK);
}
}
With our DI framework (e.g. Ninject or Autofac), we can set them up so that at runtime a instance of CreatureFactory will be created whenever an ICreatureFactory is needed in an constructor - this makes our code nice and simple.
It also means that when we write a unit test for our controller, we can provide a mocked ICreatureFactory (e.g. if the concrete implementation required DB access, we don't want our unit tests dependent on that) and easily test the code in our controller.
D: There are other uses e.g. you have two projects A and B that for 'legacy' reasons are not well structured, and A has a reference to B.
You then find functionality in B that needs to call a method already in A. You can't do it using concrete implementations as you get a circular reference.
You can have an interface declared in B that the class in A then implements. Your method in B can be passed an instance of a class that implements the interface with no problem, even though the concrete object is of a type in A.

Examples above don't make much sense. You could accomplish all above examples using classes (abstract class if you want it to behave only as a contract):
public abstract class Food {
public abstract void Prepare();
}
public class Pizza : Food {
public override void Prepare() { /* Prepare pizza */ }
}
public class Burger : Food {
public override void Prepare() { /* Prepare Burger */ }
}
You get the same behavior as with interface. You can create a List<Food> and iterate that w/o knowing what class sits on top.
More adequate example would be multiple inheritance:
public abstract class MenuItem {
public string Name { get; set; }
public abstract void BringToTable();
}
// Notice Soda only inherits from MenuItem
public class Soda : MenuItem {
public override void BringToTable() { /* Bring soda to table */ }
}
// All food needs to be cooked (real food) so we add this
// feature to all food menu items
public interface IFood {
void Cook();
}
public class Pizza : MenuItem, IFood {
public override void BringToTable() { /* Bring pizza to table */ }
public void Cook() { /* Cook Pizza */ }
}
public class Burger : MenuItem, IFood {
public override void BringToTable() { /* Bring burger to table */ }
public void Cook() { /* Cook Burger */ }
}
Then you can use all of them as MenuItem and don't care about how they handle each method call.
public class Waiter {
public void TakeOrder(IEnumerable<MenuItem> order)
{
// Cook first
// (all except soda because soda is not IFood)
foreach (var food in order.OfType<IFood>())
food.Cook();
// Bring them all to the table
// (everything, including soda, pizza and burger because they're all menu items)
foreach (var menuItem in order)
menuItem.BringToTable();
}
}

Simple Explanation with analogy
No interface (Example 1):
No interface (Example 2):
With an interface:
The Problem to Solve: What is the purpose of polymorphism?
Analogy: So I'm a foreperson on a construction site. I don't know which tradesperson is going to walk in. But I tell them what to do.
If it's a carpenter I say: build wooden scaffolding.
If it's a plumber, I say: Set up the pipes
If it's a BJP government bureaucrat, I say, three bags full of cash, sir.
The problem with the above approach is that I have to: (i) know who's walking in that door, and depending on who it is, I have to tell them what to do. This typically makes code harder to maintain or more error prone.
The implications of knowing what to do:
This means if the carpenter's code changes from: BuildScaffolding() to BuildScaffold() (i.e. a slight name change) then I will have to also change the calling class (i.e. the Foreperson class) as well - you'll have to make two changes to the code instead of (basically) just one. With polymorphism you (basically) only need to make one change to achieve the same result.
Secondly you won't have to constantly ask: who are you? ok do this...who are you? ok do that.....polymorphism - it DRYs that code, and is very effective in certain situations:
with polymorphism you can easily add additional classes of tradespeople without changing any existing code. (i.e. the second of the SOLID design principles: Open-close principle).
The solution
Imagine a scenario where, no matter who walks in the door, I can say: "Work()" and they do their respect jobs that they specialise in: the plumber would deal with pipes, and the electrician would deal with wires, and a bureaucrat could specialise in extracting bribes and making double work for everyone else.
The benefit of this approach is that: (i) I don't need to know exactly who is walking in through that door - all i need to know is that they will be a type of tradie and that they can do work, and secondly, (ii) i don't need to know anything about that particular trade. The tradie will take care of that.
So instead of this:
if(electrician) then electrician.FixCablesAndElectricity()
if(plumber) then plumber.IncreaseWaterPressureAndFixLeaks()
if(keralaCustoms) then keralaCustoms.askForBribes()
I can do something like this:
ITradesman tradie = Tradesman.Factory(); // in reality i know it's a plumber, but in the real world you won't know who's on the other side of the tradie assignment.
tradie.Work(); // and then tradie will do the work of a plumber, or electrician etc. depending on what type of tradesman he is. The foreman doesn't need to know anything, apart from telling the anonymous tradie to get to Work()!!
What's the benefit?
The benefit is that if the specific job requirements of the carpenter etc change, then the foreperson won't need to change his code - he doesn't need to know or care. All that matters is that the carpenter knows what is meant by Work(). Secondly, if a new type of construction worker comes onto the job site, then the foreman doesn't need to know anything about the trade - all the foreman cares is if the construction worker (.e.g Welder, Glazier, Tiler etc.) can get some Work() done.
Summary
An interface allows you to get the person to do the work they are assigned to, without you having the knowledge of exactly who they are or the specifics of what they can do. This allows you to easily add new types (of trade) without changing your existing code (well technically you do change it a tiny tiny bit), and that's the real benefit of an OOP approach vs. a more functional programming methodology.
If you don't understand any of the above or if it isn't clear ask in a comment and i'll try to make the answer better.

Here are your examples reexplained:
public interface IFood // not Pizza
{
public void Prepare();
}
public class Pizza : IFood
{
public void Prepare() // Not order for explanations sake
{
//Prepare Pizza
}
}
public class Burger : IFood
{
public void Prepare()
{
//Prepare Burger
}
}

In the absence of duck typing as you can use it in Python, C# relies on interfaces to provide abstractions. If the dependencies of a class were all concrete types, you could not pass in any other type - using interfaces you can pass in any type that implements the interface.

The Pizza example is bad because you should be using an abstract class that handles the ordering, and the pizzas should just override the pizza type, for example.
You use interfaces when you have a shared property, but your classes inherit from different places, or when you don't have any common code you could use. For instance, this is used things that can be disposed IDisposable, you know it will be disposed, you just don't know what will happen when it's disposed.
An interface is just a contract that tells you some things an object can do, what parameters and what return types to expect.

Consider the case where you don't control or own the base classes.
Take visual controls for instance, in .NET for Winforms they all inherit from the base class Control, that is completely defined in the .NET framework.
Let's assume you're in the business of creating custom controls. You want to build new buttons, textboxes, listviews, grids, whatnot and you'd like them all to have certain features unique to your set of controls.
For instance you might want a common way to handle theming, or a common way to handle localization.
In this case you can't "just create a base class" because if you do that, you have to reimplement everything that relates to controls.
Instead you will descend from Button, TextBox, ListView, GridView, etc. and add your code.
But this poses a problem, how can you now identify which controls are "yours", how can you build some code that says "for all the controls on the form that are mine, set the theme to X".
Enter interfaces.
Interfaces are a way to look at an object, to determine that the object adheres to a certain contract.
You would create "YourButton", descend from Button, and add support for all the interfaces you need.
This would allow you to write code like the following:
foreach (Control ctrl in Controls)
{
if (ctrl is IMyThemableControl)
((IMyThemableControl)ctrl).SetTheme(newTheme);
}
This would not be possible without interfaces, instead you would have to write code like this:
foreach (Control ctrl in Controls)
{
if (ctrl is MyThemableButton)
((MyThemableButton)ctrl).SetTheme(newTheme);
else if (ctrl is MyThemableTextBox)
((MyThemableTextBox)ctrl).SetTheme(newTheme);
else if (ctrl is MyThemableGridView)
((MyThemableGridView)ctrl).SetTheme(newTheme);
else ....
}

In this case, you could ( and probably would ) just define a Pizza base class and inherit from them. However, there are two reasons where Interfaces allow you to do things that cannot be achieved in other ways:
A class can implement multiple interfaces. It just defines features that the class must have. Implementing a range of interfaces means that a class can fulfil multiple functions in different places.
An interface can be defined in a hogher scope than the class or the caller. This means that you can separate the functionality, separate the project dependency, and keep the functionality in one project or class, and the implementation of this elsewhere.
One implication of 2 is that you can change the class that is being used, just requiring that it implements the appropriate interface.

Consider you can't use multiple inheritance in C#, and then look at your question again.

I did a search for the word "composition" on this page and didn't see it once. This answer is very much in addition to the answers aforementioned.
One of the absolutely crucial reasons for using interfaces in an Object Oriented Project is that they allow you to favour composition over inheritance. By implementing interfaces you can decouple your implementations from the various algorithms you are applying to them.
This superb "Decorator Pattern" tutorial by Derek Banas (which - funnily enough - also uses pizza as an example) is a worthwhile illustration:
https://www.youtube.com/watch?v=j40kRwSm4VE

Interface = contract, used for loose coupling (see GRASP).

If I am working on an API to draw shapes, I may want to use DirectX or graphic calls, or OpenGL. So, I will create an interface, which will abstract my implementation from what you call.
So you call a factory method: MyInterface i = MyGraphics.getInstance(). Then, you have a contract, so you know what functions you can expect in MyInterface. So, you can call i.drawRectangle or i.drawCube and know that if you swap one library out for another, that the functions are supported.
This becomes more important if you are using Dependency Injection, as then you can, in an XML file, swap implementations out.
So, you may have one crypto library that can be exported that is for general use, and another that is for sale only to American companies, and the difference is in that you change a config file, and the rest of the program isn't changed.
This is used a great deal with collections in .NET, as you should just use, for example, List variables, and don't worry whether it was an ArrayList or LinkedList.
As long as you code to the interface then the developer can change the actual implementation and the rest of the program is left unchanged.
This is also useful when unit testing, as you can mock out entire interfaces, so, I don't have to go to a database, but to a mocked out implementation that just returns static data, so I can test my method without worrying if the database is down for maintenance or not.

Interfaces are for applying connection between different classes. for example, you have a class for car and a tree;
public class Car { ... }
public class Tree { ... }
you want to add a burnable functionality for both classes. But each class have their own ways to burn. so you simply make;
public class Car : IBurnable
{
public void Burn() { ... }
}
public class Tree : IBurnable
{
public void Burn() { ... }
}

You will get interfaces, when you will need them :) You can study examples, but you need the Aha! effect to really get them.
Now that you know what interfaces are, just code without them. Sooner or later you will run into a problem, where the use of interfaces will be the most natural thing to do.

An interface is really a contract that the implementing classes must follow, it is in fact the base for pretty much every design pattern I know.
In your example, the interface is created because then anything that IS A Pizza, which means implements the Pizza interface, is guaranteed to have implemented
public void Order();
After your mentioned code you could have something like this:
public void orderMyPizza(IPizza myPizza) {
//This will always work, because everyone MUST implement order
myPizza.order();
}
This way you are using polymorphism and all you care is that your objects respond to order().

I'm surprised that not many posts contain the one most important reason for an interface: Design Patterns. It's the bigger picture into using contracts, and although it's a syntax decoration to machine code (to be honest, the compiler probably just ignores them), abstraction and interfaces are pivotal for OOP, human understanding, and complex system architectures.
Let's expand the pizza analogy to say a full fledge 3 course meal. We'll still have the core Prepare() interface for all our food categories, but we'd also have abstract declarations for course selections (starter, main, dessert), and differing properties for food types (savoury/sweet, vegetarian/non-vegetarian, gluten free etc).
Based on these specifications, we could implement the Abstract Factory pattern to conceptualise the whole process, but use interfaces to ensure that only the foundations were concrete. Everything else could become flexible or encourage polymorphism, yet maintain encapsulation between the different classes of Course that implement the ICourse interface.
If I had more time, I'd like to draw up a full example of this, or someone can extend this for me, but in summary, a C# interface would be the best tool in designing this type of system.

Here's an interface for objects that have a rectangular shape:
interface IRectangular
{
Int32 Width();
Int32 Height();
}
All it demands is that you implement ways to access the width and height of the object.
Now let's define a method that will work on any object that is IRectangular:
static class Utils
{
public static Int32 Area(IRectangular rect)
{
return rect.Width() * rect.Height();
}
}
That will return the area of any rectangular object.
Let's implement a class SwimmingPool that is rectangular:
class SwimmingPool : IRectangular
{
int width;
int height;
public SwimmingPool(int w, int h)
{ width = w; height = h; }
public int Width() { return width; }
public int Height() { return height; }
}
And another class House that is also rectangular:
class House : IRectangular
{
int width;
int height;
public House(int w, int h)
{ width = w; height = h; }
public int Width() { return width; }
public int Height() { return height; }
}
Given that, you can call the Area method on houses or swimming-pools:
var house = new House(2, 3);
var pool = new SwimmingPool(3, 4);
Console.WriteLine(Utils.Area(house));
Console.WriteLine(Utils.Area(pool));
In this way, your classes can "inherit" behavior (static-methods) from any number of interfaces.

What ?
Interfaces are basically a contract that all the classes implementing the Interface should follow. They looks like a class but has no implementation.
In C# Interface names by convention is defined by Prefixing an 'I' so if you want to have an interface called shapes, you would declare it as IShapes
Now Why ?
Improves code re-usability
Lets say you want to draw Circle, Triangle.
You can group them together and call them Shapesand have methods to draw Circle and Triangle
But having concrete implementation would be a bad idea because tomorrow you might decide to have 2 more Shapes Rectangle & Square. Now when you add them there is a great chance that you might break other parts of your code.
With Interface you isolate the different implementation from the Contract
Live Scenario Day 1
You were asked to create an App to Draw Circle and Triangle
interface IShapes
{
void DrawShape();
}
class Circle : IShapes
{
public void DrawShape()
{
Console.WriteLine("Implementation to Draw a Circle");
}
}
Class Triangle: IShapes
{
public void DrawShape()
{
Console.WriteLine("Implementation to draw a Triangle");
}
}
static void Main()
{
List <IShapes> shapes = new List<IShapes>();
shapes.Add(new Circle());
shapes.Add(new Triangle());
foreach(var shape in shapes)
{
shape.DrawShape();
}
}
Live Scenario Day 2
If you were asked add Square and Rectangle to it, all you have to do is create the implentation for it in class Square: IShapes and in Main add to list shapes.Add(new Square());

An interface defines a contract between the provider of a certain functionality and the correspondig consumers. It decouples the implementation from the contract (interface). You should have a look at object oriented architecture and design. You may want to start with wikipedia: http://en.wikipedia.org/wiki/Interface_(computing)

There are a lot of good answers here but I would like to try from a slightlt different perspective.
You may be familiar with the SOLID principles of object oriented design. In summary:
S - Single Responsibility Principle
O - Open/Closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D - Dependency Inversion Principle
Following the SOLID principles helps to produce code that is clean, well factored, cohesive and loosely coupled. Given that:
"Dependency management is the key challenge in software at every scale" (Donald Knuth)
then anything that helps with dependency management is a big win. Interfaces and the Dependency Inversion Principle really help to decouple code from dependencies on concrete classes, so code can be written and reasoned about in terms of behaviours rather than implementations. This helps to break the code into components which can be composed at runtime rather than compile time and also means those components can be quite easily plugged in and out without having to alter the rest of the code.
Interfaces help in particular with the Dependency Inversion Principle, where code can be componentized into a collection of services, with each service being described by an interface. Services can then be "injected" into classes at runtime by passing them in as a constructor parameter. This technique really becomes critical if you start to write unit tests and use test driven development. Try it! You will quickly understand how interfaces help to break apart the code into manageable chunks that can be individually tested in isolation.

Soo many answers!
Giving my best shot. hehe.
So to begin, yes you could have used a concrete base and derived class here. In that case, you would have to do an empty or useless implementation for the Prepare method in the base class also making this method virtual and then the derived classes would override this Prepare method for themselves. This case, the implementation of Prepare in Base class is useless.
The reason why you chose to use an Interface is because you had to define a contract, not an implementation.
There is a IPizza type and it provides a functionality to Prepare. This is contract. How it is prepared is the implementation and it is not your lookout. It is responsibility of the various Pizza implementations.
An interface or an abstract class is preferred here over a concrete base class because you had to create an abstraction, i.e., the Prepare method. You cannot create an abstract method in a concrete base class.
Now you could say, why not use an abstract class?
So, when you need to achieve 100% abstraction, you need to go with Interface. But when you need some abstraction along with a concrete implementation, go with abstract class. It means.
Example: Lets say all your pizzas will have a base and base preparation will be the same process. However, all pizza types and toppings will vary. In this case you could create an Abstract class with an abstract method Prepare and a concrete method PreparePizzaBase.
public abstract class Pizza{
// concrete method which is common to all pizzas.
public PizzaBase PreparePizzaBase(){
// code for pizza base preparation.
}
public abstract void Prepare();
}
public class DeluxePizza: Pizza{
public void Prepare(){
var base=PreparePizzaBase();
// prepare deluxe pizza on pizza base.
}
}

The main purpose of the interfaces is that it makes a contract between you and any other class that implement that interface which makes your code decoupled and allows expandability.

Therese are ask really great examples.
Another, in the case of a switch statement, you no longer have the need to maintain and switch every time you want rio perform a task in a specific way.
In your pizza example, if want to make a pizza, the interface is all you need, from there each pizza takes care of it's own logic.
This helps to reduce coupling and cyclomatic complexity. You have to still implement the logic but there will be less you have to keep track of in the broader picture.
For each pizza you can then keep track of information specific to that pizza. What other pizzas have doesn't matter because only the other pizzas need to know.

The simplest way to think about interfaces is to recognize what inheritance means. If class CC inherits class C, it means both that:
Class CC can use any public or protected members of class C as though they were its own, and thus only needs to implement things which do not exist in the parent class.
A reference to a CC can be passed or assigned to a routine or variable that expects a reference to a C.
Those two function of inheritance are in some sense independent; although inheritance applies both simultaneously, it is also possible to apply the second without the first. This is useful because allowing an object to inherit members from two or more unrelated classes is much more complicated than allowing one type of thing to be substitutable for multiple types.
An interface is somewhat like an abstract base class, but with a key difference: an object which inherits a base class cannot inherit any other class. By contrast, an object may implement an interface without affecting its ability to inherit any desired class or implement any other interfaces.
One nice feature of this (underutilized in the .net framework, IMHO) is that they make it possible to indicate declaratively the things an object can do. Some objects, for example, will want data-source object from which they can retrieve things by index (as is possible with a List), but they won't need to store anything there. Other routines will need a data-depository object where they can store things not by index (as with Collection.Add), but they won't need to read anything back. Some data types will allow access by index, but won't allow writing; others will allow writing, but won't allow access by index. Some, of course, will allow both.
If ReadableByIndex and Appendable were unrelated base classes, it would be impossible to define a type which could be passed both to things expecting a ReadableByIndex and things expecting an Appendable. One could try to mitigate this by having ReadableByIndex or Appendable derive from the other; the derived class would have to make available public members for both purposes, but warn that some public members might not actually work. Some of Microsoft's classes and interfaces do that, but that's rather icky. A cleaner approach is to have interfaces for the different purposes, and then have objects implement interfaces for the things they can actually do. If one had an interface IReadableByIndex and another interface IAppendable, classes which could do one or the other could implement the appropriate interfaces for the things they can do.

Interfaces can also be daisy chained to create yet another interface. This ability to implement multiple Interfaces give the developer the advantage of adding functionality to their classes without having to change current class functionality (SOLID Principles)
O = "Classes should be open for extension but closed for modification"

To me an advantage/benefit of an interface is that it is more flexible than an abstract class. Since you can only inherit 1 abstract class but you can implement multiple interfaces, changes to a system that inherits an abstract class in many places becomes problematic. If it is inherited in 100 places, a change requires changes to all 100. But, with the interface, you can place the new change in a new interface and just use that interface where its needed (Interface Seq. from SOLID). Additionally, the memory usage seems like it would be less with the interface as an object in the interface example is used just once in memory despite how many places implement the interface.

Interfaces are used to drive consistency,in a manner that is loosely coupled which makes it different to abstract class which is tightly coupled.That's why its also commonly defined as a contract.Whichever classes that implements the interface has abide to "rules/syntax" defined by the interface and there is no concrete elements within it.
I'll just give an example supported by the graphic below.
Imagine in a factory there are 3 types of machines.A rectangle machine,a triangle machine and a polygon machine.Times are competitive and you want to streamline operator training.You just want to train them in one methodology of starting and stopping machines so you have a green start button and red stop button.So now across 3 different machines you have a consistent way of starting and stopping 3 different types of machines.Now imagine these machines are classes and the classes need to have start and stop methods,how you going to drive consistency across these classes which can be very different? Interface is the answer.
A simple example to help you visualize,one might ask why not use abstract class? With an interface the objects don't have to be directly related or inherited and you can still drive consistency across different classes.
public interface IMachine
{
bool Start();
bool Stop();
}
public class Car : IMachine
{
public bool Start()
{
Console.WriteLine("Car started");
return true;
}
public bool Stop()
{
Console.WriteLine("Car stopped");
return false;
}
}
public class Tank : IMachine
{
public bool Start()
{
Console.WriteLine("Tank started");
return true;
}
public bool Stop()
{
Console.WriteLine("Tank stopped");
return false;
}
}
class Program
{
static void Main(string[] args)
{
var car = new Car();
car.Start();
car.Stop();
var tank = new Tank();
tank.Start();
tank.Stop();
}
}

class Program {
static void Main(string[] args) {
IMachine machine = new Machine();
machine.Run();
Console.ReadKey();
}
}
class Machine : IMachine {
private void Run() {
Console.WriteLine("Running...");
}
void IMachine.Run() => Run();
}
interface IMachine
{
void Run();
}
Let me describe this by a different perspective. Let’s create a story according to the example which i have shown above;
Program, Machine and IMachine are the actors of our story. Program wants to run but it has not that ability and Machine knows how to run. Machine and IMachine are best friends but Program is not on speaking terms with Machine. So Program and IMachine make a deal and decided that IMachine will tell to Program how to run by looking Machine(like a reflector).
And Program learns how to run by help of IMachine.
Interface provides communication and developing loosely coupled projects.
PS: I’ve the method of concrete class as private. My aim in here is to achieve loosely coupled by preventing accessing concrete class properties and methods, and left only allowing way to reach them via interfaces. (So i defined interfaces’ methods explicitily).

Understanding Interfaces V Classes

Hi I know this is a well trodden question but after reading the following post What is the difference between an interface and a class, and why I should use an interface when I can implement the methods directly in the class? I am struggling to understand why an interface really needs to be used. Sorry for the basic question here but while I get the theory as a contract between the interface and the class I cannot seem to see how useful this is. I know it can help you create objects easily but I feel like I am missing something.
I have read so many posts on here and all over the internet to how to use an Interface but half of the time I am like well if you create a class and inherit it would it not do the same thing? what am I missing here?

Why interfaces?
Do you drive a car? If not, I assume you know what driving a car generally entails (steering wheel, accelerator, brake). The rest of the answer assumes you drive a car and have a car that is a different brand than mine.
Have you ever driven my car? No. But if given access, would you be able to drive my car without needing to learn how to drive my car? Yes.
The same applies to me. I've never driven your car, but I would be able to drive it without needing to learn how to drive it.
Why is that? Because all cars share the same interface. Steering wheel, accelerator on the right, brake in the middle. No two cars are exactly the same, but they are built in a way that the interaction between a driver and any car is exactly the same.
Compare this to an F16 fighter jet. Being able to drive a car does not make you able to pilot a jet because its interface is different. It doesn't have a steering wheel, it doesn't have accelerator/brake pedals.
The main benefit is clear: drivers don't need to learn how to drive every car individually.
Now, to complete the analogy, the general concept of a car is an interface, whereas specific cars are classes. The main benefit is clear: you don't need to write custom code for every similar class.
A practical example
public class BMW
{
public SteeringWheel SteeringWheel { get; set; }
public Pedal Accelerator { get; set; }
public Pedal Brake { get; set; }
}
public class BMWDriver
{
public void ParticipateInRace(BMW myBMW)
{
myBMW.Accelerator.Press();
myBMW.SteeringWheel.TurnLeft();
myBMW.SteeringWheel.TurnRight();
myBMW.Accelerator.Release();
myBMW.Brake.Press();
myBMW.Brake.Release();
}
}
This driver only knows how to drive a BMW.
public class Audi
{
public SteeringWheel SteeringWheel { get; set; }
public Pedal Accelerator { get; set; }
public Pedal Brake { get; set; }
}
public class AudiDriver
{
public void ParticipateInRace(Audi myAudi)
{
myAudi.Accelerator.Press();
myAudi.SteeringWheel.TurnLeft();
myAudi.SteeringWheel.TurnRight();
myAudi.Accelerator.Release();
myAudi.Brake.Press();
myAudi.Brake.Release();
}
}
This driver only knows how to drive an Audi.
But in reality, a driver would be able to drive any car (that has a steering wheel and two pedals).
So how do we tell the compiler that any car can be used? We give them a commonality they both share: the interface.
public interface ICar
{
SteeringWheel SteeringWheel { get; }
Pedal Accelerator { get; }
Pedal Brake { get; }
}
public class BMW : ICar { /* same as before */ }
public class Audi : ICar { /* same as before */ }
public class Driver
{
public void ParticipateInRace(ICar anyCar)
{
anyCar.Accelerator.Press();
anyCar.SteeringWheel.TurnLeft();
anyCar.SteeringWheel.TurnRight();
anyCar.Accelerator.Release();
anyCar.Brake.Press();
anyCar.Brake.Release();
}
}
We now have a more generalized Driver who is able to drive any car that has a steering wheel and two pedals.
Why not inheritance?
half of the time I am like well if you create a class and inherit it would it not do the same thing? what am I missing here?
In some cases, inheritance would work. However, inheritance is generally an inferior solution, especially when you get into more complex codebases or more advanced architectures.
Don't worry, all developers once loved inheritance and then needed to learn to not use inheritance as a cure-all. It's part of the normal lifecyle of a developer :)
One of the biggest reasons why is that you can't derive from more than one class, but you can implement multiple interfaces.
Let's say we have three types of sports that can be done
public class Runner
{
public void Run() { /* running logic */ }
}
public class Swimmer
{
public void Swim() { /* swimming logic */ }
}
public class Cyclist
{
public void Cycle() { /* cycling logic */ }
}
Now we need to create a specialized sport which entails running, e.g. basketball.
public class BasketBallPlayer : Runner
{
public void ThrowBall() { /* throwing logic */ }
// Running is already inherited from Runner
}
Great, no problems yet. But now, we need to create a triathlete class, which entails all three sports (running, swimming, cycling)
public class Triathlete: Runner, Swimmer, Cyclist { ... }
And this is where the compiler breaks down. It refuses to allow you to inherit from multiple base classes at the same time. The reasons are much deeper than this answer can delve into, Google it if you want to know more.
However, had we used interfaces:
public interface IRunner
{
void Run();
}
public interface ISwimmer
{
void Swim();
}
public interface ICyclist
{
void Cycle();
}
Then the compiler would've allowed this:
public class Triathlete: IRunner, ISwimmer, ICyclist
{
public void Run() { /* running logic */ }
public void Swim() { /* swimming logic */ }
public void Cycle() { /* cycling logic */ }
}
And this is why interfaces generally beat inheritance (among other reasons).
There are more reasons why interfaces are generally better, but this is the biggest one. Google it if you want more explanation, I can't delve into it all for a StackOverflow answer.

one scenario where you (the creator of the overall algorithm) simply doesn't know the implementation in advance.
To convert them into real life scenarios:
FxCop + StyleCop both use the visitor pattern to scan code. So, the creators of the tool (FxCop) in this example, has some basic code that couples to some UI/CLI and expects some certain properties in the scan result such as severity/problem etc.
And while FxCop ships with default rules, you, as end customer, can also extend these rules to your own liking. The only way for FxCop to do that is to rely on polymorpishm Interfaces/Abstract Classes.
So the FxCop tool expects a rule instance which detects something and reports back success or failure.
But your organization might have a custom rule which only you need. Let's say it's something like: All our namespaces must begin with myorg.mytool
That's an example of where you must use abstraction (can't just implement the code in a class up front) since Microsoft doedn't know anything in particular about the custom code rules tha you enforce in your organisation.
Another example is the way that Domain- and Infrastructure code are separated in Domain Driven Design.
So, let's say you have a book collection app. One where you can get a book, all books books by an auther etc.
You will then have a Domain Type call something like BookRepository where all your books are persisted. There's two sides of this: 1. Domain where all handling logic of books are placed and 2. persistence code (IO/Database or whatever).
The reason to split these two is because then the domain logic (business logic) doesn't get entangled with persistance code. The Domain code doesn't want to know how a book is persisted. It only cares about what you can do with a book (Get by Author, Buy, Sell etc.).
The interface in this case comes in as you place an interface in your Domain code called something like IBookRepository and you go on creating all the code you need with unit tests. At this point, you don't care much about how books are stored - you just care that they are stored. Then another team or later, you can dive into the details about how the book sa restored. In a database, in cache or something else. The persistence code can also evolve without touching the domain code which is an integral part of Continuous Release principles: As small updates as possible. In other words, it allows you to ship infrastructure updates wo touching the business code. It could be that you app is working excellent but you wan't to update the database drivers.
Abstract classes are something in between interfaces and classes but should be used similar as to interfaces / they're close in usage to interfaces than classes.
**
finally, there's another reason to use interfaces which is that an interface can be considered an aspect and you can apply multiple interfaces (aspects) to a single class (multiple inheritance) with little friction whereas placing it in classes forces you to do single inheritance which can result in large and overly complex inheritance hierachies.
Hope it helps you a bit

Well in essence and with as few words as i can think of for each case:
Abstract should be used when you have different entities sharing
common behavior.
Interface should be used when you want different entities to be able to work with the same code
For example you would use abstract when:
You want to create an app that handles animals.
You create an abstract class Animal which contains some fields NoLegs,HasTail,NoEyes.
You create a Dog , a Cat and a Panda class, all inheriting from Animal.
Now you end up having 3 classes, but with the shared code defined in 1 other class, because all of them share those descriptive traits.
Now for the interface:
Inside a service in your project you create a method called 'StartRunning'.
The definition of the method is :
public void StartRunning(List<ICanRun> thingsThatRun)
{
thingsThatRun.forEach(t => t.StartRunning());
}
Now you go back to your animal abstract class and you declare that it should implement ICanRun interface, and the compiler will force you to go and define the method on Dog,Cat and Panda classes. The great part now is that:
You have defined properties that are common in different objects only once. ( number of eyes is a trait common when describing animals)
The way each animal runs is different.Your dogs run method could 'just run straight ahead', while your cat run method could 'look for the closest wall and climb'. The Panda would probably throw cause pandas don't run.
The real magic on the interface:
Because your StartRunning method does not consider classes, but rather that the objects passed comform to the ICanRun interface, you can have an other class, say Bike, that also implements ICanRun and defines the method StartRunning.
Then you can create a list containing a dog, a cat and a bike and throw those 3 unrelated classes to the same list and pass that list to StartRunning, and they will all "Start running".
List<ICanRun> runableThings = new List<ICanRun>(){new Dog(), new Cat(), new Bike()};
StartRunning(runableThings);
I hope this example helps

Manipulator Factory

EDIT4 Gave Truck a property to show the SetNrOfWheels method is tailored to a specific Truck
EDIT3 Made a connection between B - Vehicle and C1 - Truck
EDIT2 Removed interface on B
EDIT1 Changed Car into Vehicle
I have two questions about a problem I ran into several times. I wonder if I must use another pattern, or if someone could point me in the right/better direction.
If you know an article here describing the answer, please let me know and I will try to delete this one.
Consider an abstract base class B (i.e. Vehicle), which is inherited by a number of child classes, C1, C2, etc. (i.e. Truck, Motor) Suppose these classes are pure data carriers, i.e. data contracts, and consist of a number of properties. Although not strictly necessary for the story, they use a default constructor without arguments and all properties are public, and simple value type objects. They may or may not inherit some predefined properties, but most importantly, B is more or less a marker, rather than it enforces functionality (since it is a data contract).
Example:
abstract Vehicle {
int NrOfWheels { get; set;}
}
Truck : Vehicle {
bool HasExtraTrailer { get; set; }
}
Now consider a manipulator of B called BM (i.e. VehicleWheelSetter), which is either an abstract base class or an interface (you decide what's best here ;)). It has (at least abstract) functionality to manipulate B classes. Suppose each manipulator, i.e. C1M, C2M, (TruckWheelSetter, MotorWheelSetter) inherits from BM. Important is, that the type is enforced, ergo, C1M only manipulates C1 type of classes. This could be enforced by BM being generic, say BM<T> where T : B, although this is limited (this would allow for an XM : BM<B> still)
Example:
interface IVehicleWheelSetter<in T> where T : Vehicle {
void SetNrOfWheels(T vehicle)
}
TruckWheelSetter : IVehicleWheelSetter<Truck> {
void SetNrOfWheels(Truck vehicle) {
vehicle.NrOfWheels = 2 * 3;
if (vehicle.HasExtraTrailer) vehicle.NrOfWheels += 2 * 2;
} } }
Question 1: Is there a way to make sure a concrete BM (i.e. C1M) is always manipulating a concrete B (in this case C1)? Or does this require another pattern?
Let's assume that in general, this will be much more complex then assigning a number (which could obviously be retrieved from a configuration or database). It's not a coincidence I wrote 2 * 3, to show that this could be a complex operation.
Suppose I know I get B classes all the time in some service that has to do a manipulation, like a factory, something like this:
VehicleWheelSetterFactory {
IVehicleWheelSetter<T> CreateVehicleWheelSetter<T>() where T : Vehicle {
// code to create the right selector here
} }
Now, there are various ways to do this:
if (typeof(T) == typeof(Truck))
return (IVehicleWheelSetter<T>)(new TruckWheelSetter());
throw new NotImplementedException();
or some more advanced reflection based options.
There are some problems with this, aside from some 'it does not feel right'. There will also be cases in which a generic does not work, i.e. T is unknown. In that case, a Type in the argument could help:
object CreateVehicleWheelSetter(Type vehicleType) {
if (vehicleType == typeof(Truck))
return new TruckWheelSetter();
throw new NotImplementedException();
}
but how to cast the object to an IVehicleWheelSetter<T>? T is still unknown! So, maybe the interface should be this:
interface ICarWheelSetter
{
void SetNrOfWheels(Vehicle vehicle);
}
But now I have the original problem: I cannot guarantee the Vehicle is a Truck in TruckWheelSetter. This also not be resolved this way:
interface IVehicleWheelSetter
{
void SetNrOfWheels<T>(T car) where T : Vehicle;
}
Question 2: Is there a better way to do this?

Not sure if I get your problem (how can T be unknown, if you parse concrete instances), but anyway, wouldn't this be easy:
public class CarWheelSetter
{
public static void SetNrOfWheels<T>(T car) where T : Car
{
WheelSetterFor<T>().SetNrOfWheels(car);
}
private static ICarWheelSetter<T> WheelSetterFor<T>() where T : Car
{
if (typeof(T) == typeof(Truck))
{
return new TruckWheelSetter() as ICarWheelSetter<T>;
}
throw new NotImplementedException();
}
}

Consider an abstract base class/interface B
These are not arbitrarily interchangeable things. I would expect a public class abstract Car not an interface. The purpose of interface - the C# keyword specific meaning - is to define "the same, but different" behavior for unrelated classes. For example we might want a IFly interface so we can "fly" bugs, birds, and bombers - that are otherwise unrelated classes.
But Car and Truck are related so through the basic mechanisms of inheritance and polymorphism there is no need for arbitrary interfaces in handling Car sub-classes.
Suppose these classes are pure data carriers
The fundamental OO idea of a class is data + its methods. The idea of Car and its derivatives needs to be fleshed out. This will inform the car factory design.
And I'd expect many Car properties are their own classes. If a wheel assembly is as complex as suggested then maybe that should be a class.
B is more or less a marker
A Car is just a marker - nothing essentially? How can you build nothing? By building anything, which is where this design is going I think. No wonder you're trying to build Granular interfaces like ICarWheelSetter. But these are just wrong here. Imagine what the code would look like when you did this for every property in Car and its derivatives. It seems me that this is a symptom of an inadequately defined domain model. As shown, I have no idea what a Car is and its derivatives more so. Because we have nothing concrete to work any sub-class might be anything and the code seems to support this fuzzy idea.
Is there a way to make sure a concrete BM (i.e. C1M) is always manipulating a concrete B (in this case C1)? Or does this require another pattern?
I'm reminded of the visitor design pattern. I imagine a Garage fixing a Car. The Garage knows how to manipulate a Car to fix it. Further, a derived BMWGarage will know how to fix a BMW Car sub-class.
And so I imagine a Garage inheritance hierarchy that mirrors the Car hierarchy. Maybe not precisely: a ForeignCarGarage might handle several different Car types.
Is there a way to make sure a concrete BM is always manipulating a concrete B?
Of course. Call the factory and tell it to make a car, and then a garage for that car
var myBeamer = CarFactory.Create(carEnum.BMW);
var beamerGarage = GarageFactory.Create (typeof(myBeamer).FullName);
The above suggests a need for an abstract factory. Note there are 3 "levels" of factory. Which to use is a matter of the complexity of what needs building. Further, we might see a builder pattern to coordinate the complex steps in car (or garage) creation.
So that might mean we create a factory for the specific Car derivative and its garage. This BMWFactory uses BMW parts - classes like BMWWheelAssembly.
var BMWFactory = new CarFactory(carEnum.Bmw);
var myBeamer = BMWFactory.Create();
AND NOW a CarFactory might implement an interface, or be an abstract class - but not both I think. If there is base-implementation I'd expect an abstract class. The abstract class could template the assembly process so assembly - calling methods - is done in the right order.

Can anybody give a good example of what to use generic classes for?

We recently learned about generic classes in C#, but our teacher failed to mention what they can be used for. I can't really find any good examples and would be extremly happy if somebody help me out :)
Have you made your own generic class, and what did you use it for?
Some code examples would make me, and my classmates, really happy! Pardon the bad english, I am from sweden :)
happy programming!
Sorry- I think I could have written the question a bit better. I am familar with generic collections. I just wondered what your own generic classes can be used for.
and thank you for the MSDN links, I did read them before posting the question, but maybe I missed something? I will have a second look!

Generic Collections
Generics for collections are very useful because they allow compile time type safety. This is useful for a few reasons:
No casting is required when retreiving values. This is not only a performance benefit but also eliminates the risk of there being a casting exception at runtime
When value types are added to a non generic list such as an ArrayList, the value's have to be boxed. This means that they are stored as reference types. It also means that not only does the value get stored in memory, but so does a reference to it, so more memory than necessery is used. This problem is eliminated when using generic lists.
Generic Classes
Generic classes can be useful for reusing common code for different types. Take for example a simple non generic factory class:
public class CatFactory
{
public Cat CreateCat()
{
return new Cat();
}
}
I can use a generic class to provide a factory for (almost) any type:
public class Factory<T> where T : new()
{
public T Create()
{
return new T();
}
}
In this example I have placed a generic type constraint of new() on the type paramter T. This requires the generic type to contain a parameterless contructor which enables me to create an instance without knowing the type.

Just because you said you are Swedish, I thought I'd give an example integrating IKEA furniture. Your kit couches are an infestation in north america, so I thought I'd give something back :) Imagine a class which represents a particular kit for building chairs and tables. To remain authentic, I'll even use nonsense swedish linguistic homonyms:
// interface for included tools to build your furniture
public interface IToolKit {
string[] GetTools();
}
// interface for included parts for your furniture
public interface IParts {
string[] GetParts();
}
// represents a generic base class for IKEA furniture kit
public abstract class IkeaKit<TContents> where TContents : IToolKit, IParts, new() {
public abstract string Title {
get;
}
public abstract string Colour {
get;
}
public void GetInventory() {
// generic constraint new() lets me do this
var contents = new TContents();
foreach (string tool in contents.GetTools()) {
Console.WriteLine("Tool: {0}", tool);
}
foreach (string part in contents.GetParts()) {
Console.WriteLine("Part: {0}", part);
}
}
}
// describes a chair
public class Chair : IToolKit, IParts {
public string[] GetTools() {
return new string[] { "Screwdriver", "Allen Key" };
}
public string[] GetParts() {
return new string[] {
"leg", "leg", "leg", "seat", "back", "bag of screws" };
}
}
// describes a chair kit call "Fnood" which is cyan in colour.
public class Fnood : IkeaKit<Chair> {
public override string Title {
get { return "Fnood"; }
}
public override string Colour {
get { return "Cyan"; }
}
}
public class Snoolma : IkeaKit<Chair> {
public override string Title {
get { return "Snoolma "; }
}
public override string Colour {
get { return "Orange"; }
}
}
Ok, so now we've got all the bits we need to figure out how to build some cheap furniture:
var fnood = new Fnood();
fnood.GetInventory(); // print out tools and components for a fnood chair!
(Yes, the lack of instructions and the three legs in the chair kit is deliberate.)
Hope this helps in a cheeky way.

If one has a List object (non-generic), one can store into it anything that can be cast into Object, but there's no way of knowing at compile time what type of things one will get out of it. By contrast, if one has a generic List<Animal>, the only things one can store into it are Animal or derivatives thereof, and the compiler can know that the only things that will be pulled out of it will be Animal. The compiler can thus allow things to be pulled out of the List and stored directly into fields of type Animal without any need for run-time type checking.
Additionally, if the generic type parameter of a generic class happens to be a value type, use of generic types can eliminate the need for casting to and from Object, a process called "Boxing" which converts value-type entities into reference-type objects; boxing is somewhat slow, and can sometimes alter the semantics of value-type objects, and is thus best avoided when possible.
Note that even though an object of type SomeDerivedClass may be substitutable for TheBaseClass, in general, a GenericSomething<SomeDerivedClass> is not substitutable for a GenericSomething<TheBaseClass>. The problem is that if one could substitute e.g. a List<Giraffe> for a List<Zebra>, one could pass a List<Zebra> to a routine that was expecting to take a List<Giraffe> and store an Elephant in it. There are a couple of cases where substitutability is permitted, though:
Arrays of a derived type may be passed to routines expecting arrays of base type, provided that those routines don't try to store into those arrays any items that are not of the proper derived type.
Interfaces may be declared to have "out" type parameters, if the only thing those interfaces will do is return ("output") values of that type. A Giraffe-supplier may be substituted for an Animal-supplier, because all it's going to do is supply Giraffes, which are in turn substitutable for animals. Such interfaces are "covariant" with respect to those parameters.
In addition, it's possible to declare interfaces to declare "in" type parameters, if the only thing the interfaces do is accept parameters of that type by value. An Animal-eater may be substituted a Giraffe-eater, because--being capable of eating all Animals, it is consequently capable of eating all Giraffes. Such interfaces are "contravariant" with respect to those parameters.

The most common example is for collections such as List, Dictionary, etc. All those standard classes are implemented using generics.
Another use is to write more general utility classes or methods for operations such as sorting and comparisons.

Here is a Microsoft article that can be of help: http://msdn.microsoft.com/en-us/library/b5bx6xee%28v=vs.80%29.aspx
The largest benefit that I've seen is the compile-time safety of generics, as #Charlie mentioned. I've also used a generic class to implement a DataReader for bulk inserts into a database.

Well, you have a lot of samples inside the framework. Imagine that you need to implement a list of intergers, and later a list of strings... and later a list of you customer class... etc. It would be very painfull.
But, if you implements a generic list the problem is solved in less time, in less code and you only have to test one class.
Maybe one day you will need to implement your own queue, with rules about the priority of every element. Then, it would be a good idea to make this queue generic if it is possible.
This is a very easy sample, but as you improve your coding skills, you will see how usefull can be to have (for example) a generic repository (It's a design patters).
Not everyday programmers make generic classes, but trust me, you will be happy to count with such tool when you need it.

real world example for generics.
Think u have a cage where there are many different birds(parrot,pegion,sparrow,crow,duck) in it(non generic).
Now you are assigned a work to move the bird to seperate cages(specifically built for single bird) from the cage specified above.
(problem with the non generic list)
It is a tedious task to catch the specific bird from the old cage and to shift it to the cage made for it.(Which Type of bird to which cage --Type casting in c#)
generic list
Now think you have a seperate cage for seperate bird and you want to shift to other cages made for it. This will be a easy task and it wont take time for you to do it(No type casting required-- I mean mapping the birds with cages).

My friend is not a programmer and I would like to explain what is generics? I would explain him generics as below. Thus this is a real-world scenario of using generics.
"There is this manufacturer in the next street. He can manufacture any automobile. But at one instance he can manufacture only one type of automobile. Last week, he manufactured a CAR for me, This week he manufactured a TRUCK for my uncle. Like I said this manufacturing unit is so generic that it can manufacture what the customer specifies. But note that when you go to approach this manufacturer, you must go with a type of automobile you need. Otherwise approaching him is simply not possible."

Have a look at this article by Microsoft. You have a nice and clear explanation of what to use them for and when to use them. http://msdn.microsoft.com/en-us/library/ms172192.aspx

The various generic collections are the best example of generics usage but if you want an example you might generate yourself you could take a look at my anwer to this old question:
uses of delegates in c or other languages
Not sure if it's a particularly great example of generics usage but it's something I find myself doing on occasion.

Are you talking about a base class (or perhaps an abstract class)? As a class that you would build other classes (subclasses) off of?
If that's the case, then you'd create a base class to include methods and properties that will be common to the classes that inherit it. For example, a car class would include wheels, engine, doors, etc. Then maybe you'd maybe create a sportsCar subclass that inherits the car class and adds properties such as spoiler, turboCharger, etc.
http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)
enter link description here
It's hard to understand what you mean by "generic class" without some context.

Creating a Namespace -> Class -> Nested Class? or

I was reading about creating classes and nested classes to determine what is the best approach for my needs, but I couldn't find something similar to what I need ( or couldn't understand it ;) ).
I will give you guys a (almost) real-life example:
Let's say I own a factory which manufactures different kinds of vehicles. So, my namespace would be Factory I figure.
Now, lets say the factory manufactures cars, boats and airplanes. So I will add three classes to my Factory namespace with those names.
Here is where my problem is with understanding the other methods:
I have some common things between the three types of vehicles. For example, they all have an engine (might be different HP or shapes which I understand are properties of the engine, but still they all have an engine). Also, cars and airplanes have doors (sometimes boats do too). On the other hand, they also have some unique things (airplanes have propellers for example that might come in different sizes or shapes).
Can someone please describe what I said in code so I could understand the differences between them?

Your question is a bit vague. Rather than try to answer it, I'll answer two related questions.
What is the purpose of a namespace?
The primary purpose of a namespace is to organize type declarations into a hierarchy so that they can be found by users easily.
The secondary purpose of a namespace is to provide a mechanism for disambiguating name collisions. That is, if XYZ Corp has a type Vehicle and ABC Inc has a type Vehicle, and PQR Ltd wants to use code from XYZ and ABC at the same time, the PQR programmers need a way to tell the compiler which type "Vehicle" actually refers to.
You suggest naming your namespace "Factory". That's probably a bad idea. A factory is probably a class, not a namespace. A factory is a kind of thing, not a way of organizing things. I would be inclined to name my namespace "Dementic.Manufacturing" and have it contain a Factory class. Now things are organized in two ways: first, by the company, Dementic Incorporated, that is producing the code, and by what the code is related to, namely, manufacturing. And it is unlikely that any competitor of yours will also make a namespace called Dementic.Manufacturing.
When should I make a nested type as opposed to a top-level type?
Make a nested type when the nested type is an implementation detail of the outer type. It is generally considered a poor practice to make a public nested type, though it is occasionally done.
A common example is an enumerator class; it is usually a private implementation detail of a enumerable collection.

You could stick all these in your Factory namespace.
A vehicle class would contain shared components, and classes for your specific vehicle types would inherit from the vehicle class... is that what you're asking?
public class Engine
{
public int HorsePower {get;set;}
}
public class Vehicle
{
public Vehicle() { }
public Engine Engine;
public int Doors;
}
public class Airplane : Vehicle
{
public Airplane () { }
public string PropellerModel;
}
public class Boat : Vehicle
{
public Boat () { }
public string RudderModel;
}

If you want to be as generic as possible, you can approach it something like this:
namespace Factory
{
public interface IDoor { }
public interface IEngine { }
public interface IPropeller { }
public abstract class Vehicle
{
public ICollection<IDoor> Doors { get; protected set; }
public ICollection<IEngine> Engines { get; protected set; }
}
public class Airplane : Vehicle
{
public ICollection<IPropeller> Propellers { get; protected set; }
}
}
Then have the specific concrete types provide the relevant collections to the supertype properties.
This is a bit of a hack, but modeling any real-world objects as classes in a programming language is going to break down sooner or later.
Note that I've made the engine property a collection too. This is to support, for example, the Prius class, which would have two engines.
An alternate approach would be to define the vehicles in terms of interfaces, somewhat like this:
namespace Factory
{
public interface IDoor { }
public interface IEngine { }
public interface IPropeller { }
public interface IDoorProvider
{
ICollection<IDoor> Doors { get; }
}
public interface IEngineProvider
{
ICollection<IEngine> Engines { get; }
}
public interface IPropellerProvider
{
ICollection<IPropeller> Propellers { get; }
}
public abstract class Vehicle { }
public class Car : Vehicle, IDoorProvider, IEngineProvider
{
public ICollection<IDoor> Doors { get; protected set; }
public ICollection<IEngine> Engines { get; protected set; }
}
// And so on...
}
This approach has the advantage that you don't have to define much on Vehicle itself, but this also means that you can't easily share the definitions of these members across all of the classes. However, this prevents you from defining members on the base type that are not relevant to the concrete types.

You have the wrong concept of what namespaces are. Namespaces have nothing to do with this.
I think you're also confusing inheritance and factories. Again, those are very separate ideas.
First think about creating your class heirarchy with the common base class that provides the basic structure of your objects and then the specialized subclasses that provide the specific details. And be careful not to use inheritance unless it truly works. Don't force your model into an inheritance heirarchy if it doesn't make sense.
Then you can worry about creating one or more factories to create instances of these objects.
As for namespaces, a namespace is just a way to group related pieces of code together in a logical, meaningful way. You might have a factory namespace, but you could just as well have a "factories" namespace or a "vehicles" namespace or something completely different which is relevant to your domain.

Since the person asking the question might actually get some value out of it, here my take:
If your software deals in some ways with objects of the real world, don't try to model the set of classes that represent the core of your application according to the real world. Rather, let the requirements of the software guide as to how your objects will look like.
For example, is this an order management system?
In that case it may be more relevant that certain orderable items have other orderable items directly associated with it. For a boat you can order certain parts, engines, etc. That is, it may more important to express the relationships between orderable items instead of having them available as concrete types.
For example, is it a tool to draw new boats, planes, propellers, etc.? Then a more relevant base class maybe that of a shape. Is it more about calculating the power of an engine or the efficiency of a propeller? Then you may need some concept of mathematical bodies and additional physical relationships and characteristics need to be defined between the different objects.
Lastly, as a rule of thumb you can think of inheritance as a somewhat overrated concept in that it is the first thing that starters think of when touching OO. The predominant concept of reuse in nature is composition - ultimately all natural things are composed of small items with very clear interfaces. Ideally, you will try and compose your OO application in a similar fashion.

I would rather go for VehicleFactory namespace, Factory as a class (there are many design patterns addresing the problem of creating objects and usually this needs to be a class, or at least (usually in non-objective programming) function. Namespace won't provide you this.