We Keep Coding

Why using an Interface, what is wrong with classes and inheritance

I know that this question might be asked for many times in this website. I have read the other posts and read some books about why we have to use interfaces. All those posts and books say that, interfaces are like classes but they can only contain functions and all the classes that implement them should also implement their methods.
So I basically know what they are but I don't understand why should I write an interface at all, when I can make a superclass and extend the my other classes to that superclass without rewriting inherited functions again and again.
I would really appreciate if someone explains that to me please.

The key point of using interfaces is to create loosely coupled types. This is because interfaces are completely abstract and each class that implements them should have its own particular implementation of the interface’s methods.
If you create a base class instead of an interface, all the derived classes are tightly coupled with the base class. In particular situations, this tight coupling can cause some problems. The simplest and the most digestible problem that this tight coupling can cause is to create statically bound behaviors which can limit the code to a particular context. On the other hand loosely coupled types are dynamically bound which means they are more general and more reusable.
For example: imagine that you have one class named Service and another named Customer, if you do:
class Service {
public void RenderService() {…}
…
}
class Customer: Service {
public Customer () {…}
…
}
The Customer class in this example in tightly coupled with the Service class. Imagine if we want to introduce a new Service called Service2. Now, our Customer class will become useless and we need to also introduce another class like Customer2.
Now imagine the use of an interface:
interface IService {
void RenderService();
}
class Service: IService {
public void RenderService() {…}
}
class Customer {
IService service;
public Customer(IService service) {
this.service = service;
}
}
Using this technique (also known as Dependency Injection) you can introduce Service2 by creating another class which also implements the IService interface and still keep your Customer class useful and prevent the need to rewrite it.
Apart from this, there are other reasons to use interfaces such creating highly general (i.e. polymorphic) types or methods. So, as a conclusion, there’s a huge difference between simply writing classes and using inheritance and introducing an interface to your code. I hope I could help you digest the use of interfaces.

Interface implementation and common function

I have the following requirement,
There will be 2(or more) different classes to perform same kind of operation(in different ways). Therefore I decided to create an interface. Then I implemented these 2 classes with my interface.
Now, from another class I will be using the object of type Interface and calls functions. Everything works fine.
Then a new requirement came to create a common functionality that applies to both classes.
I don't want to define same function in both classes. And interface dont allows function definition.
First I thought abstract class will be useful. Because it allows function definition and abstract functions. But abstract classes cant be instantiated and also I need to create objects with individual class types.
Sorry I cant find a simple way to define my problem. It feels like a solution that spring framework provides. But I need to know how to acheive this from a Java/C# application.

It sounds like you want an abstract class implementing the common functionality, but still have two concrete classes for the distinct functionality. You may or may not still want to keep the interface as well. So the options are:
Interface
^
|
Abstract
class
^
/ \
Concrete Concrete
class 1 class 2
or just
Abstract
class
^
/ \
Concrete Concrete
class 1 class 2
Code which wants to use these classes just uses the interface or abstract class. How you configure which concrete class to use were will depend on your exact requirements - but presumably you'd already tackled that in the earlier version.

A common pattern for this is:
Define the interface (as you've done).
Create an abstract class which implements the common functionality in terms of the non-common functionality.
Extend this abstract class to provide the non-common functionality.
A lot of JDK classes do this. For instance, the List<T> interface has an AbstractList<T> abstract class, which is extended to provide both ArrayList<T> and LinkedList<T>.
A simple (if contrived) example would be something like:
interface IntThingy {
int getValue();
int getDoubeValue();
}
abstract class AbstractIntThingy implements IntThingy {
#Override
public int getDoubleValue() {
return getValue() * 2;
}
}
class ConstantFourtyTwo extends AbstractIntThingy {
#Override
public int getValue() {
return 42;
}
}
class ConstantIntThingy extends AbstractIntThingy {
private final int value;
ConstantIntThingy(int value) {
this.value = value;
}
#Override
public int getValue() {
return value;
}
}
Note that once Java 8 arrives, you'll be able to define methods in interfaces. These are commonly known as "defender methods." When that happens, you may not need the abstract class -- depending on whether that common functionality needs to maintain its own state (interfaces still won't be able to define instance state). But for now, the interface-abstract-concrete pattern often works well.

You can try to avoid using simple interface and use strategy pattern:
http://en.wikipedia.org/wiki/Strategy_pattern

Create a concrete class (or better abstract class) that implements your interface, and contains your "common functionality", Now you can extend this class (Hierarchy) with two (or more) classes.
there are many more ways of designing this requirement.
And I am not sure If mine is best either.

