About object-oriented programming

[lypwig]

I would like to embrace python's OOP with build123d, I think it's a good paradigm to deal with cad models.

For instance, I would like to make a class that represent a box with a hole and a fillet.

In algebra mode, I do it this way:

import build123d as _ # yeah I belong to the no-wildcard team :)

box = _.Box(30, 20, 10)
box = _.fillet(box.edges().filter_by(_.Axis.Z), 5)
box -= _.Cylinder(3, 10)

In OOP, I would like to inherit the Box class. Something like this:

class RoundedBoxWithHole(_.Box):
    def __init__(self, length, width, height, hole_diam, fillet, **kwargs):
        super().__init__(length, width, height, **kwargs)
        self.make_hole(hole_diam)
        self.make_fillet(fillet)

But then I have some issues when implementing the two last methods. Of course, I can't do this:

def make_hole(self, hole_diam):
    self -= _.Cylinder(hole_diam, self.height)

def make_fillet(self, fillet):
    self = _.fillet(self.edges().filter_by(_.Axis.Z), 5)

So I was looking for oop equivalents, and so I found part.fillet() and part.cut(), nice! Let's try this:

box = _.Box(30, 20, 10)
box.fillet(1, box.edges().filter_by(_.Axis.Z))
box.cut(_.Cylinder(3, 10))

But it seems that it doesn't work that way. This fails (for both method calls).

I would like to understand why. Is there a technical reason that could make this difficult to implement by design? Or it could but it's out of scope / not planned yet?

[gumyr]

This part of the docs describe exactly what you are requesting: custom objects. Once you create objects that are a subclass of BasePartObject, BaseSketchObject or BaseLineObject then all of the standard method and mechanisms will work for your custom object. The bd_warehouse library is full of examples of this.

I'm happy that you're attempting to build objects like this.

[lypwig]

Thank you!

Yes I tried with BasePartObject but I still don't understand how to do basic operations like detailed above.

Could you explain how am I supposed to implement this RoundedBoxWithHole class?

[gumyr]

Here is a link to the bd_warehouse Pipe that you can use as reference: https://github.com/gumyr/bd_warehouse/blob/main/src/bd_warehouse/pipe.py

[jdegenstein]

Here is a basic example in builder and algebra modes:

class RoundedBoxWithHole(BasePartObject):
    def __init__(
        self,
        length,
        width,
        height,
        hole_diam,
        fillet_rad,
        rotation: float = (0, 0, 0),
        align: tuple[Align, Align, Align] = (Align.CENTER, Align.CENTER, Align.CENTER),
        mode: Mode = Mode.ADD,
    ):
        with BuildPart() as zz:
            Box(length, width, height)
            fillet(edges(),fillet_rad)
            Hole(hole_diam)

        super().__init__(part=zz.part, rotation=rotation, align=align, mode=mode)

class RoundedBoxWithHole_alg(BasePartObject):
    def __init__(
        self,
        length,
        width,
        height,
        hole_diam,
        fillet_rad,
        rotation: float = (0, 0, 0),
        align: tuple[Align, Align, Align] = (Align.CENTER, Align.CENTER, Align.CENTER),
        mode: Mode = Mode.ADD,
    ):
        zz = Box(length, width, height)
        zz = fillet(zz.edges(), fillet_rad)
        zz -= Hole(hole_diam, height)

        super().__init__(part=zz, rotation=rotation, align=align, mode=mode)

[lypwig]

Thank you!

Sorry if I was not very clear, but I actually wanted to work with class methods and use them to update to object.

I took a look on the sources of bd_warehouse and build123d primitive parts (box, cylinder, etc), but each time all the job is done in the constructor.

By the meantime I found a solution: don't inherit BasePartObject and use a part attribute that stores the part:

class RoundedBoxWithHole:
    def __init__(self, length, width, thickness):
        self.length = length
        self.width = width
        self.thickness = thickness
        self.part = _.Box(length, width, thickness)

    def make_hole(self, hole_diam):
        self.part -= _.Cylinder(radius=hole_diam / 2, height = self.thickness)

    def make_fillet(self, radius):
        self.part = _.fillet(self.part.edges().filter_by(_.Axis.Z), radius=radius)

