#060 - Object Oriented Engineering | A Useful Framework for Thinking

Modularity, Reusability, and Scalability in Engineering Practice

Greetings all 👋

A slow start for me in 2025. I have been busy with family duties and various other commitments. Any fleeting moments of freedom are currently being squandered on a digital drum set, to questionable effect, and a rather brutal reacquaintance with the BJJ mats.

But I’m back on the horse and we must endure.

Today's discussion centers on a cognitive framework, a particular approach to thinking that I have found helpful in my own process of understanding.

---

Object-oriented thinking. It's a phrase that gets thrown around, usually in the context of software development. But its implications extend beyond programming. It's a powerful mental model, a shift in perspective that can significantly augment our approach to problem-solving, design, and even project management.

The core idea is deceptively simple: view the world as a collection of interacting objects.

An object can be anything: a beam in a structure, a meeting on a schedule, a concrete pour, or even a document in a project file system.

Each object has properties, or attributes, that define it. Our structural beam has a length, a material, and a cross-sectional area. Our meeting has a date, time, attendees, and an agenda.

Furthermore, objects can perform actions, or methods. The beam can bend under load. The meeting can be rescheduled or canceled. This combination of data and functionality encapsulated within an object is the essence of object-oriented programming, but this logic is applicable to basically any technical field.

Here's a simplified explanation of Object Oriented Programming (OOP):

• OOP helps us model complex systems using "objects."

• Objects represent real-world components:

  • Attributes: Properties of the component (e.g., material, dimensions, axial/bending/shear capacity).

  • Methods: Actions the component can perform (e.g., calculate bending stress, deflect, rotate).

• Classes are templates for creating these engineering objects.

• Example:

  • Class: Beam

  • Object: beamA (a specific beam in your design)

  • Attributes: beamA.length, beamA.material, beamA.load

  • Methods: beamA.calculateStress(), beamA.getDeflection()

While there are more advanced aspects of OOP, such as polymorphism and encapsulation, those are topics for another discussion.

Now, why should a practicing engineer, perhaps one more familiar with spreadsheets and FE software than with classes and inheritance, care about this?

Because this approach mirrors how we intuitively understand the world. We naturally break down complex systems into their constituent parts. Adopting a formal object-oriented approach simply refines and structures this natural inclination.

Consider the project management example from earlier. A "Project" is an object. It contains "Schedule" objects, "Design" objects, "Budget" objects, and so on. Each of these, in turn, contains other objects. The "Schedule" contains "Meeting" objects and "Milestone" objects.

This hierarchical structure allows for a clear organization of information and responsibilities. You will start to notice the natural hierarchies that exist in every system once you put your mind to it.

But the benefits go beyond organization. Thinking in objects promotes modularity. Each object becomes a self-contained unit, responsible for its own internal workings. If you need to change the way a structural element is designed, you modify the "StructuralElement" object or perhaps a more granular object. The change is localized, minimizing unintended consequences elsewhere in the project. This modularity is the bedrock of maintainable and scalable systems. Whether you are dealing with physical structures or enormous software projects, the same principles apply.

This leads to another significant advantage: reusability. Once you've defined a well-designed "Beam" object, you can reuse it across multiple projects. You can even create specialized types of beams, like "Precast_I-Girder_01A" or "W14X120," that inherit the basic properties of the "Beam" object and add their own specific attributes. This inheritance mechanism is a cornerstone of object-oriented programming, but again, the logic of it applies everywhere.

I'm not advocating that everyone should become a hardcore object-oriented programmer. But understanding the underlying principles can dramatically improve your ability to manage complexity. It encourages a more systematic, structured approach to problem-solving.

Take, for instance, a challenge I'm currently grappling with: integrating BIM workflows with earthworks modeling. These are two distinct domains, often treated as separate silos. But if we view them through an object-oriented lens, we start to see the connections.

A retaining wall in Revit is an object. A cut slope in Civil 3D is also an object. Both have geometric properties, material properties, and relationships to other objects. The challenge then becomes defining these objects clearly, identifying their commonalities, and establishing a robust way for them to interact.

I've looked into commercial services like Autodesk Construction Cloud, Speckle and more recently FreeCAD, but applying them to the large multidisciplinary power projects I typically work on, each with a multitude of stakeholders, feels like a quest through Mordor.

This is where "The Pragmatic Programmer," by Dave Thomas and Andrew Hunt, a book I highly recommend, comes in. While not exclusively about object-oriented programming, it emphasizes the importance of flexible, adaptable thinking. It encourages concepts like orthogonal design, which aligns perfectly with the modularity promoted by object-oriented principles. The first 50% of it is applicable to general engineering principles - then it slides into more programming and development specific weeds.

Similarly, Peter Debney’s ‘Computational engineering’ is full of practical advice and ‘engineeringisms’ that help you think more clearly. I talk with Peter about it in more detail here:

#050 - Flocode Podcast 🌊 | Peter Debney - Computational Engineering

Ultimately, object-oriented thinking is about adopting a powerful mental framework. It's about seeing your problem not as a collection of disparate parts, but as a network of interconnected objects, each with its own role to play.

It's a framework that scales, that promotes clarity, and that, quite frankly, makes you a better engineer.

It helps to eliminate the gray areas between disciplines, or between software platforms, or between design and construction.

Embrace it, and you'll find yourself approaching problems with a newfound clarity. Like anything it’s a skill that must be nurtured and developed to see the benefits.

As engineers, we are always searching for unified theories, and I believe this is a strong step in the right direction.

Be good out there.

See you in the next one.

James 🌊