Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #70560

Re: Moving to an OOP model from an classically imperitive one

Show all headers | View raw

tim.thelion@gmail.com wrote:
> I think this would be better solved
> by moving fully to an OOP model.  That is, I would have a SubuserProgram
> class which had methods such as "install", "describe", "isInstalled"...

This wouldn't necessarily be better. Don't be taken in by the
"everything is better as a class" kind of dogma that seems to
prevail in some circles.

If all you do is take a bunch of module-level functions and
put them into a single class, you haven't really changed anything.
It's still the same design, you've just arranged the source
differently.

There are a couple of good reasons for turning a function into
a method. One is if it embodies implementation details that you
want to keep separated from the rest of the program. But if
*all* of your code is inside the class, there isn't any "rest
of the program" to keep it separate from.

Another is if you want to be able to override it in subclasses.
If there were different kinds of SubuserProgram that needed to
be installed in different ways, for example, it would make
sense to structure this as a collection of classes with an
install() method. But even then, you don't have to put all
the installation code in the classes -- the methods could just
be stubs that call out to different module-level functions if
you wanted.

A reasonable compromise might be to keep the *data* assocated
with a SubuserProgram in a class, maybe together with a few
methods that are tightly coupled to it, but have the major
pieces of functionality such as install() implemented by
separate functions that operate *on* the class, rather than
being inside it.

> Currently, I have these functions logically
> organized into source files, each between 40 and 170 LOC.

That's quite small as these things typically go. You can afford
to make them somewhat larger; I tend to find that files start to
get unwieldy around 1000 lines or so.

-- 
Greg

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Moving to an OOP model from an classically imperitive one tim.thelion@gmail.com - 2014-04-23 13:57 -0700
  Re: Moving to an OOP model from an classically imperitive one Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-04-23 22:15 +0100
  Re: Moving to an OOP model from an classically imperitive one Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-23 15:23 -0600
    Re: Moving to an OOP model from an classically imperitive one Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-04-24 12:26 +1200
  Re: Moving to an OOP model from an classically imperitive one Ethan Furman <ethan@stoneleaf.us> - 2014-04-23 14:42 -0700
    Re: Moving to an OOP model from an classically imperitive one tim.thelion@gmail.com - 2014-04-24 00:32 -0700
  Re: Moving to an OOP model from an classically imperitive one MRAB <python@mrabarnett.plus.com> - 2014-04-24 00:08 +0100
    Re: Moving to an OOP model from an classically imperitive one tim.thelion@gmail.com - 2014-04-24 00:21 -0700
      Re: Moving to an OOP model from an classically imperitive one Chris Angelico <rosuav@gmail.com> - 2014-04-24 17:36 +1000
      Re: Moving to an OOP model from an classically imperitive one Steven D'Aprano <steve@pearwood.info> - 2014-04-24 09:08 +0000
  Re: Moving to an OOP model from an classically imperitive one Chris Angelico <rosuav@gmail.com> - 2014-04-24 09:12 +1000
  Re: Moving to an OOP model from an classically imperitive one Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-04-24 12:21 +1200
    Re: Moving to an OOP model from an classically imperitive one tim.thelion@gmail.com - 2014-04-24 09:53 -0700
      Re: Moving to an OOP model from an classically imperitive one Amirouche Boubekki <amirouche.boubekki@gmail.com> - 2014-04-25 19:21 +0200
  Re:Moving to an OOP model from an classically imperitive one Dave Angel <davea@davea.name> - 2014-04-23 22:01 -0400

csiph-web