Structured Object-Oriented Programming


Harrison Ainsworth

[Subject: software engineering > rework structure > language]

Structured Programming proposed a limited set of forms – only sequences, conditionals, and loops – for building all procedural software. The intended primary benefits were:

  • uniformity of complexity – complexity “is proportional to program length”
  • a global, subdividable “frame of reference” or “coordinate” space

and these ramify into other details of understanding and manipulation. The whole representation is more ‘logically efficient’.

Is it possible to apply a similar formalisation to Object-Oriented software? Classes seem comparatively undisciplined: on one hand they have a single general form (various methods and fields), on the other there are various loose open-ended conventions (such as Patterns). Structured Programming implies more discipline, like a limited set of interfaces for all classes. And the aim would be making interchange easier by reducing adjustment of interfaces.

Functional programming suggests something of a direct analogue to the three Structured forms, translated into data:

  • map (struct in C, object in JSON) – sequence
  • list (array in C and JSON) – loop
  • sum/variant-type (union in C) – conditional

Perhaps this is the answer. They are comprehensive, and they have a limited set of fixed interfaces – although they disappear into the language syntax.

But the basic data structures aren't quite satisfying: the primacy of data-orientation seems lost, and they are too low-level (and being well-established, they don't add anything new). Classifications of kinds of classes would be better: like containers, iterators, or streams, each defining a pattern of methods. They only exist vaguely/colloquially though; something firmer is needed.

Maybe just strictly defined versions of ‘Design Patterns’ would do, like: Iterator, Strategy, Composite . . .