Tag Archives: objects

Objects vs Functions

I learned to ‘programme computers’ long ago, almost before there was no “me” in ‘program’ and certainly before I knew how to ‘team’. I had a very brief and unsuccessful exposure to functional programming in LISP (not Lisp) then stopped. I did other ‘Data Processing’ things.

In recent years I’ve been working as an analyst, alongside people who write code according to the object model. I think I have a feel for objects but never having written code in an object-oriented language, I can’t be sure. I decided to try, in the Python language, then got distracted by the shiny Clojure language which is functional. I feel that right now I’m approximately equally confused by objects and functions, so I thought I’d write this quickly before I know what I’m talking about. I can come back later to laugh at my naivety, along with the rest of you.

Like the person who wrote this https://news.ycombinator.com/item?id=4246018 ,
I’ve been watching some talks online recently by Rich Hickey of Clojure fame”
The post asks “So if I follow Hickey’s advice, how am I supposed to represent a book? As a vector of vectors of vectors of vectors of strings? If so, then how do I prevent a change in the representation of the Book from breaking client code?”

I found the question very interesting because representing ‘books’ in a functional language is exactly what I want to do. I think differently to the author because  I’m not yet trapped inside the object paradigm. I can see that ‘book’ is a real-world class of objects, a very specific and limited implementation of the representation of a small subset of all the information in the world. That’s what my ‘book’ was going to be about and why I’m now playing with functions instead of writing it.

Objects are good at simulation of real life systems. They encapsulate small sub-systems of a process and it’s local data into an object. What I always struggled to understand was what you did with the data that didn’t want to be enclosed – “information wants to be free”. People seem to cope by inventing objects that don’t really exist: to be data shepherds.

Functions are good at abstraction. A book is a single output format from something much richer. That’s what I want to write. Data and processes are complex. Objects and functions are simplifying models; there may be others.

p.s. (not Lisp) Get it?


Programming Paradigm Objectification

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.