Object-wdnflected programming

Object-orientation is a powerful way to organise code but it harms as much as helps when it's overused. The largest failure of OO has been for web-services. I gave a talk on this back in early 2014, and wanted to share it.

What is OO?

OO means different things to different people. In this article I take a simple definition, which I think has a lot of weight as it's the definition from Alan Kay, the originator of OO:

OOP to me means only messaging [and] local retention and protection and hiding of state-process

secondly Alan states:

TODO objects are smaller idea, real idea is messages

So OO is a model for programming that can be implemented in many ways. It's specifically NOT classes, which is one way of implementing objects. It's specifically NOT certain languages, you can trivally produce objects in any language.

A particuarly pernicious idea is that OO is about modelling. It's pernicious because although we're writing code to help real-world people, our problems are code problems, not real world ones. Our code should be shaped by the needs of the program, not of the real world.

Why OO?

OO is fantastic where we have something in our programs with identity and state that changes during the program's execution. It was born in the user-interface, and with good reason. UI components have identity and state - we need to track what the user has put in a text box, for instance, and the text box is definined by its identity not its content. TODO more specific

As a counter-example, let's consider the code problems we're faced with in responding to a HTTP request. HTTP is stateless: it can logically be thought about as a transformation of the user's input into the response. It has no time component - it is a single action which doesn't change through the generation of the response.

Where are the objects - with identity and state that changes - in an HTTP request handler? There is no state to change. We parse the input - statelessly. We retrieve the current state from storage - statlessly. For GET requests we transform that state into the response, and in the case of non-GET requests generate a new state and store it. There are no objects with identity that are mutated. It can be brought right down to:

function abstractGET(input, state, transformToResponse) { return transformToResponse(input, state); }

function abstractPOST(input, stateBefore, transformState, transformToResponse, storage) { var stateAfter = transformState(input, stateBefore); var storageResult = storage(stateAfter); return transformToResponse(stateAfter, storageResult); }

TODO need better examples

If we involve objects with mutable state suddenly our code does not match our problem. We have stated we are dealing with time and identity, when we are only dealing with values. Objects' ... CONTINUE

TODO code problem - is there a good phrase for this? the concept of 'the problem we're faced with in writing a program' - it's distinct from the domain