I must get the part attribute (ie. show(obj.part) instead show(obj)), but at least it provides the flexibility I was looking for.

[gumyr]

If you subclass BasePartObject and use super() in the constructor, then the methods just refer to self to get the part.

[gumyr]

To expand, this is what I was referring to:

class RoundedBoxWithHole_alg(BasePartObject):
    def __init__(
        self,
        length,
        width,
        height,
        # hole_diam,
        fillet_rad,
        rotation: float = (0, 0, 0),
        align: tuple[Align, Align, Align] = (Align.CENTER, Align.CENTER, Align.CENTER),
        mode: Mode = Mode.ADD,
    ):
        self.box_height = height
        zz = Box(length, width, height)
        zz = fillet(zz.edges(), fillet_rad)
        # zz -= Hole(hole_diam, height)

        super().__init__(part=zz, rotation=rotation, align=align, mode=mode)

    def make_hole(self, hole_diam) -> RoundedBoxWithHole_alg:
        self -= Hole(hole_diam, self.box_height)
        return self


test1 = RoundedBoxWithHole_alg(30, 20, 10, 2)
test2 = test1.make_hole(4)
test3 = RoundedBoxWithHole_alg(30, 20, 10, 2).make_hole(4)

Here I've added a make_hole method to RoundedBoxWithHole_alg and here are the three test results:

Using the power of OO you could also subclass Box itself and add some methods to it like this:

class HoleBox(Box):
    def __init__(
        self,
        length,
        width,
        height,
        rotation: float = (0, 0, 0),
        align: tuple[Align, Align, Align] = (Align.CENTER, Align.CENTER, Align.CENTER),
        mode: Mode = Mode.ADD,
    ):
        super().__init__(
            length, width, height, rotation=rotation, align=align, mode=mode
        )

    def make_hole(self, hole_diam) -> HoleBox:
        self -= Hole(hole_diam, self.box_height)
        return self


test4 = HoleBox(30, 20, 10)
test5 = test4.make_hole(4)

In this case, the attribute box_height was inherited from Box.

[lypwig]

First of all, thank you for your time.

You last example shows pretty well what disturbs me.

If you take a look at my original message, it's not so different to what I tried first:

class RoundedBoxWithHole(_.Box):
    def __init__(self, length, width, height, hole_diam, fillet, **kwargs):
        super().__init__(length, width, height, **kwargs)
        self.make_hole(hole_diam)
        self.make_fillet(fillet)

def make_hole(self, hole_diam):
    self -= _.Cylinder(hole_diam, self.height)

def make_fillet(self, fillet):
    self = _.fillet(self.edges().filter_by(_.Axis.Z), 5)

The main difference is that your methods return self.

First, I don't understand the point of affecting the object to self. You can get the same result with:

class HoleBox(_.Box):
    def make_hole(self, hole_diam) -> Self:
        return self - Hole(hole_diam, self.box_height)

Secondly, while returning a new object can be useful for expressions chaining, I would like to be able to actually update the object itself:

class HoleBox(Box):
    def make_hole(self, hole_diam) -> Self:
        self -= Hole(hole_diam, self.box_height)

hb = HoleBox(10, 20, 30) # using inherited constructor
hb.make_hole(5) # method updates the object
show(hb) # -> box with a hole

Note that directly assigning to self is considered a bad practice, so ideally we should be able to use a method for that, like self.cut(Hole(...)), but that's another topic.

From what I understand, with build123d we basically just create new object every time and we never update them, which is a bit of a shame. Is there a reason for that?

[lypwig]

Here is an example of the benefits of the do_cut defined above:

class BoxWithNotch(MyBox):
    def make_notch_v1(self, length, width):
        hole = Box(length, width, self.box_height)
        return self.cut(hole)

    def make_notch_v2(self, length, width):
        hole = Box(length, width, self.box_height)
        self.do_cut(hole)

