While doing some research on Python, I came across a Stack Overflow question. It was about private fields and methods in Python. As I scrolled through the answers, I caught sight of a very odd response.
This responder (who’s title was “Software Architect”) boldly stated that they worked in Java and Python code projects and have never, ever, written anything (in either language) as private.
They asked, “who am I making this private from? My teammates? My clients, they have the code – they could modify anything they want.”
Here we have a fellow that had 300k+ points for “good advice” and a title of Software Architect, who doesn’t even know the basics of good programming…
Why Encapsulate?
The reason to hide data isn’t some paranoia of your teammates, it’s due to inadvertent access to methods and fields.
Bypassing Logic
Most everyone is using an IDE, especially with Java development. Consider I have a Java class for registration. That class has several private methods. Those methods are called on in steps of the registration process. Perhaps some vetting goes on in those methods. One method might verify the user’s email domain and generate a score, which is passed into a second method that then finalizes registration.
Imagine if these methods are not private. Another team member might need to create a test user or call the registration for a different controller – perhaps to generate administrators.
In the course of a busy day, they didn’t notice the code itself, they simply instantiate the Registration class, and call the registrationFinalization method – passing in the data to create a new user.
In a case where these methods are public, they can be accessed out of sequence and violate the business logic.
Public Endpoint – Security Vulnerability
What if a team member is writing a public endpoint, and calls a method that should be private…. accessing some data directly? Anyone who has access to the public endpoint (i.e. the PUBLIC) could find an inroad into the application.
Modifying / Updating Fields
Consider a case where there’s a class with a field with a password as its value. If not private, then another developer may inadvertently call that class and overwrite that field’s value.
The application deploys with this new bug. When someone kicks off his new logic, they lose a connection to some part of the application (key value store, database, etc.)
Developers spin their wheels trying to figure out how this token has a null value, instead of value in the Class itself. It’s there, the password is right there, how is it getting overwritten? Oh right, somebody didn’t make the field private and some other dev. overwrote it.
Encapsulation exists for a reason. It’s not that you don’t trust your developers, or clients and yes, obviously anyone with access to your code base can tamper with the code… What this creates is a way to ensure the IDE doesn’t simply auto generate a list of available fields or methods for us – methods we shouldn’t be accessing outside of the logic and flow of the application.
No responses yet