Just to add on to Jon Skeet's answer, you need to think as to what kind of relationship your classes have with the interface or the intended abstract class. If the relationship is between the behaviour laid out in the interface is has-a then the interface is the right choice, and if it is an is-a relationship, you can go with an abstract class.
In another scenario, you can also check if the relationship is has-a, and the new common functionality that you want to implement is an is-a relationship, then apart from option by Jon, you can use something like this:
Abstract
class
^
/ \
Interface Interface
\ /
Concrete Concrete
class 1 class 2
for e.g.:
interface IParent{}
abstract class Parent{}
class Child1: Parent, IParent{}
class Child2: Parent, IParent{}
It all depends how you design your classes for future use.

How to create method interface with variable parameters / different method signatures?

I'm trying to create an interface to a common class, but the implementation classes can have different parameters.
e.g.
public interface IViewModel
{
//...
void ResetReferences();
}
// and then, in my class implementations, something like this:
public class LocationViewModel : IViewModel
{
public void ResetReferences(List<StateProvinces> stateProvinces) //...
}
public class ProductViewModel : IViewModel
{
public void ResetReferences(List<Color> colors, List<Size> sizes) //...
}
So notice that I want to standardize on the ResetReferences naming convention. I'm pretty sure I can't do this, but is there a design pattern that could work? e.g. in my interface, something like below?
// variable parameters
void ResetReferences(params object[] list);
But then how do I make I do type checking or having it call the actual method signature that I want, etc?
Maybe an interface is the wrong thing to use? Maybe just a base class and some coding conventions?
Thanks,

Replace your args lists with objects that implement a related interface:
public interface IViewModel
{
//...
void ResetReferences(IResetValues vals);
}
I should add that, IMO, ResetReferences() should not take an argument... it should reset to some default value that would be specific to the individual type(s) that implement your interface..."Reset" being the word that means, to me, "restore to initial state"...adding args implies that you can control that.

The purpose of an interface is to have client code know about the interface and be oblivious of the implementation. If your implementations require special treatment when called, the client code need to know what implementation it is calling and then the whole purpose of the interface is lost.
Unless I misunderstand totally what you're trying to accomplish, you're down the wrong road.

If the parameters can be different, then it isn't really a common interface. Put it this way: does the caller need to know the implementation class? If so, you've lost the loose coupling benefits of interfaces.
One option is to encapsulate the parameters into another type, and make the class generic on that type. For example:
public interface IViewModel<T>
{
void ResetReferences(T data);
}
Then you'd encapsulate the List<Color> colors, List<Size> sizes into one type, and possibly put List<StateProvinces> stateProvinces in another.
It's somewhat awkward though...

You will need to implement the interface method, but you can still do what you want
public class LocationViewModel : IViewModel
{
public void ResetReferences(List<StateProvinces> stateProvinces) // ...
void IViewModel.ResetReferences() // ...
}

You would have to have both methods in the interface (and have the one not correct for an instance throw a non-supported exception), or have the interface inherit from two other interfaces to the same effect.
An interface definition is the entire signature.
It may also be possible to pass an object as a parameter (perhaps derived from a ParameterProvider base class) so that the object encapsulates the dynamic nature and still allows the interface to be static. But that that point you're basically working around the type system anyway.

I think I missed something on the "Programming to an interface" concept

So I am still very new to C# and using interfaces, and when I thought I understood them I realized I don't completely. The confusion I have found that I am seeking some clarification here for is, when you create an interface, and have a class inherit from it
public Interface ISomeInterface
{
//some methods/properties
}
public class FooClass : ISomeInterface
{
//implemented ISomeInterfaces methods/properties
}
And you use this class object in an implementation somewhere in your program
public class BarClass
{
private ISomeInterface _someInterface;
public BarClass(ISomeInterface someInterface)
{
_someInterface = someInterface;
}
//rest of class
}
My confusion is why do I see it setup this way. I thought that I would have instantiated a new object of type FooClass, as well as used an object of type FooClass in the constructor as such:
public class BarClass
{
private FooClass _fooClass;
public BarClass(FooClass fooClass)
{
_fooClass = fooClass;
}
//rest of class
}
What am I missing to understanding this? I didn't think I would directly be declaring objects of an Interface?
Thanks in advance.