obj1 = BoxWithNotch(30, 20, 10)
obj1.color = "green"
obj1 = obj1.make_notch_v1(15, 5)
# obj1 = obj1.make_notch_v1(5, 15) # AttributeError: 'Compound' object has no attribute 'make_notch_v1'

obj2 = BoxWithNotch(30, 20, 10)
obj2.color = "green"
obj2.make_notch_v2(15, 5)
obj2.make_notch_v2(5, 15)

show(_.pack([obj1, obj2], padding=5))

With make_notch_v2, which use do_cut instead cut, I can keep track of the object attributes (here color) and I can reuse the defined class methods (here make_notch_v2):

[Jojain]

You can do that definitely. The design approach used in build123d is different.
The philosophy is that you have a set of objects that you combine in different ways. The only thing that gets mutated is the representation of the part.

Now it is up to you to do how you like !

[gumyr]

The entire field of functional programming is based on this idea, but you can use both mutable and immutable objects with build123d as you like. Here is a short description by ChatGPT:

A fundamental principle of functional programming is immutability, meaning that once an object is created, it cannot be altered. Instead of modifying existing objects, functional programming relies on creating new objects with the desired changes. This approach minimizes side effects and makes code behavior more predictable and easier to test, as functions return the same output for the same input without relying on or altering external states.

In contrast to the mutable state in imperative or object-oriented programming, functional programming emphasizes pure functions and referential transparency. Pure functions operate only on their input parameters and return new values without modifying any state, contributing to the overall reliability and modularity of the code. This immutability is often facilitated by using data structures that are inherently immutable or by treating data as if it were immutable by not modifying it directly.

[lypwig]

Thank you.

I have the feeling that we have a lot of trouble understanding each other. I understand what is functional programming and the principle of immutability, I didn't ask help for that.

This topic was more about using object-oriented programming in build123d, as stated in my very first sentence of the original post:

I would like to embrace python's OOP with build123d, I think it's a good paradigm to deal with cad models.

Although at first I wanted to confirm that mutating build123d objects was not possible without modifying the library, at this point I don't really need technical advice but I just want to enjoy a general discussion about using oop in build123d.

Python, while being multi-paradigm, is more focused on OOP than a functional language, so I wanted to actually use build123d with the OOP mindset.

So maybe OOP is not really suited to cad design, I still don't understand why for now but I might some day. Or maybe it's suited for cad libraries users but not for cad libraries developers because side effects makes it too complicated.

As far I can tell for now after doing my simple tests, it just feels more intuitive and practical for me. Because I can make a connection between a conceptual object and a physical object (both have some properties, etc.). I will create create a branch in my build123d fork to add some mutable methods, just to see if it's more practical in use. :)

[gumyr]

build123d is specifically designed as an Object-Oriented (OO) programming library, leveraging OO principles extensively to provide a powerful and intuitive experience for CAD modeling. The essence of OO programming lies in three key principles:

• Encapsulation: Bundling data (attributes) and behaviors (methods) together. For example, the bd_warehouse hole classes encapsulate all relevant fastener data, enabling users to specify a fastener without needing to manage the underlying details.
• Inheritance: Allowing classes to inherit behaviors and attributes from parent classes. In build123d, foundational classes like Edge and Face inherit from the Shape class, while users can leverage inheritance themselves, such as by creating custom objects through classes like Box as described above.
• Polymorphism: Enabling objects to be treated as instances of their parent class or interface. All build123d objects follow this principle, ensuring a consistent and flexible interface for users.

While mutability is often associated with OO programming, it is not a core principle. Instead, it is one of many design choices—and one with several challenges that immutable objects can help address:

• Thread Safety: Immutable objects can safely be shared across threads since they cannot be modified after creation.
• Reliability: Immutable objects eliminate unintended side effects, making code more predictable and easier to debug.
• Encapsulation Strength: Immutability enforces stronger encapsulation, preventing the internal state from being unexpectedly altered.

In summary, build123d is built on a solid foundation of OO design because it is an excellent paradigm for modeling CAD systems. Immutability is embraced where it enhances the robustness and predictability of the system, ensuring users can focus on creating accurate and reliable designs.