[Chicago] Factoring fun with functions in Python
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:
> 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
More information about the Chicago