[Tutor] class question

[Elwin Estle]

Elwin Estle wrote:

> Is it better to have one large sort of "do it all" class, or break
> the larger class up into smaller classes?

Yes.

Or no.

It's impossible to answer that question definitively without knowing more about what "it all" is. But I can give some general advice:

* Python isn't Java. Don't feel that you must use classes. If your problem is better solved using a procedural or functional approach, go right ahead and use it. Classes aren't compulsory.

* The standard model which you should use it:

  verbs -> functions or methods
  nouns -> classes or attributes

  You should be able to answer the question "What *thing* does
  your class represent?". (The answer can be an abstract thing,
  but it should be a thing.)

  If you can't answer that question, then you shouldn't use a
  class. You should solve the problem using stand-alone functions.

* Think about "is-a" and "has-a" relationships:
==================================================================

The class in question, does, in fact, deal with a thing.  The problem is, the "thing" is highly mutable.   The "is-a" and the "has-a" changes.

Here is the scenario:

A raw casting comes into a factory.  It is listed as such.  When machined, this part number changes to a different part number.   The raw casting has no "quality related" stuff, but the machined casting does, and it can have more than one "quality related" thing.

...because, the raw casting may go through multiple operations to get to it's final state.  It may get machined on a lathe, then be transferred to a CNC machining station where a bolt circle may be drilled and tapped into it.  Each of those operations on separate machines will have a different set of quality checks associated with it.

...or it might be a part that goes from a raw casting to a sort of "mini-assembly" such as a rocker lever (if you know what that is), so we have raw casting = one part number, then it gets a bushing pressed into it = another part number, then it gets a threaded insert = another part number, but it is still the same thing, and each one of those steps may have some sort of quality check involved.

Lets complicate things even further.  One raw casting may be machined into multiple part numbers.  Perhaps the only thing that changes is the location of a single hole.  But again, each one of those part numbers may go through multiple machining operations on different machines, with different quality checks.  This is done through something called a "tabbed" blueprint, wherein there is a master number, but there are "tabs" indicating that if you changes such and such feature, then the part number isn't the master number, but the tabbed number.

So, in essence, there's a sort of "network" of "is-a" and "has-a" information.

My idea was to, instead of having just a single "part" class, to have a sort of "component aggregate" class, which would cover not only single parts, but assemblies of parts.  So, even if a part was as simple as a raw casting that is just machined into a finished part and that's it, it would still be treated as a sort of assembly, with the raw casting being a component of the finished part number, if that makes sense.

So there's all this information associated with a given part.  I am thinking it has a sort of tree structure.  I am just wondering if some of the branches of the tree should be separate classes that are then tied into the "trunk" of the master class, or if the whole thing should be a tree into and of itself.

...and yeah, I know, it's kind of a complex problem for a newbie to be thinking about.






      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20110126/c747b525/attachment-0001.html>