The idea is that BarClass should not be tightly coupled to a specific implementation of ISomeInterface.
If you use this:
public BarClass(FooClass fooClass)
it means that the BarClass can work only with this specific FooClass implementation and nothing else. Whereas if you use:
public BarClass(ISomeInterface fooClass)
now the BarClass is no longer tightly coupled to FooClass. This means that the consumer of the BarClass can now pass any implementation of the interface he wants as long as it respects the defined contract (interface). So if he wants FooClass he passes an instance of FooClass, but if he is not satisfied with FooClass he can write his own implementation and pass it to the constructor and from the point of view of the BarClass this is absolutely transparent (it doesn't need to be modified).
The weak coupling between your classes is one of the most fundamental aspects of OOP as it allows you to easily replace one component with another without having to rewrite your entire application.

Suppose FooClass wrote something to a database. You'd like to test BarClass without having to actually set up a database. If you created a different TestFoo that implemented the same interface, you could pretend to be the database and more easily test your class; BarClass wouldn't have to know that it wasn't talking to the 'real' FooClass.

Do you have a C/C++ background? Then you should be aware that
private ISomeInterface _someInterface;
would be written as
private:
ISomeInterface& _someInterface;
In C++ (assuming you have an abstract base class called ISomeInterface).
This means you are storing a reference to an object implementing ISomeInterface not such an object itself. The advantage of this is that you can pass ANY object to BarClass that implements ISomeInterface which gives you more flexibility, e.g. for unit testing.

By using the interface definition instead of the concrete implementation, your code is now more loosely coupled. This technique is used in dependency injection.
In addition, this comes in handy when you need to need to implement FooClass differently. If you used the concrete implementation, you will need to make code changes where ever you have declared FooClass. Programming against the interface shields you from the effects of such changes.

One of the main benefit to program to ISomeInterface instead of FooClass, is that you might probably change your implementation of FooClass. For example, consider a database driven blog application:
interface IBlogStorage{
getPosts();
}
you then have a class like:
class XMLBlogSotrage: IBlogStorage{}
and suppose you implement everything to the interface. later on, you think XML is too slow and you want to use RDBMS, then:
class MsSQLBlogStorage:IBlogStorage{}
In this case, you don't need to change anything in other codes, you just need to create a new class and plug it in! Those already existed codes, doesn't need to bother where is the storage.

Another way of thinking about the interplay between interfaces and classes is to flip them upside down. That means to start with classes first. Let's say you have several classes that expose a method called "Sort()". Then you have another class that has a method that requires references to these classes and in turn calls their "Sort()" methods. Instead of having several methods with different parameters, you can create and attach an interface to those classes (very quick fix as these classes already contain the implementation).
A.Sort()
B.Sort()
C.Sort()
interface ISortable {void Sort();}
A : ISortable
B : ISortable
C : ISortable
D.SortSomething(ISortable foo)
{
foo.Sort()
}
Maybe this is too abstract. My favorite use of interfaces is enabling my classes to participate in foreach loops.
class SomeCollection : IEnumerable
{
List<SomeItem> _items = new List<SomeItem>();
// This is the only code I need to enable this class to participate in foreach loop.
public Enumerator GetEnumerator()
{
return _items.GetEnumerator();
}
}
Once you discover how interfaces can simplify your codes, you can even begin creating interfaces before writing your classes.

Abstract classes vs Interfaces

I'm a bit confused about the usage of Abstract classes in C#. In C++, it makes sense to define a template which classes inheriting the abstract class can follow. But, in C# doesn't Interface serve the same purpose?
True that abstract classes can have default implementation which is not provided by Interfaces. So if implementation doesn't need to be included in base class, is it better to go for Interfaces?

I still like to provide a default abstract implementation of an interface, assuming it's a substantial interface (and it makes sense). You never know when you might add something to the interface that has an easy default implementation that could be included and given "for free" to anyone who inherits from the abstract base class.

This CodeProject article has a lot of information on the difference between the two including a table comparing and contrasting the features of each.
Interfaces define the contract between classes - the ways classes call each other. A class can implement multiple interfaces, but can only inherit from one abstract class.

True that abstract classes can have default implementation which is not provided by Interfaces. So if implementation doesn't need to be included in base class, is it better to go for Interfaces?
Yes :). If it makes sense to implement some methods in the base class which will be common to all inhereted class you should use an abstract class. If the base class would only be used to define an interface but there is no common logic between the inherited classes, use an interface.

