4 ms·
I suppose it depends on your language. For example, if you're working in Java 8 where everything's just one big jumbled globally visible classpath, sure. If, o
by mumblemumble 6y ago
I suppose it depends on your language.
For example, if you're working in Java 8 where everything's just one big jumbled globally visible classpath, sure. If, on the other hand, you're working in Java 9 or later, you have the ability to control your public interface. People can get around that with reflection, so it's technically more permeable than a service boundary, but, if you're letting shenanigans like that sail past code review, you get what you deserve.
- 100011_100001 6y agoPerhaps the dev culture I am in is skewing my perspective. There have been developers that have changed private methods to public just so that they can access them. You make a good point, it's a code review problem and by extension Architecture teams not communicating effectively with Dev Leads.
- rowland66 6y agoI agree, and packages and package private access is such a powerful tool in Java, that so many developers completely ignore.
- mumblemumble 6y agoLargely because it's not that powerful. It's got several shortcomings, but the main one is that Java doesn't actually understand Java package organization conventions. To Java, "com.mycompany.stuff" and "com.mycompany.stuff.specialized" are two completely unrelated packages, and so stuff that's package-private to "com.mycompany.stuff" is inaccessible from "com.mycompany.stuff.specialized". That and a few other details make the feature annoying enough to use in practice that most people just find it's better to just stop using it. Fortunately, if you're on Java 9 or later, there are modules, which are a much better fit for what kinds of access control tooling programmers actually need.