Possible Duplicate:
Interface vs Abstract Class (general OO)

I can see their advantage in coordination of a developing team, or code that might be further developed by others.

But if not, is there a reason to use them at all? What would happen if I omit them?

Abstract – I'll be able to instantiate it. No problem. If it doesn't make sense – I won't.

Interface – I have that functionality declared in all classes deriving from it anyway.

Note: I'm not asking what they are. I'm asking whether they're helpful for anything but coordination.

• c#
• interface
• abstract-class

I think if you're not coordinating with others, it does two things

1. helps keep your from doing weird things to your own code. Imagine your write a class, and use it in multiple projects. You may evolve it in one project so that it is unrecognizable from it's cousin in another project. Having an abstract class or interface makes you think twice about changing the function signatures.
2. it gives you flexibility going forward - plenty of classic examples here. Use the generic form of the thing you're trying to accomplish, and if you decide you need a different kind later (streamreaders are a great example, right?) you can more easily implement it later.

Both are what I call contracts and can be used in the following fashion by an individual developer:

Abstract

• Allows for polymophism of differing derived implementations.
• Allows one to create base functionality which can be dictated or not that the derived class be required to implement.
• Allows for a default operation to be runtime consumed if the derived does not implement or required to implement.
• Provides a consistency across derived objects which a base class pointer can utilize without having to have the actual derived; hence allows generic operations on a derived object from a base class reference similar to an Interface in runtime operation.

Interface

• Allows a generic pattern of usage as a defacto contract of operation(s). This usage is can be targetted to the process in hand and allows for the surgically precise operations for that contract.
• Used to help with factory patterns (its the object returned), mocking of data during unit tests and the ability to replace an existing class (say from a factory returning the interface) with a different object and it doesn't cause any consumer of the factory any pain of refactoring due to the adherence of the interface contract.
• Provides a pattern of usage which can be easily understood away from the static of the rest of the class's implementation.

Long story short are they required to get a job done? No.

But if you are into designing systems which will have a lifespan of more than one cycle, the upfront work by said architect will pay off in the long run whether on a team or by an individual.

++Update

I do practice what I preach and when handing off a project to other developers it was nice to say

1. Look at the interface IProcess which all the primary business classes adhere to. That process defines a system of goals which can help you understand the purpose and the execution of the business logic in a defined way.
2. While maintaining and adding new functionality to the project the interfaces actually helped me remember the flow and easily add new business logic into the project.

Abstract - you can instantiate a child of it, but what is more important, it can has its own non abstract methods and fields.

Interface - more "rough" one in regard of abstract, but in .NET you can have multiple inheritance. So by defining interface you can lead consumer of your interface(s) to subscribe to different contracts(interfaces), so present different "shapes" of specified type.

There are many reasons to use either construct even if you are not coordinating with anyone. The main use is that both actually help express the developper intent, which may help you later figure out why you choose the design you actually chose. They also may allow for further extensibility.

Abstract class allow you to define one common implementation that will be shared across many derived classes while delegating some of the behavior to the child classes. It allows the DRY (don't repeat yourself) principle to avoid having the same code repeated everywhere.

Interfaces expresses that your class implements one specific contract. This has a very useful uses within the framework, among which:

• Use of library functionality that necessitate the implementation of some Interface. Examples are IDisposable, IEquatable, IEnumerable...

• Use of constraints in generics.

• Allow mocking of interfaces (if you do unit testing) whithout having to instanciate a real object.

• Use of COM objects