Methods with too many parameters

Method with too many parameters (esp in exported api) is a Codestench (?). It makes an API usage a pain. IMO 4-5 parameters should be the practical maximum.

I have seen them evolve in two (anti) patterns. One is a desire to create a feature rich API. And in doing so adding new enhancements very intrusively, e.g by adding a parameter for each parallel feature in existing methods. In turn producing a polluted feature creepy (YAGNI) API, making it very difficult for normal situations.

e.g.
// Normal API to find a blade in database by a its id a long type.
Blade blade = bladeFinder.getBladeById(id);

Developer modified above finder to search by multiple id types (by name, key, by group etc addin one param) , from multiple data sources(adding three params), and multiple service types (ejb/jms/corba servers) in total adding five more parameters.

// Ugly
List blades = (List) bladeFinder.getBlades(idType, id, userid, password, datasourceName, servertype);

In next version developer added a new feature to get data in different formats XML, formatted HTML, Blade object etc (adding one more param for dataformat). As part of this new version a new parameter object is created with all the parameters from old previous finder method + one more to support dataformats. A Response object is also added to wrap return data, exceptions, some more methods. Usage pattren changes to

// The ugly
BladeRequest request = bladeRequestFactory.createReadBladeRequest(idType, id, dataFormat, userid, password, datasourceName, usingJMS, ...);

BladeResponse response = bladeRequestProcessor.processRequest(request);

If (response.getAttribute(somecode).equals(successcode))
Blade blade = (Blade) response.getObjectType(OBJ_FORMAT);
else
String failMessage = (String) response.getFailureObject();


Other pattern is a need/plan to develop very loosely coupled modules. These modules agree only on a minimal set of interfaces and see world very differently.
e.g. proverbial OR mismatch. One layer looks a BladeObject and other looks it as a Map.

Possible refactorings ?

• Make one or more parameter objects with all the parameters. We are moving problem from one place to other place.
• Setters instead of constructor for Parameter object, with possible defaults for some. (confusing some times, difficult to document etc)
• A magic container like properties(map), that server assumes a default for missing properties. (confusing some times, difficult to document etc)
• Write Facades to hide ugly code(If we can't change any interfaces or if it is a result of a loose coupling design).
• Remove unused features/parameters, computable parameters if any.
• If a parameter is an enumeration provide different methods for each type.
  

The above example can be refactored by removing unneeded features data source (user and password too) parameter. And adding new Criteria a parameter objects and new methods for each data format.

// Refactoring to below
Criteria criteria = ...; // to make a search expression
List /**/blades = bladeFinder.findBlades(criteria);
//or xml as String
List /**/ blades = bladeFinder.findXmlBlades(criteria);