On the Internet and Object-Oriented Programming
The rise of the internet over the last, say, two decades has been pretty unstoppable (we all know that). But, is it now affecting the prominence of object-oriented programming? I’m going to try and argue in this post that: yes, it is. That is, at least for “classical” object-oriented languages (i.e. not JavaScript).
What is the ‘Net effect?
The starting point of this discussion is to think about how the internet affects programming. It’s not easy to reduce this to some simple ideas, but, still, I think there are useful observations to make…
The internet has become a dominant feature of most programs. This is not saying much. The fact is, most people today are writing programs that in some way interact with the internet. There are so many kinds of programs which do this. Of course, web applications. Certainly, mobile apps. Yes, tools for scraping “big” data of the web. Don’t forget the Internet of Things devices on WiFI which (yuk) like to punch holes via UPnP. There are so many others. And, yes, there are still some applications being developed which don’t do any networking. Embedded systems is one area we see this, and in standard Operating System utilities, and more.
Yes, Dave, the internet is big. So what? We know the internet is all about moving data — bits and bytes. Many exciting data formats have arisen for exactly this, like XML, JSON, Protocol Buffers and even, at a stretch, (yuk) Java Serialization (to name just a tiny few). It’s all about moving data. That’s what modern programs spend a lot of time doing. Reading from a database. Writing HTTP to a socket. Waiting for JSON from a webpage. Data comes in, it gets mashed up and spat out again. And, in that simple process, a lot of amazing stuff happens!
Right, at this point, nothing is controversial. It’s all pretty obvious. So, what’s it got to do with object oriented programming?
Big Little Data
Object-oriented programming is supposedly all about data (for now, let’s stick with SmallTalk, C++, Java, C# as our definition of OOP). Objects encapsulate data, right? There’s even a problem — the expression problem — which suggests OOP is to data as functional programming is to functions. Apparently, OOP is about State, Behaviour and Identity. We want to hide our data in objects to prevent people seeing it and in case we want a different implementation. Polymorphism or Dynamic Dispatch is a powerful mechanism here. That is, you don’t know anything much about the object you’re dealing with. Protection modifiers (public, private, etc) are somewhat less good at this (think: need ownership), but still OK. Yup, reflection breaks this (but that’s not surprising). But, overall, it works pretty well. For example, collection libraries. We want an abstract List interface that can be implemented by different algorithms (ArrayList, LinkedList, CopyOnWriteArrayList, etc). Great. That’s not the problem.But. Most programs don’t usually involve writing collection libraries**. We use ArrayList and HashMap and, probably, that’s about it. So, what do programs do a lot of? Moving data over the wire! And the thing about the wire is that, by definition, it’s not encapsulated. The concept of encapsulation is backward here because data must be completely visible (in some sense). Furthermore, it doesn’t make sense to think about “different implementations” of our data objects. We know exactly what data fields our objects need because that is determined by the wire protocol.
That’s it. OOP is all about hiding your data and leaving your options open. The wire is all about giving away your data in a well defined format. These two things are somehow in opposition. What’s the net effect of this? Friction, of course. The more we use the network, the more of a pain OOP will become…