Jan 12th, 2011, 05:09 PM
interface vs. abstract class for services and daos
I seem to remember thinking at one point in time that interfaces were the way to go because I ran into some problem with making one of my services (or dao...I can't remember) an abstract class, but I can't remember why. What are the pros and cons of each? I am guessing I would use an abstract class when there is a lot of shared code between the different implementing services. I just want a clearer understanding of when to use one verses the other.
Jan 13th, 2011, 04:52 AM
I personally always recommend programming to interfaces. That is the best way to achieve loosest coupling between application components and it's also the natural way to go when using dependency injection to its fullest power.
Abstract classes are there to model real hierarchy between business entities (for example a USDollar object and a Euro object both extend the abstract class Currency) but I don't see their usage for classes that are statless and offer services like daos, business layer services, controllers etc.
Jan 13th, 2011, 10:37 AM
Thanks for the response. Lets say you had a ReportService that created reports from an xml file. I could see making the ReportService as an abstract class with two child classes that extend it (ie XSLReportService and JavaReportService). That way if the two services shared some functionality (ie XML utility methods) the could be located in the parent class instead of having the same code in each service. Does that make sense? Again I am just trying to understand the pros and cons, so I may be missing something. Thank for your input. What are your thoughts on something like the above case.
Jan 13th, 2011, 11:08 AM
The problem with the approach of your example is that by using the abstract class with shared xml functionality, and by making all your services childs of that class, you tie your services to a particular type of reports, based on xml source. Say you introduced a third kind of report that takes data from database and not from xml (JasperReports is an example)...in that case all your xml functionality would be useless, so probably you won't make this third report service class a child of the abstract class, this introduces diversification which in turn means chaos bits.
In my opinion the power of an interface is that it describes WHAT a service does without implying or suggesting in any way, not even a little bit, HOW that service should be implemented. This aids the developer in 3 ways: it guides him in clarifying business needs BEFORE getting down to code, it makes refactoring/ switching of technology easier, it makes maintenance/testing easier. Not counting the dependency injection is "born to be interface". In my career as a developer I've come to find it invaluable.
Obviously that's just my personal opinion, my two cents.
Jan 13th, 2011, 11:12 AM
Great thoughts. Thank you.
Jan 13th, 2011, 01:22 PM
It's worth mentioning that this isn't necessarily an either-or equation. For example, given the use case you described (two XML-based reporting services), I probably would still use an abstract class to catch any commonality, but inject a common interface.
That said, I agree with Enrico in the core - injection is usually best done with interfaces, and abstract classes are more of an implementation detail.
Hope this helps
Tags for this Thread