This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hi Manas, Abstarct classes are meant for 'abstracting'. means if some classes are having common behaviour, instead of writing evry time the same thing in each class, write that in one class and ask the other classes to use it[by making the classes as subclasses to the abstract class]. this is nothing but inheritance. To summarise: Use abstract classes when you want default behaviour for some classes Use interfaces when you want different behaviour different classes.
Functionality: likely to be different in all parts: Interface.
Data, and functionality, parts will be mostly the same, parts different: abstract class.
Data, and functionality: actually working, if extended only with slight changes: ordinary (concrete) class
Data and functionality, no changes planned: ordinary (concrete) class with final modifier.
Data, and maybe functionality: read-only: enum members.
Remember this is very rough and ready and not at all strictly defined, but there is a spectrum from interfaces where everything is intended to be changed to enums where everything is fixed a bit like a read-only file.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com