Interfaces and abstract classes serve different goals. Interfaces are used to declare contracts for classes while abstract classes are used to share a common implementation.
If you only use abstract classes, your classes cannot inherit from other classes because C# does not support multiple inheritance. If you only use interfaces, your classes cannot share common code.
public interface IFoo
{
void Bar();
}
public abstract class FooBase : IFoo
{
public abstract void Bar()
{
// Do some stuff usually required for IFoo.
}
}
Now we can use the interface and base implementation in various situations.
public class FooOne : FooBase
{
public override void Bar()
{
base.Bar(); // Use base implementation.
// Do specialized stuff.
}
}
public class FooTwo : FooBase
{
public override void Bar()
{
// Do other specialized stuff.
base.Bar(); // Use base implementation.
// Do more specialized stuff.
}
}
// This class cannot use the base implementation from FooBase because
// of inheriting from OtherClass but it can still implement IFoo.
public class FooThree : OtherClass, IFoo
{
public virtual void Bar()
{
// Do stuff.
}
}

For your first question, Yes.
For your second answer i'll give you some tips I've followed.
Use abstract classes and interfaces in combination to optimize your design trade-offs.
Use an abstract class
When creating a class library which will be widely distributed or reused—especially to clients, use an abstract class in preference to an interface; because, it simplifies versioning.
Use an abstract class to define a common base class for a family of types.
Use an abstract class to provide default behavior.
Subclass only a base class in a hierarchy to which the class logically belongs.
Use an interface
When creating a standalone project which can be changed at will, use an interface in preference to an abstract class; because, it offers more design flexibility.
Use interfaces to introduce polymorphic behavior without subclassing and to model multiple inheritance—allowing a specific type to support numerous behaviors.
Use an interface to design a polymorphic hierarchy for value types.
Use an interface when an immutable contract is really intended.
A well-designed interface defines a very specific range of functionality. Split up interfaces that contain unrelated functionality.

You can implement any number of Interfaces, but can only inherit one Class. So Classes and Interfaces are quite different beasts in C# and you cannot use them interchangeably. In C# abstract classes are still classes, not interfaces.

If you don't have any default/common code, then go with an interface.
An abstract class can also serve as a template, where it defines the steps of some algorithm and the order in which they are called, and derived classes provide the implementation of these steps:
public abstract class Processor
{
// this is the only public method
// implements the order of the separate steps
public void Process()
{
Step1();
Step2();
//...
}
// implementation is provided by derived classes
protected abstract void Step1();
protected abstract void Step2();
}

Whilst it's true that an abstract class with no implementation is equivalent to an interface, interfaces and abstract classes are used for different things.
Interfaces can be used for polymorphism in the most general sense. For example, ICollection is used to define the interface for all collections (there are quite a few). Here it is defining the operations that you want to perform on a certain kind of type. There are many other uses (such as testability, dependency injection etc). Also, interfaces can be mixed and this works both conceptually and technically.
Abstract classes are more to do with templateable behaviour, where virtual methods are a place to 'fill in the gaps'. Obviously you can't mix abstract classes (at least, not in C#).

In C# a large deterrent for the use of abstract classes is that you can only use one. With interfaces you have the advantage of not limiting the base class for the implementation. To this end, I always use an interface even if I create an abstract base class to aid with the implementation.
Often another annoyance of base abstract classes is that they tend to rely on template arguments. This can make it very difficult for the rest of your code to utilize. The easy answer for this is to provide an interface to talk to the abstract class without knowing the type argument of the template class.
Others seem to be typing their answer faster, but allow me to summarize...
Use an interface. If you need to share implementation, you can also create an abstract base class that provides common implementation details.

Note that with C#3, you can provide default behavior for interfaces through the use of extension methods. There are some limitations, though, and abstract classes still have their place.

The rule I follow when modeling is:
Classes(abstract included) and structs model entities.Interfaces model behavior.
Entities implementing an interface can be considered as exhibiting behaviors that the interface(contract) exposes.

This is hinted at in a few of the answers but not explicitly stated.
The fact that you can implement multiple interfaces and only inherit from one base class, as if they were two sides of the same coin, isn't a good way to look at it.
Don't think of interfaces as part of an object hierarchy. They are usually just small parts of functionality (or at least specific if not small) that your real object heirarchy can declare as implementing. Take IDisposable for instance. If you were the one writing that, would you ask yourself whether it should have been an abstract class or an interface? It seems obvious that in this case they are two completely different things. I want to BE disposable. Think ICloneable and IEnumerable. You can implement those in your class without having to try and make your class derive from some unrelated classes like List or Array. Or take IEnumerator. Simply gives a MoveNext type of view to an object. My class can provide that functionality without having to awkwardly be derived from some other sequential collection data type that has nothing to do with my class.

I always prefer interfaces as long as the base class don't have some really "heavy duty" implementation that will save lots of time to the implementers.
giving that .net allows only one base class inheritance, forcing your users to inherit is a huge limitation.

You should always prefer programming to interfaces than to concrete classes.
If you also want to have a default implementation you can still create a base class which implements your interface(s).