How Objects Naturally Arise

NOTE HXA7241 2016-04-03T12:07Z

Why have objects? They are ‘naturally arising’: components are necessary, callbacks are valuable, and grouping them is good – and there is an object.

Instead of seeing OO as something devised, a way of doing things that was designed, or otherwise deliberate, try looking at OO as antiteleological – as just one of the natural forms that arises from the ‘grain’ of the material of software, and whose usefulness is rather by happenstance.

The argument proceeds thus:

  • Components naturally arise – in building and in knowledge.
  • Callbacks naturally arise – as a shortcut to passing actual code.
  • Groupings naturally arise – by offering a way to components.
  • Conclusion – do not overdo it.

Components naturally arise

Things must be broken into pieces – components – for building to be possible at all. Otherwise, everything would have to be made as a monolithic whole, completely from scratch each time, with no knowledge ever reused.

And with components necessarily comes: 1, interfaces between components; and 2, parameterisation of those interfaces. Parameterisation is really what gives the reusability: with none, a component could only fit in a single place – it would not really be a component, it would still be part of a monolith and not really separate. The range of the parameters allows the component to fit in multiple places.

Callbacks naturally arise

The maximal limit/‘extent’ of a component interface is, in a way, Turing-completeness – the component being parameterised by a full programming language. Rather than the component being configured with a few ‘switches’ or other values, it is controlled with a language that has no computational limit.

But when both component and client run in the same context, in the same form, there is a shortcut: callbacks. Instead of an interface taking source-code text to parse and interpret, or even ready-compiled code to execute, it can take not code but merely a pointer to it. The component is still parameterised by general code, but packaged in a different way – by reference really.

Groupings naturally arise

Software creators seek grouping because it is a kind of inchoate component: finding a commonality, an aspect of simplification, is a step toward finding something understandable and buildable, as noted above.

The salient way of grouping callback procedures is on their shared parameters. And that will tend to boil down to a single one that represents what is common – any that are shared can be factored into one.

So we end up with a set of callback procedures grouped around a shared datastructure ... and there is an object !


Does this mean OO is excellent, right, and obligatory? No. It is one structure that has a place.


Now read this other article for further examination of this subject: