Ben Finney wrote: > "Alan Isaac" <[EMAIL PROTECTED]> writes: > > > There are *many* parameters, and the list can change, so I want to > > avoid listing them all in the Param class's __init__ function, using > > the strategy above. > > > > Q1: Is this approach reasonable? > > (This is a newbie question about unforseen hazards.) > > Q2: Is it horrible design to isolate the parameters in a separate class? > > (Comment: currently several classes may rely on (parts of) the same > > parameter set.) > > It's a bad design smell to have functions that accept large numbers of > parameters, many of them optional. Such an interface is difficult to > document, maintain and test. > > You should certainly be examining such code and seeing how much of it > can be implemented instead as functions with small, well-defined > parameter lists. This may mean writing more functions, or more layers > of functions, or more classes, or whatever; but having a result that > uses small, well-defined interfaces is a valuable property.
So I guess you prefer the (os.system, os.spawn*, os.popen*, popen2.*, commands.*) kitchen sink than the single versatile subprocess.Popen class, right ? I respectfully disagree, and I'm all for one-class-does-it-all, as long as most parameters are optional and the default values address the most typical/reasonable case. To answer to OP's question, your approach is totally reasonable and well-known; the csv.Dialect class for example is exactly this, a parameter-holding class. George -- http://mail.python.org/mailman/listinfo/python-list
