Persistence contract design: Single generic interface vs. Several specialized interfaces

Question

I'm working on a base library intended to provide common interfaces to a large application which is intended to support several DBMS (Oracle, SQLServer, MySQL, PostgreSQL, etc). Additionaly a concrete class may use JDBC or JPA to interact with the DBMS.

I want to provide a contract with basic persistence operations involving domain (model) classes so I've made this interface using generics:

public interface IDomainDAO<T> {

    public int insert(T domainObject);

    public int update(T domainObject);

    public int delete(T domainObject);

    public List<T> getList(IQueryFilter queryFilter);
}

Note: IQueryFilter is not relevant to my problem.

I'm trying to decide if I should provide more specialized interfaces so concrete classes can implement those ones instead of IDomainDAO, or doing so is just a waste of time. For instance:

public interface IUserDAO extends IDomainDAO<User>{}

This is an example of how a concrete implementation will look like:

public class UserDAOJDBC implements IUserDAO {

    public int insert(User domainObject){...};

    public int update(User domainObject){...};

    public int delete(User domainObject){...};

    public List<User> getList(IQueryFilter queryFilter){...};
}

On the other hand an implementation could simply be as shown below (and I don't have to spend some time providing specialized interfaces):

public class UserDAOJDBC implements IDomainDAO<User> {

    public int insert(User domainObject){...};

    public int update(User domainObject){...};

    public int delete(User domainObject){...};

    public List<User> getList(IQueryFilter queryFilter){...};
}

Answer 1

This comes down to a design issue. It depends on whether you think that you will -- at any time -- add anything to the IUserDAO interface that doesn't belong in the IDomainDAO interface.

If you considered creating IUserDAO merely to allow you to say implements IUserDAO as an abbreviation for implements IDomainDAO<User>, then it's useless and it is actually more verbose with the extra interface.

If you consider an IUserDAO as a specialized form of an IDomainDAO<User>, then keep the interface; that keeps open the possibility of adding functionality to IUserDAO that doesn't exist in -- and shouldn't be in -- IDomainDAO<User>, e.g. a method such as List<User> getActiveUserList().