I learned to program according to the principles of
- structured programming (rather than spaghetti code)
- modular code (rather than monolithic)
- top-down design/functional decomposition (rather than JFDI)
The Idea was:
- you had a big problem that you completely understood and the problem could be decomposed into smaller and smaller pieces of function until you could see how to write them as code (producing a functional hierarchy – a concept similar to dissecting a body, with no significant understanding of anatomy until you had finished)
- your organisation’s data could be analysed and abstractly modelled without any knowledge of how it would be used (producing a data model)
- you could trace the route of all information in the system as it was input from a data source, processed within the system into a different form and output to a data sink (producing data flows & data processing)
Sadly, none of those assumptions were completely true and the systems produced were liable to be hugely disrupted by minor changes if they had not been anticipated – or not – it was fairly random.
I worked in that culture for a few years. I could see what was wrong but didn’t know how to fix it, so I got out of programming and ran systems for people who didn’t seem to have existential issues with their programming paradigm.
I don’t like being beaten by a problem, so I kept a weather-eye on what was going on in software development. I started to hear about Object-Oriented Programming and decided to investigate. It took about three talks for me to begin to understand tiny bits of ‘what the hell They were talking about’, because each time I was told that O-O languages had some of the following features:
- Encapsulation and information hiding
- Objects (with attributes and methods)
- Dynamic dispatch
- Abstraction
- Polymorphism
- Inheritance (or delegation)
Oddly, I didn’t find that knowledge helped me much to understand WHY. I’ve started reading about O-O again this week and I realised in the shower this morning that the object paradigm isn’t just a list of jargon words.
Instead of splattering representations of the things your program is dealing with throughout the functions, with references to many elements of the data structure and data flows, O-O models any of ‘the business objects’ of your organisation that your program needs to deal with. The objects encapsulate their local functions and data. Objects don’t change as often as functions so changes are localised.
The connections between the objects are represented by message-passing. If things have to be taken apart later, as relationships between real objects change or are replaced, the connections can be re-made to represent the new reality.
The O-O model represents “small systems, loosely joined”, like Unix. If someone had just pointed that out, it would have helped me to understand. So I’m saying it here, now, in case it helps you.
Without O-O, I don’t think the Agile software development revolution could have happened, because the early uncertainties and ‘sketched solutions’ of Agile would have had too great a cost of change, later.
On The Outside 