Screaming Penguin

At a new gig I started recently one of the tasks I have is hitting the ground running and getting familiar with (at least) a lot of code on a lot of projects. It is my present duty to work on reference implementations and offer feedback and so on for other developers, as well as work on infrastructure projects and write code (I hesitate to call this an "architecture" related job, because of all the negative connotation I personally have for that term from experience over the course of my working life - 95% of the architects I have met were virtually useless, outside of fancy PowerPoint presentations). My employer, like many companies, is looking to move core functions toward an SOA approach. Designing services, and useful APIs in general, is often different than just working on internal classes and structures. You have to think about how things will be used and how they come across to people just hitting the outside level with no other understanding of internals. One specific item I might note is that you should try to avoid passing in many untyped parameters (Strings) or collections, or collections of collections and so on, because understanding is reduced, usability is hampered, and validation and other aspects are harder (not to mention that you just threw out typing and all that that entails, for no good reason). I have seen this in a few APIs my new company currently has, and have brought up, tactfully, that I felt it was less than ideal. I made my own blabbering arguments about it, and noted that especially when it comes to exposing services the approach of a lot of untyped parameters is problematic (you then have to include a spreadsheet or some documentation, rather than the typing being part of the API). When my arguments didn't really get a lot of attention, or even got pushback - concerning a topic that I consider the jury to be in on, I decided to poke around and see what the internets thought about this. I searched for "too many parameters" and other phrases and quickly came across articles from "expert" sites like this and this. Frankly, all the "answers" in those pages were pathetic, I thought. Really, horrible. Not a single person in those responses mentioned using the Builder pattern, or creating a typed parameter object? Rather the suggestions there were to use arrays or collections, or even to use a single String and delimit it somehow. You stepped in what! As Nate might say "go get me a coffee." So I searched a bit more and came across TooManyParameters at the great C&C site, which led me to an ANTI-PATTERN named MagicContainer. It seems to line up with my sentiment, too many params is a bad smell. I hadn't heard of MagicContainer before, shamefully or not, but it sure might help me to help others in the future. In summary the answer to "too many parameters" is *NOT* to use an array/collection, but rather to use the improved builder, or for more service friendly APIs (those you plan to expose over the network, so you don't want 10 chained calls to setup) simply use a ParameterObject that makes sense (and by makes sense I mean don't just move the problem by moving Strings or something to a new object, use the type system you have and type things, then create a composite as a parameter object).