Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Replies:
8 -
Pages:
1
Domain Classes or Interfaces?
URL: Domain Classes or Interfaces?
At 4:43 PM on Oct 31, 2006, Matthew Schmidt wrote:
Fresh Jobs for Developers Post a job opportunity
All in all, I think it’s an interesting approach. He does mention that abstract classes aren’t always the best choice. For example, he uses interfaces for service layers where you’re likely to have different implementations or need easy mocking for testing. What are your thoughts? Do you prefer to use abstract classes where you can constrain the data that comes in more easily or do you prefer interfaces all the time? Let me know what you think.
Read "Domain Classes or Interfaces?"
8 replies so far (
Post your own)
Re: Domain Classes or Interfaces?
Is there a reason the use of one precludes the use of the other? They were designed for entirely different purposes afterall...But it's ok. I'm sure I'll see another 100 postings (in addition to the dozen or so I've already seen) on this issue in the blogosphere before people figure it out.
Re: Domain Classes or Interfaces?
Do as it has been done in the JDK. Provide interfaces for the people that know what they are doing and provide abstract classes for the ones that would rather implement their logic via hooks.Re: Domain Classes or Interfaces?
Abstract base classes are less work, but you'll need interfaces if you have different implementations that can't share the base class.Interfaces are often misused or misunderstood rather, and give the user a false sense of "wrapping everything up in a neat little package(s)", while not really necessarily achieving a good OOP structure, just because.
If you want to leave things open, and allow for future clean implementations, then interfaces are definitely needed, which is why, I guess, I tend to (over)use interfaces, but I might rethink my tactics a bit.
I've been coding and recoding my hierarchy hacks although I seem to keeping using interfaces, I'm finding that often everything is always deriving from that one base class, so the 'interface' thing isn't really doing anything for the OOP neatness. Just more files to deal with.
Interfaces also help with the obfuscation process, where you can have the obfuscator bypass certain interfaces you wish to publish. But I think that annotations might be better for that.
Re: Domain Classes or Interfaces?
In my view, abstract classes are intended for providing convenience that should implement some interface. They may be used by developers who wish to provide an implementation of the interface.Dependencies in a public API should always be specified in terms of an interface. Of course that does not prevent you from providing a sensible default implementation in the form of an abstract class. However, you should consider that complex class hierarchies are strongly correlated with poor maintainability, flexibility and understandability. In other words, if a lot of crucial framework functionality ends up in abstract classes (i.e. it is more than just a bit of convenience) you might want to consider refactoring your inheritance relations to delegation relations. This will allow you to provide framework functionality in final implementation classes and makes it much more explicit what the responsibilities of the framework are and what the responsibilities of the framework consumer are.
Personally I consider more or less mandatory use of complicated abstract classes to be a code smell. In fact I find I rarely need them and almost never create them myself. There are many standard java APIs with more or less mandatory abstract classes (e.g. swing) and all of those have complexity issues.
A major problem with abstract classes is that Java has single inheritance. So if you are trying to combine frameworks that require you to extend abstract classes, that tends to complicate things a bit if you also want to inherit from a different class. This typically becomes a problem when combining different libraries that were not designed explicitly to be used together.
Future inclusion of closures in Java will remove most (if not all) of the need for abstract classes. If you think about it, abstract classes are just a primitive way of parametrizing classes with functionality. Closures are a much cleaner and explicit construct.
Re: Domain Classes or Interfaces?
This is an excellent response and I will be referring people at work to it.One point that I would add is that interfaces make it much easier to create unit tests. I have just joined a team that produces a library full of concrete classes and almost no interfaces. Our customers have specifically complained because they can't mock out any of our library types. If they were interfaces then a mock utility would be able to very easily mock out compatible types with defined, local behaviour.
Re: Domain Classes or Interfaces?
The blog post clearly encourages usage of abstract classes (instead of pure Java interfaces) *only* for domain abstractions which are rich in behavior and need to honor many constraints (pre-conditions/post-conditions/invariants etc.). Pure Java interfaces do not offer a way of expressing contraints or invariants. For spis and other service layer apis or abstractions requiring multiple inheritance / mixins, pure interfaces are a definite choice. And regarding mocking and testability, classes can also be mocked using EasyMock, although I am not very sure if domain abstractions can be tested effectively using mocking.Cheers.
Re: Domain Classes or Interfaces?
Let's not mix things different by nature. In abstract classes you can provide algorithm implementations which you cannot do in interfaces. At the same time you can implement multiple interfaces masking necessary parts of functionality. Components should only be known by their interfaces - not by abstract classes!Re: Domain Classes or Interfaces?
I think they are designed for different purposes.