Skip to content

Technical philosophy of the BHoM

Jump to bottom Edit New page
Chuck McCallum edited this page Mar 13, 2021 · 3 revisions


Technical philosophy of the BHoM

The Buildings and Habitats object Model [BHoM] has been designed as a hybrid model for code architecture - integrating a number of concepts from across existing languages/platforms. Think of your favourite aspects of GH, C# and MongoDB combined.

Specifically the BHoM has a data structure and data manipulation strategy which is directly compatible with both visual flow-based programming and text-based imperative code.

The aim being to enable seamless transition from design and code experimentation to prototyping to development and deployment with increased participation and co-creation, and greater rigour, review, robustness and transparency in our scripts, our code and the tools we use.

For the AEC industry this means a platform for combining the efforts of the professional programmer through to the enthusiastic computational designer/engineer/architect all in one coding ecosystem.

The basic architecture

The Buildings and Habitats object Model is organised as four distinct categories of code: object Model, Engine, Adapter and User Interface.


1. The object model [oM] is nothing more than structured data - a collection of schemas.

The oM is defined as naturally type strong C# classes, but comprising of only simple public Get Set Properties, with all methods excluded from the class definition including even the requirement for default constructors.1
Ultimately, they are very close to C type structures with the added benefit of inheritance and polymorphism that a C# class provides.



2. The Engine is nothing more than data manipulators - a structured collection of components/methods.

All functionality is provided to the base types through extension methods in the Engine and organised as static methods within public static partial classes. Immutability is enforced on inputs of each method to enable translation to flow based programming environment.



3. A common protocol for adaptors enables a single interface irrespective of the external software dealing with.

IO and CRUD concepts are combined to enable convenient Push-Pull visual programming UI with CRUD functions interfacing with the external application.
Crucially the abstract BHoM_Adapter enables centralized handling of complex data merging so that creators of new adapters can focus on what makes their adapter different, reusing what is common and has already been solved



4. The UI exposes code directly. Same terminology. Complete transparency.

Through reflection, all objects, engine methods, adapters - any functionality implemented - is accessible immediately through the UI. This means the same code can be explored through the two contrasting development mediums - either Visual Studio or Visual Programming - but with direct parity.



The approach to coding

The above code structure therefore enables at its core ease of extensibility ...


A. Open, flexible data schemas

The base object class provides a CustomData Dictionary allowing dynamic assignment of any data type to any object. To the extent that a CustomObject is defined as an Empty Object. Default definitions for common objects can be curated and collectively agreed upon, however all are inherently flexible and extendible.



B. Ease of extensibility of functionality too

By structuring the code almost exclusively as extension methods in the Engine this enables new functionality to be added to existing objects without the requirement for derived types or indeed modification or recompilation of the base object. This naturally opens the door wide to distributed development and customisation of new functionality on top of any existing base objects.



and finally, as highlighted, the above architecture and code design principles place mass participation and co-creation as central.


C. Transparency in code

The source code architecture, principles and terminologies are all open, exposed and reflected as a common language across the visual and text based environments as described. This is paramount for a seamless transition from a visual UI to code and vice versa with huge benefits to the developer in debugging and the designer in prototyping and well as a teaching aid to the lower level concepts behind the UI.



D. Human readable data

All objects natively serialisable based on JSON being compatible with MongoDB and standard data format for the web.



A shift from data encapsulation

Despite being one of the pillars of OOP, data encapsulation has been systematically eliminated in favor of a solution more transparent and more closely related to visual programming. This translates into a few interesting side-effects:

A. Node <--> Code correspondence

Since objects have no private members and functionality is represented as a collection of individual static methods, the conversion between code and visual programming nodes becomes a straight-forward exercise.



B. Shallow hierarchies

Most objects inherit directly from the BHoMObject class and polymorphism is expressed mainly through interfaces. This is made possible without duplication of code thanks to the lack of encapsulation and an engine designed around extension methods.



C. Orthogonal properties

With all object properties public, it is paramount for those to be independent from each other. This also means the objects are crafted with the minimal required information needed to construct them. All derived properties are exposed as methods in the engine.



Further Reading





1 By exception IImmutable objects are allowed where calculation of derived properties in the engine requires lazy computation.
Section Profile is a good example

In addition some explicit casting and operator overrides etc. are also included in the BHoM definitions of some limited base objects.
Node is a good example

Add a custom footer

Home

Clone this wiki locally