Being dependent on the implementation in one place (at construction) is better than being dependent on the implementation in N places (each place the class is used), so it's an improvement.
1) Makes testing a whole lot easier since can easily create mock / fake implementionsi agree
2) Makes code easier to read / understand
3) If user wants to create their own implementation of the interface they can. If it's a concrete class they'd have to extend that class. That may not be possible or desirable.
"timfox" wrote:
I have just committed a refactoring to our new package structure.
Here is how it goes:
org.jboss.messaging.core and sub packages.
Contain the messaging core - this is all the stuff needed to make a fully functioning transactional, reliable messaging system.
...
server - the core server interfaces and implementation
...
client - this contains the core client interfaces and implementation
"jmesnil" wrote:
I'm thinking mainly about the Message interface (and also the Version interface, anything else?).
I find weird in client code to instantiate an object from server.impl package.
2) Deployers. Currently abstract class Deployer is exported from the module. This should be an interface. Also DeploymentManager should be an interface. We should also avoid singletons throughput JBM, this is to allow multiple JBM instances to co-exist in the same VM without interacting.