[Tutor] When to use classes

[boB Stepp]

On Fri, Aug 18, 2017 at 9:56 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> Mostly for Bob, but also for anyone else interested:

I guess I'm the "Bob" being referred to.

> When To Use Classes
>
> http://kentsjohnson.com/stories/00014.html
>
>
> He says:
>
>     You may have several functions that use the same state
>     variables, either reading or writing them. You are passing
>     a lot of parameters around. You have nested functions that
>     have to forward their parameters to the functions they use.
>     You are tempted to make some module variables to hold the
>     state.
>
>     You could make a class instead!

>
> Indeed you could, and sometimes you should, but we can see a problem
> here. The situation described is a bad situation to be in: there is too
> much coupling between functions, too much state being passed around.

Excellent point!  This sort of stuff has made it hard for me come up
with good tests.

But I wonder if the author is thinking about something a bit simpler.
In some of my procedural-based programs, I might have started out with
one long, overly complex function.  I think that I need to break this
up into smaller, more single purposed functions, and do so.  But often
this has resulted in a "daisy chain" of functions -- the first
function starts things going, called the next function.  Then that
function calls the next, etc.  When I have found myself in this
situation, there are often a set of values that are needed by several
of these functions, tempting me to "globalize".  But I resist and
instead pass the needed values as arguments.  In this case each
function can be very focused in what it accomplishes, and is easy to
test, but the same values keep being needed by these functions.  I
think this is not necessarily the point you are making?  Anyway, I can
see the author's point that a class would work well here.  A suite of
related methods needs to share the same values and a class would tidy
this up nicely without the need for any globals or needless passing of
the exact same values around as parameters/arguments.

> Ideally we should try to *reduce the coupling* between components, if
> possible, and hence make the program less complex. OO design tries to
> encapsulate the coupling within (hopefully) a single class, but it does
> nothing to reduce the coupling or complexity.
>
> So I would say:
>
> - if your code is complex, with lots of connections between
>   components (coupling), try to reduce the coupling and make
>   the code simper;
>
> - if you can't, encapsulate it in classes.

I really enjoyed reading this brief article.  He explained things
rather clearly.  And he used some modules that I have used (I have yet
to use all of them he cited.).  This got me to examine the csv.py
file, for instance, which proved to be an interesting read in light of
his points.

Thanks for the link, Steve!  This will help me design my current
project better, I'm certain.  At the moment, however, I am studying up
on SQL (Once again.  Maybe I will make it farther this time!) in order
to use sqlite3 in this project.

-- 
boB