Which one you normally go for it, Interface or Abstract Class?

10. June 2010 15:13 by Eric in .net  //   Comments (0)

I just came across a blog about "Classic confusion - Interface vs Abstract Class" this morning, which quite relates to the sales reporting application project I'm currently leading on at the moment.

The current major issue I'm facing with massive is re-factoring on a fortnightly basis due to the constant requirement amendments from the client, which leads to the large amount time wasting for updating underlying logic to catch up weekly release.

The biggest headache is that those interfaces I designed in the beginning need to be updated along the way, which causes issues & time to update all implementation for corresponding logic, otherwise the other reports will just simply fall apart.

What a headache! However, I never even asked myself once about why not just leveraging Abstract class over Interface for this application design. That's because "Interface defines just the "syntax" of how an object can be communicated, abstract classes defines the "semantics" ", in other words, updating interfaces for new requirement will cause consequences to update the all existing implementations, while abstract class really offers "extended features" to new implementations and remains the same for the old implementation. By utilizing that approach in my context, at least I don't need to go through that tedious refactoring period all over again as a fortnightly-basis.

I guess, in a nutshell, what I'm trying to emphasize here is that when we design an application in the very beginning, we need to be quite careful about how to define and identify abstraction layer of the application in terms of extensibility, manageability and re-usability, in order to avoid another maintenance disaster project for fellow programmers. (Anyway, we learn from the mistakes, we get stronger from them!)