What was the problem with keeping data and methods separate?

Answer 1

There is no problem with keeping data and methods separate. Encapsulating data with the methods that operate upon the data doesn't actually resolve anything, it merely helps us to express the relationship between the data and the methods in code. But we still require methods that are completely separate from the data. For example, a function that operates upon two different data types cannot be a member of both data types, it has to be separate from at least one of them.

The problem to which you allude is not the fact that data and methods are separate but the fact that the data itself is publicly accessible and can be modified by any function regardless of whether the function is a member of the type or not. The compiler cannot help us because user-defined types are user-defined; it has no knowledge of which operations are valid and which are not.

Encapsulation not only introduces the concept of member functions it also introduces the concepts of private, protected and public access, as well as the concept of friend functions. These concepts do not exist at the machine level, they only exist at the programming level and are simply an extension to the procedural programming paradigm. Behind the Scenes, the data is still public and the functions are still separate; calling a member function is merely syntactic sugar-coating for an ordinary procedure call.

Encapsulation essentially allows us to inform the compiler as to which functions may gain access to which data. This helps to eliminate many potential errors at compile time, but also reduces the amount of code we need to write by eliminating runtime checks that would otherwise impact upon performance. In short, the more the compiler knows about our user-defined types, the more it can help us to eliminate errors in our code, and encapsulation is just one of the tools we use to provide that information to the compiler.