DEV Community

Discussion on: What's the case for data hiding?

Collapse
austindd profile image
Austin

While I don’t think OOP is necessarily a great paradigm in most use cases, I think the idea of private fields can be good for at least one reason: preventing unwanted dependencies on flaky internals. Limiting the surface area Of an interface allows you more flexibility to change/optimize the implementation later without breaking the users code. It also signifies the intent of the interface.

That said, you don’t need objects or classes to achieve this kind of “interface refinement,” as I like to call it. It can be done with procedural or functional code as well, depending on the language, with largely the same benefits.

Collapse
yujiri8 profile image
Ryan Westlund Author

My point was that all of the benefits can be achieved with a violable convention like Python's. It still communicates intent, and it only breaks user code if users explicitly decide to disregard that. Semver is the main solution to breaking user code with dependency updates. The same major version can be used to indicate only that there haven't been changes in the public API, not in the private stuff (I don't know that is in fact the expectation in the Python community).

In general, I'm extremely skeptical of going out of one's way to making anything impossible for a user. No one can ever anticipate all the use cases someone might have. Sometimes a hack is the most practical solution. If I can't accomplish something using the public API and I decide it's better to depend on an exact version to get the functionality I need, I don't see much benefit in taking that option away outright.

Collapse
austindd profile image
Austin

I totally agree. I think it’s always a good idea to give more power to the user and see the awesome things they come up with.