I know this might seem a controversial question but it really is not meant to be. is there an optimal number of methods in an interface.
For example, I personally hate an interface with 20 methods. It is just difficult to implement. The contract seems to hard to maintain. Similarly if the number of methods is just 1. It makes me wonder if it is really a good abstraction.
Any thoughts ?
There's a well-known study that suggests that the number of items of information we can process at a time is seven, plus or minus two. I often find that this is a good rule of thumb for this type of question -- in this case, if the interface is designed to manage a single related set of functionality, we probably won't be able to understand the functionality as a single set if it's much more than seven.
However, for many interfaces a developer doesn't need to be able to understand the functionality as a single related set, in which case this rule would not be relevant.
The way to deal with many methods when you only need to implement a few is Abstract classes that supply default implementations or throw NotImplementedException. If there is only one method then it probably is ok because there are methods that only expect that one Iterface and call that one method. There are lots of patterns, Vistor for example that only need one method.
Well interfaces with one method usually have their purpose and you can implement them anonymously more easily. My rule of thumb is as many methods as it needs to have. But a lot of methods in one interface usually suggests that you can split it into several other interfaces, especially when it affects different task areas (e.g. a UserLoginAndAdministrationInterface becomes one UserLogin and one UserAdministration interface). You can implement as many interfaces as you want in a class and they can be subclassed, too. So splitting them doesn't hurt at all.
An interface should have exactly as many methods as it needs. Examples:
java.lang.Iterable - 1 method
java.lang.Comparable - 1 method
java.util.Collection - 14 methods
java.util.List - 25 methods (including those from Collection)
So the answer is - don't take the number as a criterion for your interface. Instead, put methods in interfaces where they belong logically.
An interface should have exactly as many methods as it needs.
If that number is large the rationale should be looked at carefully, but may be valid.
On the other hand there is (at least) one instance in Java where the interface needs no methods (serializable) and thus has none. Fewer methods, definitely makes it easier to implement the interface but can still provide a very useful abstraction. There are a number of interfaces with one method.
I'd be more concerned that the interface is logically consistent than it has some arbitrary optimal number of methods. That said, a large number of methods might indicate a "god" object, that should be refactored. The clearer indication is that the methods aren't cohesive, but the number of methods might be easier to observe and lead you to closer examination. Sometimes, though, you just need to have a lot of methods because there are a lot of possible operations you'd like to do on objects of that type. An example of this would be something like IEnumerable<T> in .NET. I can't think of any valid reason for breaking those out into separate interfaces, yet there are a lot of methods in the interface.
There is no optimal number of methods in an interface. Interfaces are used for all kinds of different things, and what is appropriate depends entirely on what.
On one extreme, an interface might be automatically code-generated by a program for consumption by another program, and might for good reason have 1,000 methods in it.
For code readable by humans, rules cannot substitute for judgement.
Those twenty methods either capture something useful together or not. If they do, then you need to implement all of them to provide an implementation to that thing they capture. It will be consistent to house them in the same interface in this case.
the answer is - don't take the number as a criterion for your interface. Instead, put methods in interfaces where they belong logically and you can use it in differnt classes you can use one method of interface in two or more classes so don't hesitate to use interface its a good programing techniqe.
There is no right or wrong answer to how many methods are acceptable for an interface to have. Some can have zero, others one, and probably very few will ever exceed a hundred. The largest interface I've ever written was nearly thirty methods but it was a facade for clients.
However I would think that an interface that had more than say 8-10 methods would be a possible code smoke -- just something that would warrant 5 seconds to investigate.