I've seen this quite a bit in Altitude, lots of formal parameters in method declarations. Often times these params are simply passed on to the next method in the chain. These can easily be replace with a small composite class that simplifies the method signature. I've been replacing these with what I call "specs", so we have a "site spec" which defines an Altitude web site (site code/interface code pair) and a "service spec" which defines a host and port of a network service. Martin Fowler describes them as data clumps [1]: "This is one of my favorite CodeSmells from the refactoring book. You spot it when you constantly see the same few data items passed around together. start and end are a good example of a data clump wanting to be a range. Often data clumps are primitive values that nobody thinks to turn into an object. The first step is to replace data clumps with objects and use the objects whenever you see them. An immediate benefit is that you'll shrink some parameter lists. The interesting stuff happens as you begin to look for behavior to move into the new objects." This is also talked about in constructor initialisation: http://martinfowler.com/bliki/ConstructorInitialization.html [1] http://martinfowler.com/bliki/DataClump.html -- tom adams p: +61.7.3011.7509 | e: tom.adams@xxxxxxxxxxxxxxxxxxx ************************************************************ List homepage: //www.freelists.org/list/fct-java-geeks PLEASE NOTE: This list is for general technical discussions. Please do not post sensitive company specific information to this list. ************************************************************