Ian Bicking: the old part of his blog


I agree with Martijn Faassen. Either keep it explicit, or make it an attribute. If only a few methods need it, leave it as a parameter to the methods. Otherwise, make it a parameter to the constructor. If you're just passing context along to some other dependent objects, maybe consider making it an attrobute of those objects instead.

Another way of looking at it is like this: Say you started with a bunch of ordinary functions (no objects). You realized after awhile that all of these functions took at least the same three parameters. So, you make a class to encapsulate those three parameters, and thus make the "context" of those functions (now methods) implicit. Now, time goes by, and you realize that you're passing yet another parameter to all (or almost all) of these functions. This additional parameter, unfortunately named "context" as well, looks like it's part of this class's encapsulated context as well. So, move it into the class, along with the first three. Granted, this is a very mechanical view of OO, but it often works for me.

I don't know your specific situation, so this is all based on an abstract notion I have of your real problem, but I'd be skeptical of any metaprogramming solution to--what seems to me--too simple of a problem to warrant it.
Comment on Dealing with Context
by Dave Benjamin