Interface to return Generic type

I have an interface that returns a Connection. I've changed to Object, because I need to return sometimes a Connection and sometimes a MongoDatabase object from Mongo.
My poor ideia was to change this method to Object, like this:

Object getConnnection(String uri);

Is a poor design? Any suggestion to improve this aproach? Thanks a lot for any suggestion.

> I have an interface that returns a Connection. I've changed to Object,
> because I need to return sometimes a Connection and sometimes a
> MongoDatabase object from Mongo. My poor ideia was to change this
> method to Object, like this:
>
> Object getConnnection(String uri);
>
> Is a poor design?

If the intended uses of this interface will require users to cast the return value, or otherwise do anything with it that depends on knowing or assuming whether it is a Connection or a MongoDatabase, then yes, it is a poor design.

Also, getConnection is a terrible name for a method that in fact might return something that is not a Connection.

> Any suggestion to improve this aproach?

There are plenty of alternatives that would be better, but which one is best for you depends on how you want to use instances of this interface. Some of the more likely possibilities are

• give the interface separate methods for retrieving a Connection and for retrieving a MongoDatabase. This is not great if individual instances cannot be expected to be able to do both, but even then it's better than the version presented in the question.

• provide a separate interface representing objects that can provide MongoDatabases, with an appropriately-named method for that purpose.

• put a method for retrieving a MongoDatabase (only) on a class implementing the interface, and make methods that need to be able to exercise that getMongoDatabase() method require instances specifically of that class. Possibly create a sub-interface that specifies the getMongoDatabase() method.

• make the interface generic, parameterized by the type of object to which it provides access. For example,

  interface DatabaseAccessor<T> {
      public T getDatabaseObject();
  }
  

  Each implementation would then be specific for Connections or MongoDatabases or some other similar thing. Other methods that want to consume these specify what flavor of DatabaseAccessor they need via the type parameter.

Unless you plan to only use toString or the other few methods available on Object, that type isn't useful. Thus, client code will have to attempt to downcast in order to do something more useful with it. Thus, it's generally regarded as a design smell. I don't currently have my copy of Refactoring handy, but as far as I recall, it describes the code smell and suggests better alternatives.

What's a better design? This depends on context. Why does the interface exist in the first place?

You may consider following the Dependency Inversion Principle, which entails that abstractions should be defined by client code, and not by the implementing class.

Since you don't describe the needs of client code, it's difficult to suggest a better API. I'd suggest to look at the requirements that client code has, and then define a type (interface or base class) that supports those interactions. Then return that type from the method.

If you can't do that, a sum type could be useful. Unfortunately, most object-oriented languages don't support sum types natively, but you can implement them with the Visitor design pattern.