Procedural, class-oriented, role-driven: history of programming in 80 minutes

Friday, 6th of November 2009 at Øredev. The time had come to sit in on the one of the main attractions of the conference. A talk by the man to whom many of us developers owe their career. (If you have worked with Object Orientation and Model-View-Controller you belong in that category).

Trygve Reenskaug made a monumental talk about rethinking the foundations of Object-Oriented development that spanned the three "ages" of programming: its genesis, the difficult maturing stage, and the recent breakthrough at a higher level.

The first part, "Procedure Orientation: Success" detailed the dawn of programming discipline where chunking code for readability and testability were good practices. Developers used to review each others' code to find bugs; failing early was considered good. If this sounds like something you've heard before, you're right. Procedural programmers of the day were Agile by default. They found what worked and stuck to it.

The next stage ("Class Orientation: Collapse") was more complicated. By that time, it was decided that a program should model the real world by mirroring its objects. Accounts, Users, and Money were represented in classes that at runtime had certain behavior, roles, and responsibilities. This was a major cognitive breakthrough for developers, however it also resulted in a dangerous chasm. To stakeholders, the program was a dynamic system with a certain behavior. The implementors had to deal with a different picture: all this behavior had to be represented using primitives that were static in nature: classes, attributes, objects. Stakeholder - developer communication became complicated.

Enter the last stage ("True OO: a new beginning"); the revival of "true" Object-Oriented development. Now, we are back at what objects were SUPPOSED to do in the first place. An object is something that plays a role. And a role exists in a certain context. (Like acts in a theater play are contexts for roles?) That is crucial. Without context, everything is static. Add context, and everything comes alive; roles can be injected into objects at runtime (context is dynamic!). By now you're probably wondering what exactly these roles are - how do you code them?? While getting into the gory details seems to be overkill for this blog (and would do no justice to Trygve's talk), consider this: roles are something that can have methods!!

With this renaissance of Object Orientation, best practices suddenly shine again. Peer code reviews become meaningful, because now you'll be reviewing both the class AND its context! This is responsibility-driven design.

This has no doubt been of the most memorable sessions of Øredev. I'm glad I attended it  - otherwise I would have missed something that is crucial to the programming discipline and where it is going today.