The problem of Object Oriented Programming is an education one

Over on Hacker News, there's been some discussion about OOP and specifically about inheritance and encapsulation.  The general idea seems to have moved within the discussions from understanding OOP as primarily about inheritance to it being primarily about encapsulation (an excellent read on its own, by the way).

As neilk points out in the HN discussion,

Skillful practictioners [sic] of OOP, even in languages like Java, know this stuff already...To a first approximation, inheritance is always wrong. The Design Patterns book advocates composition...

Here I will point out that the essential problem with OOP, and programming in general, is really that the quality of the code is dependent on the skills of the "Skillful practitioners".

This obvious observation has big ramifications: encapsulation, as enforced by the compiler, is a technological solution to what is a human behavioral problem, and there are many ways of solving the behavioral problems.  The question is which one is more effective.



The purpose of encapsulation, briefly, is to hide information and to restrict access to components of objects.  But why is that important?  The short answer is that doing so prevents users of your code from mucking around with the internals of your component, preventing them from setting that component into an inconsistent state, preventing users from relying on internal parts of that component by limiting interdependency between components and thus creating a more robust system.

It sounds good doesn't it?  Except in the hands of a less skilled programmer, they can get around all of that technological limit by, eg, simply creating one huge, all-encompassing universal class that contains all the variables needed to do anything, then writing all the functions in that one class.

Think it couldn't happen?  But it does happen, and with programs that are in production, used by real end-users, doing real work, and paying real money for the program [1].

The solution, of course, is to educate and increase the skills of the programmer, teaching them the proper use of encapsulation in OOP.  Yes, but if that were effective, then why not just teach them to not write code that is fragile, due to excessive interdependency amongst the modules or classes, to begin with?  Why not just create a culture amongst the programmers to write code that doesn't go mucking around with other people's objects' internal components, unless there's a damn good reason to?


The original problem that encapsulation is solving actually creates a secondary problem that needs to be solved by changing the behaviour of the programmers through education.  And yet, that original problem could've been solved through education in the first place!

As an existence proof that it could be done, observe that this is the solution Python went with (see Object Oriented Programming doesn't need Encapsulation).

So in the end, we find ourselves having to rely on education of the programmer, to increase their skill in writing either code that respects the privacy of the state of other people's modules and classes, or code that creates an effective class structure where each class's respect for the privacy of other classes' internal states is enforced by the compiler.

Either way, we end up having to educate programmers effectively.  So why not cut out the middleman, ditch OOP, and just make better programmers?

[1] I'm currently involved in work on a program whose code base is exactly of that description.