A technique
First off - I'm a fan of named parameters - which is why I much prefer languages like ObjectiveC and Smalltalk as they name the params in the message names.
dict at: key put: anObject.
I name my java method names similarly
map.atKeyPutObject(key,object);
Yes they get looooong - but they are understandable.
longest method name I remember in the WebObjects api is
object addObject: anObject toBothSidesOfRelationshipWithKey: relationshipName;
Lately I've been running into situations where I've written a method and it does exactly what I want in 90% lf cases and I'm using it all over the code. Then I hit a case where it has to act just a tiny bit different.
So I add an additional parameter and extend the name of the original function, then reimplement the function to pass what would be the default parameter.
so I had product.addDemand(demandQuantity) throws UnsatisfiableDemandException
and then well into the project I learn that there is a case where you have to push the demand through regardless of whether you can satisfy it - which ended up with me changing the first method to:
product.addDemandForced(demandQuantity, shouldForce)
and creating
product.addDemand(demandQuantity) { addDemandForced(demandQuantity,false); }
Still clear what's going on and I don't have to touch the already written code that uses the usual behavior.
