Essential tools for Python development
ben+python at benfinney.id.au
Fri Apr 24 03:21:06 CEST 2009
Phillip B Oldham <phillip.oldham at gmail.com> writes:
> On Apr 22, 5:00 am, Ben Finney <ben+pyt... at benfinney.id.au> wrote:
> > code each module so that the behaviour is easily introspected and
> > tested from outside the module. If I'm not able to easily introspect
> > the code at an interactive prompt, that's a clear sign that the code
> > interface is poorly designed. So I fix that first.
> Could you give a small example of this approach?
Sure, though the principle is general and applies to many different
situations (there are many more ways to write bad code than ways to
write good code :-)
A common anti-pattern is a swath of code that does too much in one
lump. A contrived example::
intermediate_result = (frob * spang) + foo
secondary_result = spam.register(intermediate_result)
This is difficult to introspect because it's not clearly parameterised,
and it does too many things so it's difficult to trigger only part of
its behaviour for testing.
Depending on the conceptual arrangement of the steps and their actual
semantic meaning, this might work better as::
result = (frob * spang) + foo
def convert_floop(floop, twiddler):
def register_spam(spam, entry):
result = spam.register(entry)
foo_twiddler = frob_and_spang(foo)
result = register_spam(foo_twiddler)
Rather contrived, but I hope you can see that this approach makes it
much easier to get at any of the steps that comprise ‘one_man_band’ from
outside the module, and introspect them simply by calling small
functions. Debugging is much easier with this design.
This also makes them easier to unit test; in fact, if unit testing is
adopted as a mandatory practice, it's much more likely to result in the
loosely-coupled approach *first* rather than needing to be refactored to
achieve it later.
\ “I may disagree with what you say, but I will defend to the |
`\ death your right to mis-attribute this quote to Voltaire.” |
_o__) —Avram Grumer, rec.arts.sf.written, May 2000 |
More information about the Python-list