I'm using a large interface with about 50 methods to access a database. The interface has been written by a colleague of mine. We discussed this:
Me: 50 methods is too much. It's a code smell.
Colleague: What shall I do about it? You want the DB access - you have it.
Me: Yeah, but it's unclear and hardly maintainable in the future.
Colleague: OK, you are right, it's not nice. How should the interface look like then?
Me: How about 5 methods that return objects that have, like, 10 methods each?
Mmmh, but wouldn't this be the same? Does this really lead to more clarity? Is it worth the effort?
Every now and then I'm in a situation where I want an interface and the first thing that comes to mind is one, big interface. Is there a general design pattern for this?
Update (responding to SJuan's comment):
The "kind of methods": It's an interface for fetching data from a database. All methods have the form (pseudocode)
Methods and tables are not exactly in a 1-1-relation, the emphasis is more on the fact that you always get some kind of list that comes from a database.