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.
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
