El problema con ese diseño es que no estás "
encapsulando" el uso de bases de datos.
¿Por qué no el modelo "clásico" (y suficientemente probado como para no tener que reinventarlo
) de una "clase de abstracción genérica" y luego le pasas por parámetros o por métodos cual es la base que quieres usar?
Una instancia del objeto = una base de datos.
Dependerá también de qué es lo que quieres hacer con las bases, si vas a interactuar entre ellas, etc.
Mi sugerencia sería que crees una clase "BaseDeDatos" que te abstraiga de las clases "concretas" de abstracción (AdoDB, Pear, etc) e implementes tú los métodos que vas a necesitar, pero que la implementación contenga dentro las llamadas a los métodos de las clases concretas.
Por ejemplo, si usas en todo tu sistema la clase AdoBD, y mañana decides cambiar a Pear, tu código está tan acoplado que tendrás que modificar todo el sistema donde use las bases de datos.
De lo contrario, solo modificas la implementación de la clase "BaseDeDatos" y todo tu sistema no se entera, y el costo de los cambios será mucho menor.
Tu sistema pasará a depender de
"implementaciones abstractas" y no de
"implementaciones concretas", desacoplando mejor el código.