Skip to content
June 22, 2012 / jeroencoenders

Objects in NetworkedDesign

As I promised, I will gradually explain the concepts of NetworkedDesign on this site. If you have any questions or comments, feel free to use the comments section on this post.

Examples of NetworkedDesign objects

This first post discusses one of the most basic concepts NetworkedDesign contains: objects. NetworkedDesign largely follows the object-oriented paradigm (OOP) of modelling the world as objects which can have properties, relationships and behaviour. Objects can be inherit from parent objects, which means that they have the same properties, relationships and behavior. However, because NetworkedDesign is a bit different from a programming language, there are also some differences.

First of all, objects are initially empty containers. This means that they have a name and a type, and some other things the system can recognise them with, but nothing more. The user is now free to start defining the objects by applying methods to the objects with all properties and relationships to the object. Methods, properties, relationships, etc. will be discussed another time. This has some advantages:

  1. Objects in NetworkedDesign carry the minimal data and behaviour with them, which means that they are very lightweight and just have the things they need.
  2. Objects in NetworkedDesign can become anything the user would like them to be. So, if you want to derive your own special point type, you can simply add some additional methods and you have your point type. This is especially useful with you are e.g. working on data exchange between two different applications (interoperability). If one application defines a beam by two sets of x, y and z coordinates and the other application defines a beam by two points by the two sets plus a section shape, it is easy to build a BeamApp1 and BeamApp2 object which are slightly different and transfer the data between the two (will also be discussed at a later stage how you can do this).

Second, objects do not define their own behaviour. The methods take care of this. So, a line does not know its length until a LengthCalculationMethod has been added to object. Advantage is that the objects do not do any unnecessary calculation, which makes the system lightweight.

Third, objects have representations, actually as many as you like. Everything you see, including the graphical interface on the system, is a representation that defines how the object is shown and what interaction is allowed. You can easily activate and deactivate sets of representations to set up drawing your objects in different systems. In a later post I’ll explain more details about representations

These are some of the basics of the object concept in NetworkedDesign. I might get back to this topic once I have introduced more of the other concepts to you.

I hope you enjoyed this first post. Again, if you have any questions, feel free to add a comment.



Leave a Comment
  1. mrca506 / Jul 12 2013 11:38

    Hello Jeroen, I just found your project recently.

    So far it sounds very interesting but I’m trying to understand it better. At the risk of sounding extremely naive, in what ways your infrastructure improves on say CLI (.NET fw)? Is your aim, producing something like a graphical low-level grasshopper? In short, why ‘bother’ with an infrastructure and not designing another framework or application that implements the desired methods? I apologize if my questions are not very technical I am an architect.

    Best regards,


    • jeroencoenders / Jul 15 2013 12:03

      Hi Mauricio,
      Thank you for your comment and your interest in my project.

      CLI is of course a bit more low-level than what NetworkedDesign is aiming at, but if you think about what CLI is to .NET or C#, yes, NetworkedDesign is more or less aiming at a similar goal: to provide a very flexible infrastructure to tie design and engineering systems together. You can think of it as a kind of glue between systems, but it could also act as a base infrastructure underneath new systems or existing systems (will of course need some re-development).

      I have often joked that it is a kind of ‘Universal Business Adapter’ ( between applications and perhaps partially this also has been a source of inspiration. Except for the fact that the original Universal Business Adapter of course has become a term to indicate a system that will never exist.
      NetworkedDesign is build to exist.

      The question on ‘why bother’ has many answers, but to name two:
      1) By using NetworkedDesign you will become solver-agnostic, so you are not limited to the parametric and associative paradigm, but you can use many more paradigms to help model and solve your problem: rule-based logic, optimisation, constrain solving, etc. (solvers will be covered in one of my next posts).
      2) NetworkedDesign is the friend of many modelling systems rather than a new one. This means that it becomes easier to exchange data between different systems and apply many of the concepts in systems that do not implement these concepts themselves.

      I hope this helps. If you would like to know more, post a reply. I will try to answer your questions/comments/etc as much as possible.

      Kind regards,


  1. Properties in NetworkedDesign « NetworkedDesign
  2. Methods in NetworkedDesign (Part 1) « NetworkedDesign
  3. Methods in NetworkedDesign (Part 2) « NetworkedDesign
  4. Methods in NetworkedDesign (Part 3) « NetworkedDesign
  5. Assemblies | NetworkedDesign

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: