No hay una clave para crear una herencia perfecta.
Con el uso de super y override puedes hacer lo que estás pidiendo tranquilamente.
Eso de que si te devuelve un objeto de tipo contacto o contactoEmpresarial , puedes comprobarlo por ti mismo tranquilamente, simple y tan llanamente probando
Si tienes un método en tu interface, clase abstract base, o clase, ejemplo, getConexion, las clases que implementa a ese método , es decir que hereden a una de esas clases, tanto por simple herencia, o herencia múltiple, tendrán su propia implementación y conectarán a la tabla, o procedimiento almacenado correspondiente, claro está que cada implementación debe apuntar a la tabla correcta.
No te vuelvas loco enredándote, que lo que quieres hacer si que se puede.
Las 2 maneras son validas
* Eso de la interface que te vuelve objetos de tipo contacto en ves de empresarial? Es Bull shit o algo parecido
Tu clase Contacto, debería ser más bien la clase abstracta base de la cual van a heredar las clases hijas, Contacto Empresarial y otros tipos de contactos y ya. No te vuelvas loco, y esa clase abstracta puede a la vez, implementar una interface, que contenga los métodos que quieres que implementen a las clases hijas de diferentes tipos de contactos, o la misma clase abstracta dar implementacion a ellos y las hijas usarlos con dicha implementacion, empresarial,personal, u otros dog.
Añadiendo Generics se puede ahorrar mas código, pero ahí se complica solo un poco más eso es todo.pero ni tanto, y sobre los Generics hace poco implemente algo parecido, y totalmente funcional, vía herencia múltiple usando una interface de servicio genérico para un log de una db.
Código
public interface ServicioXXX<T extends ServicioBean>
y ese servicio dentro retorna parámetros genéricos tipo T , en cada método. Al heredar de ahí, osea
Código
public class ServicioXXXImpl implements ServicioXXX<ServicioBean>
ese parámetro específico dentro del operador diamante indica lo que retornará cada método en ServicioXXXImpl o parámetros en dichos métodos, teniendo un solo servicio, ahorrando tener múltiples ServixioXXXA, ServicioXXXB, y casting innecesarios en la mayoría de los casos.