On Fri, Aug 18, 2017 at 9:56 PM, Steven D'Aprano <st...@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 _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
