Dynamic association

Dynamic association is my new 'magic' programming model that allows objects to be collections of functionalities that are dependent/independent of each other as needed.

Most developers are used to inheritance (is-a) or containment (has-a). There advantages are many and most applications today, use them heavily in their application design. I see association (use-a) as the new way for designing the applications of the future.

Inheritance requires heavy amount of design ahead of time of a project. It requires heavy commitment with calculating what should use containment and what should be inherited. While it does sound great on paper, in real world situations where projects change over time, I have noticed that inheritance unless designed heavily before hand, just does not stand the test of time. Designing complex inheritance relationships ahead of time is not always feasible and over big projects with lots of developers make it a real headache.

My solution of course is 'dynamic association'. Dynamic association allows components to be small, concrete and encapsulated but be part of the same objects. Instead of designing inheritance ahead of time, you dynamically associate (attach/detach) components to objects at run-time. If a window uses hierarchy, just attach the node component to the window object. If the window needs input, just attach the input component to the window object. The association is on the object, not on the component (class).

Its based more on the real world model. A chair is a chair because it has chair abilities. You can sit on a table, so is a table a chair? Of course not. So should you derive the chair from the table or the table from the chair? With dynamic association, you don't need to. If it started as a chair, attach an object to a chair component. If it later on has a table usage, attach a table component to the same object. Its not what an object is, but what it does. Once components are attached to objects, you can cast between the different component instances attached to the same object.

I know its going to take me years to convince developers of this model, I am meanwhile using it heavily in Screens. Its allowing me to write functionality faster than ever, keeping each component to a very small size and all written in native C without macros gives me a lot of clarity which higher level languages lack. C's simplicity in its language features and its code portability allow me to target multiple environments easily.

I hope to continue pushing out components, so developers can see the advantages of dynamic association and start using it in any project. If anyone wants to see what it looks like, check out in the code attached to the post below: http://screensenvironment.blogspot.com/2010/08/first-draft-of-object-storage.html

First draft of Object storage

The code can be downloaded at: http://www.box.net/shared/9i4g3mbo5m

Note that the code is a draft and while it does compile in VS2010, it has not been tested very much.
Its just to show the direction I am taking with the Component based programming code.
The licence is public domain and Screens is staying that way for the foreseeable future.

I am now working on the component CoreShadow which allows a component to link
to another component instance of a different component without controlling the linked component instance life-cycle but still not having a dangling pointer. The idea is that components only really control their own instances, not instances of other components unless they are maintained by the component instance itself.

This is dynamic association. CoreObject allows to attach different components together to form an object. Components can be attached or detached from objects, or sent dynamically bind messages to them. All written in native C with no macros. Why use component based objects? It allows to add or remove functionality from objects at run-time with data. Most other languages support adding interfaces but not adding data dynamically. Component based programming using the attached files allows to add also an interface and data to any object.

Because the association is done at run-time, components do not need to be created just because the associations are slightly different. Components are like classes in Java/C++ but do not use inheritance but rather association. Whats the difference? "Inheritance = is a relationship" while "Association = use a relationship". Its a subtle but powerful difference. Instead of deriving types, an object is a combination of different types that together form a single concept.

I know that this is not a known programming relationship but I will explain it better as time goes on.
Meanwhile feel free to peak into the code and enjoy.