>
>
> 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.
>
>
>
>
Here is my two-cents. This code is untested. Import statements haven't been
included, there could be syntax errors, etc etc etc. What I did
was switching off the part_number attribute in the Thing class. For the
functions that "do stuff" to the thing instance, I appended a part-number
(assuming new part number = master number + doing stuff number). The quality
functions will check for that part number before proceeding with the checks.
class Thing: # single part class
def __init__(self,part_number='12345'): # 12345 is a default part
number
self.part_number=part_number
def routeThing(thing):
try:
thing.part_number.append('-someRoutingPartNumber')
<do routing>
exception AttributeError (e):
e.printStackTrace()
print "Router was not applied to thing"
def checkQualityRoute1(thing):
if hasattrib(thing,part_number) &&
(thing.part_number.find('-someRoutingPartNumber'):
<do quality checks>
else:
print "Thing has not be routed yet"
def checkQualityRoute2(thing):
if hasattrib(thing,part_number) &&
(thing.part_number.find('-someRoutingPartNumber'):
<do quality checks>
else:
print "Thing has not be routed yet"
.... continue for all of the functions that you might need
HTH,
-Tino
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
