Objects, Domain Objects, Object Orientated

Todays intelligent software vendors will tell you you'll be using their softwares to "build" model, not to "draw" model. They also tell you they have a whole set libraries of "objects" accompanied with their solution for you to build a virtual building in a flash of light.

"Trash it or boss fire me!" illustrator thought.

"No, their library don't suit my practice." boss said.

"Are you sure they legally comply?" architect asked.

"There's no hyperbolic-shape wall? It's crap!" designer commented.

Me sarcastic? No! Not even a tiniest sense.

If a piece of software is not designed to work your way, you expect the whole company work their way around to suit the tool, would you?

All 4 people spelled out their concerns very right. Unfortunately at the same time they made certain preconception about the capability of current softwares designed for AEC industries.

Software providers used the term "Object" or "Domain Object" because it's a direct reminiscent of the underlaying programing philosophy: "Object-orientated", or "OO" they used to build these softwares.

In computer world anything can be "Objects": numbers, letters, words, cars, men, cats, values, series of electronic pulses, actions, properties, behaviors ... ... anything that can be abstracted.

When software developer invented "AEC domain objects", they did not merely create parametric model templates so that you could build very fast models. (please read my last chapter titled "Parametric Modeling")

Instead they create "generic object" in first hand: wall, slab, column, window, door, envelope, etc. These "generic objects" do not have geometric particularities yet. So "wall object" could eventually take the form of a horizontal waffle; "slab object" could have a stick-like form.

So what's the meaning and use of these object if they are so "generic"?

Answer: properties and behavior.

Some examples:

1. A window object could not exist alone, it should have a host object to adhere to e.g wall object

2. A slab object will be attached with "floor area" property, while wall object would not.

3. A load path should follow a column object, not envelope object.


With the definition of these very basic classes of object laid down in our AEC world, the software developer start to build up the semantic convention to describe everything (almost) about a building.

"Why tutoring me with these boring talks? I'm not interested in IT anyway!!"

I'm not taking you into IT world (actually I'm not capable), but only to let you understand more about the tools at our disposal.

So, we can see now, the "library of objects" people referred to at the start of this article is merely a second layer of pre-made instruments we could make use to speed up our modeling work.

We could actually build our own "second layer" library based on the "generic object class" provided by the softwares.

The example I showed in "Parametric Modeling" is a custom "second layer object" I built myself. I'm an architect, not programmer. I have been using CAD-based softwares for 12 years.

Here I provide a concept only. How far an application open up the interface for us to build our own domain object varies from software to software.

It's always the hard part to put things into practice. I will cover more practical cases in later blogs.