I would say no. I'm not sure what language this is but first of all, some (most?) methods on a class should be private. They are implementation details and should not be exposed at all.
So if we assume the is only about public methods, I still argue the answer is: no. The point of an interface is to define the methods that are to be used in contexts where the implementation class isn't known and doesn't matter. While it would be possible to create 'filler' interfaces that specify implementation specific methods, this is just cruft unless there is going to be some code referencing that interface in a implementation agnostic way. This will surely result in devolving into something approximating having an interface per class which is something I consider noise.
For example let's say I have defined a simple, read-only dictionary interface for use in an algorithm:
interface ReadOnlyDict<E> {
E get(Object key);
}
My algorithm doesn't care about how you implement that method. Maybe it's a Map
. Maybe you use a switch statement to call different methods on an object. Maybe it reads from a file, maybe it calls from the remote web service. In each of these cases, there could be plenty of things that the code creating those objects needs to be able to call to prepare it for use. Maybe those methods are defined by other interfaces and that's great. But if they aren't, creating an interface simply so that they are defined on one is a pointless exercise, in my opinion.