Software Architecture Antipatterns : Swiss Army Knife Interface

Swiss Army Knife Interface is an interface class which has excessive number of method definitions. Architect/designer may design this interface to use for every need of the software, but this is a wrong approach and an antipattern. More than one interface must be designed using some design approaches.

Of course, "excessive number of methods" is a too general statement. Although most developer think that a handful number of methods (e.g. 8-10) and some studies show that some magic numbers (7 plus/minus 2) are mostly enough, we can't say the maximum number of methods precisely.

First of all, you must think that this interface will be implemented by a class and if the number of methods is excessive, there will be plenty of empty method bodies in implementor class. But this situation still can't determine the number of interfaces and number of methods in an interface.

The answer is hidden in the OOP SOLID rules. Single Responsibility ("S") rule of SOLID says that "every object should have a single responsibility", and Interface Segregation ("I") rule of SOLID says that "different types of functionalities should be placed in different interfaces". If an interface have more than one types of functionalities or defines more than one responsibilities, implemening that interface is meaningless because implementer class will not suit SOLID rules by implementing that interface.

More than one Swiss Army Knife Interface may also exist in a software. This means more than one problem exist and must be solved.

For another viewpoint, you can take a look at our another post about interface segregation principle:

This is not about a specific programming language's interface definition. Interface is generally a class having method definitions which have to be implemented. Even if implementer class does not have empty bodies for unimplemented methods, these methods are still not implemented and this will not be a good design.

First of all, this is not an interface, a method. If there is an interface having this method, there exist a bad design. This is better than a 20-30 or more parametered method but parameter type and method are too general. A method must exist for only one purpose, not for the whole business logic. Also number of code line of this method will be excessive with high probability. Heavy loaded parameter size may also cause performance and bandwidth problems.Splitting this method into more than one method with definite typed parameters will be better.