i was asked this question once, and resented it. its for a college kid just out of CS101, not proven professionals. unless you are a coder of advanced gaming and/or AI systems you BETTER NOT be spending so much time contemplating interface VS abstract. if i was your boss i would NOT be happy.

i am willing to bet most if you are web developers for backoffice business process automation systems and NOTHING more advanced than that. to feel the need to use such advanced OO concepts is overkill and over-coding. just make sure you follow good agile patterns, proper namespacing and standards, and enforce it accross the team, and you will have successful projects.

Here is the basic problem with asking the question as written on this site. IT IS LANGUAGE SPECIFIC. The “concept” of abstract versus interface is different depending on the language you are using. A good CS Programming Languages course will make you appreciate that. This question is very theoretical. For example in C++ the distinction is very minimal and very context oriented–in C++ an “interface” is an abstract class which provides no implementation, has no members, and no constructor. But to Anil’s point, what if I had a class with 1000 members on it. I could code an abstract class with default implementations and use that–in C++ this can still be used effectively as an interface. There are some other subtle complexities with interfaces and template design in C++, but I won’t go into that here.

However, move to C#. The same is not true. Why? Because in C# the langauge only supports single inheritance, thus if you use an abstract base then you cannot offer any more interfaces–or rather you are stuck with a fat interface. Since fat interfaces (i.e. putting all service methods into one class) is generally not a good practice we would like to separate out our interfaces based on the services they provide–the only way to do this in C# is through an interface. (A class can only extend a single base class whereas it can implement multiple interfaces; contrast to C++ a class can implement many base classes).

Thus the answer to your question is “it depends.” What are our use cases? What is our language we are coding in? What runtime dependencies do the syntactical constructs impose? What is the design goal behind class abstraction? based on these considerations, then I could answer why I would use one versus the other. In my experience most developers can’t properly code an interface without suffering from some unexpected coupling issues.

Choosing to use an interface as a design construct should be a well thought out and thorough examination of how the code/class will behave.

Go for interface when u need programmers working on just the defination part where method name’s and arguments will stay the same .Thus that will maintain the naming conventions.

Put methods in abstract class if defination is pretty much known.

I’d throw the question back: Gosling claimed to have omitted MI for simplicity, but is that for the language user, or for the compiler writer? Issues like this suggest that it’s merely the latter. OCaml programmers don’t spend any time sitting around discussing this, and they don’t seem to be hurting for productivity or type-safety or performance or anything else except possibly marketing budget.

I have been a professional for 30 Years, I have even taught Advanced Object Orentation and I dre the paverbial BLANK!
I tend to agree with Pratik but one can not be a Smart Axx in an interview!

I am agree with Partik.I have face such kind of situation,where interviewer ask these question and when you explain they don’t agree on that because they have feeling like they are taking interview.