[Chicago] Factoring fun with functions in Python

Dan Krol orblivion at gmail.com
Thu Nov 15 16:41:57 CET 2012

Sure, I'm not against writing one or two line functions or one or two
function modules when it represents appropriate coupling. I was just
focusing on the fact that *every* function in the example was like
this, and perhaps I took that aspect of the example to be a key point
when I shouldn't have.

On Thu, Nov 15, 2012 at 5:15 AM, Martin Maney <maney at two14.net> wrote:
> On Tue, Nov 13, 2012 at 08:35:17PM -0800, Dan Krol wrote:
>> One thing I struggle with on this count is that spitting it up to this
>> degree makes it confusing all over again, because there's so many
>> functions, so many lines of logic to follow. There's no indicating what the
>> "main idea" is, you just have to read it all to find out what isn't being
>> called by everything else.
> The intention may have been to suggest a good design approach, but if
> so it's a really poor example.  I've been struggling with finsing a way
> to talk about the problems, and I think Google has finally found me a
> simple way to approach it.  Read this:
>   http://highered.mcgraw-hill.com/sites/dl/free/0073191264/371536/Ch07.pdf
> The whole issue of module size is, at best, an approximation to the
> real issues of cohesion and coupling.  And, yeah, none of this has
> changed all that much since the seventies.  At the most, OOP and FP and
> fad-of-the-month-Programming have all been, at bottom, attempts to make
> good cohesion and low coupling "just happen".
> Have you ever considered that an object is a bunch of related functions
> with a bunch of locally-global variables?  Not, perhaps, the best OOP,
> but c'mon, I'm sure you've seen this if not written it yourself.
> Nested functions, likewise, have value, but often suffer from the
> "simplification" of implicitly sharing the enclosing-and-calling
> scope's locals as the nested function's globals.  Back int he day
> FORTRAN had this named COMMON thing to support the same concept.
>> Any ideas on that front? Isn't there such a thing as splitting functions up
>> *too* much?
> From Ch07:
>   If a software organization insists that modules must be neither too
>   big nor too small, then two undesirable things happen.  First, two or
>   more otherwise ideal smaller modules are lumped together to create a
>   larger module with coincidental cohesion.  Second, pieces hacked from
>   well-designed modules that management considers too large are
>   combined, again resulting in modules with coincidental cohesion.
> --
> If nature has made any one thing less susceptible than all others of
> exclusive property, it is the action of the thinking power called an
> idea, which an individual may exclusively possess as long as he keeps
> it to himself; but the moment it is divulged, it forces itself into
> the possession of every one, and the receiver cannot dispossess
> himself of it.  -- Thomas Jefferson
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> http://mail.python.org/mailman/listinfo/chicago

More information about the Chicago mailing list