Do non-OOP paradigms support concepts such as encapsulation?

Question

One of the important concepts in Object Oriented Programming is Encapsulation. However, lately the software world seems to be tilting in favour of other paradigms like functional programming.

It makes me think, what about encapsulation and other OOP tenets? Are they wrong?

Is it that OOP is applied wrong? For instance Alan Kay is noted for saying in the OOPSLA'97 Keynote: "I invented the term object-oriented, and I can tell you I did not have C++ in mind."

Joe Armstrong - "Objects bind functions and data structures together in indivisible units. I think this is a fundamental error since functions and data structures belong in totally different worlds."

Answer 1

I think the trap you fell into here is thinking that there is a rigid definition of any programming paradigm (structured, object-oriented, functional, et. al.)

If you ask two different developers what OOP means, you will get two different answers. Yes, as a profession we agree that there are a few common themes such as encapsulation, data hiding, etc. covered by any OOP software engineering class in college.

However, in the real world, things are not quite so cut and dry, which is why two developers will give two different answers. Perhaps they are experts in different languages that express OOP concepts differently. Language paradigms tend to overlap. The latest rage as of 2013 or so is incorporating functional programming in object-oriented languages through closures or lambdas. Is Java 8 object-oriented or functional? I would call it object-oriented with a dash of functional. Someone else might describe it differently.

Is it that OOP is applied wrong?

No, the issue is that various languages express programming concepts differently. Perhaps one language leaves out an OOP concept, and another language includes it but leaves out a different OOP concept. Languages are typically designed for a purpose: to make a certain type of task easy, at the expense of making other tasks more difficult. That is neither right nor wrong, it is simply a real-world tradeoff that is impossible to avoid.

The real world is not the classroom. We either need to discuss conceptual programming paradigms at the abstract level, or we need to discuss real programming languages that are forced to make tradeoffs in order to be useful. As long as a programming language is mostly defined by an abstract definition of OOP, we can include it in that bucket.

Answer 2

However, lately the software world seems to be tilting in favour of other paradigms like functional programming.

That is debatable. First, I don't see any other paradigms besides OOP and functional programming which are discussed that broadly, so I guess we can forget the "other paradigms like" phrase, let us talk about FP, nothing else.

The reasons why functional programming became so popular over the last years were discussed in other questions here in depth, I am not going to repeat this (see here or here, for example). But, in my opinion this is not because "OOP was a big mistake", or "Functional vs. OOP are mutually exclusive", it is more like people extending their toolbox and try to get the best of both worlds. Ok, there are surely experts which are hardliners favoring one over the other, but you will find those guys on both sides.

It makes me think, what about encapsulation and other OOP tenets? Are they wrong?

Encapsulation has many different flavors. Functional programming languages and language constructs provide certain forms of encapsulation, object oriented others. If you are looking for examples of encapsulation with functional means, start with closures.

Concerning "other tenets": no, they are not wrong, but for certain scenarios like high scale parallelization, functional approaches probably scale better. For other scenarios, like creating well designed UI frameworks, OOP approaches scale probably better (YMMV, I don't just have a better example at hand). Moreover, I am sure for most real world scenarios it depends on the knowledge and experience of the team with its favorite programming paradigm how well a certain system will scale.

Is it that OOP is applied wrong? For instance Alan Kay is noted for saying in the OOPSLA'97 Keynote: "I invented the term object-oriented, and I can tell you I did not have C++ in mind."

Surely OOP is often applied wrong by many people, but I am sure the same is true for FP. And I would be astonished if John Mc Carthy (designer of Lisp) had something like Javascript in mind when he was thinking about functional programming (mercy on me, don't flame me too much for that comparison ;-)

Joe Armstrong - "Objects bind functions and data structures together in indivisible units. I think this is a fundamental error since functions and data structures belong in totally different worlds."

I guess the inventor of Erlang has some good arguments, but he has also his very own point of view, so let him his opinion and build your own. There are lots of other experts which have a different idea of this.

Answer 3

Of course:

struct Foo
{
    string bar;
    int bux;
}

I know what you're going to say: "But that doesn't also encapsulate behavior!" Well, I'm with Joe Armstrong on this one: you can write entire programs or operating systems without ever requiring first-class objects. Linux proves that.

Javascript programmers routinely encapsulate state and behavior in functions and closures, not classes.

Answer 4

The main issue here is that Encapsulation is not rigidly defined concept nor why is it useful. Doing some research shows that how people see encapsulation is highly opinionated and that lots of people confuse it with Abstraction.

First definition you are going to find is

Encapsulation is a concept that binds together the data and functions that manipulate the data ...

If this is your definition, then majority of languages have way to group data and functions operating on that data into classes, modules, libraries, namespaces, etc..

But I would argue that is not the main purpose of encapsulation, as that definition continues :

... , and that keeps both safe from outside interference and misuse.

Wikipedia also agrees on that :

A language mechanism for restricting direct access to some of the object's components.

But now, we need to ask what is meant by "interference and misuse" and why should direct access to the data be restricted. I believe there are two reasons.

First is that limiting scope in which data can be mutated is in developer's best interest. Way too often there is need to have logic before/after value is set. And having only limited number of places where value can be set is extremely valuable. In OOP languages this can be done using classes. In "mutable" functional languages closures serve same purpose. And because we know classes = closures, it is even arguable than mutable functional languages are different "paradigm" to OOP.

But what about immutable languages? It doesn't have problem of mutating variables. This is where second issue comes in : binding functions and data allows to keep that data in state that is valid. Imagine you have immutable structure for Email. This structure has single string field. We have requirements that if you have value of type Email then that field contains valid address. In OOP's encapsulation, this is easily done by declaring that field private, providing only Get method and having constructor method that only succeeds if passed in string is valid address. Similar thing with closures. Now, for immutable language, it would need way say that structure can only be initialized through specific function and such function can fail. And I'm not aware of any language that would fit that criteria (maybe someone in comments can enlighten me).

Last issue is what is meant by language "supporting" encapsulation. On one side there are languages that allow enforcing of encapsulation, so that code won't compile if encapsulation is broken. On the other side, the language might provide way to do encapsulation, but it doesn't enforce it, leaving developer to enforce it themselves. For the second case, any language that has structures and functions can work. Dynamic languages and Haskell come to mind. And I would say there aren't many languages that fall on the other side of the spectrum. Even C#, which is really good at enforcing encapsulation for it's objects can be bypassed using reflection. But seeing that in C# would be considered massive code smell and no sane C# developer would do that willingly.