Part Classes

Motivation

Encapsulate how the geometry of a part is made.

Parts are often thought about as real world objects, and therefore fit nicely into the paradigm of Object Oriented Programming (OOP) as classes.

Each part class has the single-responsibility to “make” the geometry for a given part.

For example, you might have a Box class with a make method that encapsulates and exposes how to create the geometry of a box.

import Part


class Box:

    @staticmethod
    def make():
        box = Part.makeBox(10, 10, 10)
        return box

Note

Naming the method make is a convention inspired by FreeCAD’s make* Part API.

While in this trivial example the Box class and make method don’t provide much value, this abstraction offers a simple interface for “making” more complex and custom geometry.

For example, you may pass in the length and width into the make method as parameters for creating boxes of different sizes.

class Box:

    @staticmethod
    def make(length, width):
        height = 10
        box = Part.makeBox(length, width, height)
        return box

We could have defined a make_box function instead, but why is the class approach preferable?

Imagine the box is a sub-part of a more complex part, and that parent part needs to know about the static height of 10 for the box.

With a quick refactor, the parent part can now access the height of the Box as a static property, and that information stays close to the construction of the box geometry, as opposed to being defined somewhere else in the program via constants or some other approach.

class Box:

    height = 10

    @classmethod
    def make(cls, length, width):
        box = Part.makeBox(length, width, cls.height)
        return box