Who does it "protect the data" from? Are you thinking it "protects" the data from the poor schmuck programmer who gets stuck trying to add a simple feature to the mountain of framework code (that instantly becomes legacy the moment it's deployed to prod) that some OOP fundamentalist left behind when they've long-since left the company? Only the data that should be easy to inspect or modify is marked 'private' (and therefore can't be altered even in a derived class). To make matters worse, the OOP fundamentalist didn't anticipate all the ways that someone coming after them might want to use the code, so the "interfaces" which are supposed to cleverly provide access feel like trying to fit a Escobarian hippopotamus in a tutu.
I used to be one of those OOP purists, until I realized the following.
1. Businesses evolve. Use-cases evolve. Hell the very concept of a project itself will evolve over the course of the development cycle, during testing, integration testing, and again after deployment. Whether one uses agile or whatever flavor-of-the-era development methodology one wants to build a campfire around, I have yet to see a single case where this hasn't been true in the more than 35 years I’ve spent in software development. The stuff that doesn't evolve is the stuff that isn't being used.
2. No matter how creative you are when you're designing the perfect OOP framework, no matter how well your object framework is designed, a few observations are more than likely true:
a) Your users will not necessarily use it the way you intended.
b) Your users will find ways to use it that you didn't think of in your original design. Writing a service? Well guess what, I can promise you that the consumers of that service are going to say, "Hey, can you provide an operation for me to do this?" Many times it's something that you were clever enough to think of beforehand. Just as many times, you're going to say to yourself, "Hmm."
3. Let's say that time has passed, your software (built on your framework) has gone live. It's not entirely unheard of for a senior developer or architect to move on, possibly on another project, possibly on another contract, possibly at another company.
4. Some poor schmuck is then going to have to come in after you and will be required to reconcile points 1, 2 and 3, possibly in a two week agile cycle. After spending a considerable amount of time trying to understand the intent behind the legendary framework, time spent tracking down the myriad of interfaces and trying to figure out exactly which class got called during testing (or worse, production), and where that code lives (I have a pattern that I always keep a Visio clone handy and start drawing out interface and inheritance diagrams), when they finally find the data element or method that needs twiddling, they are going to think to themselves: "Well I see the data, but because it’s declared private, I can't change it, not even if I derive the class. Wait, why can't a derived class directly change this data? That would make my job so much easier."
So yeah, I get that security is a very real thing, but anyone who really wants to get at your stuff is going to de-compile the byte code or disassemble the IL code and directly manipulate the memory anyway. So the people you're "protecting" the data from are the programmers who are trying to make use of the framework that you wrote. One of whom is possibly cursing your name and can't wait to jump at the opportunity to throw it all away and re-write it to "la langue du jour."
