Do access modifiers matter?

Question

The theory is that access modifiers improve code safety because they support encapsulation of internal state. When doing OOP, every language I've used implements some kind of access restriction. I like some access models better than others.

I am on a team of Java developers. Our projects spend time in code reviews considering the access modifiers, their appropriateness, and the use of things like @VisibleForTesting (a Java annotation). Our projects also occasionally spend time de-finalizing or de-privatizing something in a 3rd party library if a source-code change is not feasible.

I went looking for the research that shows how the use of access modifiers affects defect density or occurrences of run-time errors. I cannot find any studies on it. Maybe my Google-Fu is weak. What is the evidence that access modifiers actually provide the benefits we assume they do? Where are the studies that quantify the problems with how access modifiers are used?

Answer 1

Let me give you a real world example of when access modifiers "mattered" that I ran into personally:

Our software is primarily python, and one way that python differs from most other OO languages is that there are no explicit access modifiers. Instead, it is convention to prefix methods and attributes that should be private with an underscore.

One day, a developer was working on a particular feature, and could not make it work with the interface of the object he was working with. But he noticed that if he worked with a particular attribute that was marked private, he could do what he wanted to do. So he did it, checked it in, and (unfortunately) it slipped past code review, and into the master branch.

Fast forward two years. That developer had moved on. We updated to a newer version of an underlying library. Code that had been reliably suddenly stopped working. This resulted in lots of debugging and back-and-forth messages with another team in a different time zone.

Eventually we figured out the issue: the developers who owned that underlying object changed the way it worked in a very subtle way. Subtle enough that no exceptions were thrown, no other errors occurred. The library just became flaky. This happened because the developers of that library had no clue that they were doing anything that would cause any troubles to anyone. They were changing something internal, not the interface.

So after the fact we did what should have been done originally: we asked the library developers to add a public method that solved our problem rather than mucking about with the internals of their objects.

So that's what access modifiers prevent. They ensure that the separation of interface and implementation is clear. It lets users know exactly what they can do with the class safely and lets developers of the class change internals without breaking user's software.

You could do this all with convention, not force, as python shows, but even where it's just convention, having that public/private separation is a great boon toward maintainability.

Answer 2

To my experience, the primary benefit of access modifiers is not the number of errors they prevent, so it would not make much sense trying to make a statistics over this.

The real benefit is, especially in large code bases, they facilitate the impact analysis of changes to a code base by several orders of magnitude. And that is something I experience daily. For making a change affecting only private stuff the consequences can usually be narrowed down to a relatively small part of the code base. For making changes to public parts the analysis is often way harder, since a change to a public function in one module could theoretically affect all depending modules.

Of course, even a change to some private function can have consequences on a larger scale, and not every change to a public method affects the code base as a whole. But access modifiers allow us better reasoning about what and where the majority of changes will have (of have not) wanted or unwanted effects, and so let us implement such changes correctly in a more efficient manner.

Let me add that to my experience, for small programs with less than, lets say, 2K lines of code the effect is small, but when you work at a system with >200k lines of code, things look differently.

Answer 3

Access modifiers are a technique for implementing encapsulation. Use them if you seek the benefits that encapsulation provides.

In general, best practices in Software Engineering are not dictated by academic studies or double-blind, peer-reviewed experiments; they are dictated by pragmatism and experience. The evidence is "does it work in real life?" Or (being pragmatic) "do the benefits outweigh the costs?"

It also depends on what your goals are. If you come from a background where brevity is valued over explicitness, you may find that access modifiers do not benefit you at all. But sometimes you don't get that choice. When you work with a team of Java developers, the right things to do are generally the things that fit Java's sensibilities.

When in Rome ...

Answer 4

To complement the existing excellent answers from Doc Brown and from Gort the Robot, another way of looking at access restrictions is as one of many ways we write modular programs.

In the simplest architecture, all variables and lines of code are accessible from all scopes. This would allow you to assemble code in any combination you wanted, and as the program grows, the number of combinations increases exponentially, making it hard to reason about what the program will do.

To improve this, we break down programs into reusable modules of various types. Each module has a contract defining the ways the program can interact with it; and an implementation which is hidden from other code.

The simplest type of module is a function: function signature (name, parameters, and return type) defines the contract; and the implementation can include local variables, and lines of code that cannot be jumped into from outside the function. The number of possible combinations then reduces from all possible interactions of variables and lines of code, to all possible interactions of functions.

Visibility modifiers simply iterate the same advantage: by grouping functions and variables into classes or packages, we can give each grouping a contract and an implementation. The number of possible combinations reduces further, to valid interactions of classes, or packages.

All of this can be implemented by convention rather than as part of the language - you could name global variables carefully rather than having local scope, and you could name functions carefully rather than having visibility. The more universal those conventions are, the more tools can support them - e.g. offline checkers can tell you if you're validating contracts, and IDEs can suggest only "visible" members.

In order to be truly universal, the convention needs to be baked into the language, and enforced by default tooling. This matters most when sharing or handing over code: if most tools read a leading underscore as meaning "private to this class", but the default compiler/runtime doesn't enforce that, you have to make a judgement whether someone else's code uses it "correctly". If you see private in a Java program, you can make pretty strong assumptions about the contract.

Ultimately, it's about trading flexibility for the ability to reason about and maintain the code. Just as there are cases when using goto rather than functions helps solve a problem, there are cases where accessing a private method gets a job done. If the language has not made that trade-off by what it enforces, the programmer has to make the same trade-off by how they use it.

Answer 5

Safety and maintainability aside, it keeps you sane.

Let's make this real world, without the fancy mumbo jumbo. Suppose you get a class library to support you doing your job. You know what it is supposed to do, you just haven't worked with it yet. So you add it to your development environment and look at what's in there.

Wow! 1200 classes! What the... what were these guys thinking? I only need to do whatever so reasonably I should be able to get by with 5, 10 classes tops. And they give me all these. I bet 99% of this is totally irrelevant to me, why don't they just show me the classes that really matter to me?!

So you browse through the name spaces and spot some class name that looks promising. It is called ThisIsTheOneYouActuallyWantToUse. How convenient. You type:

ThisIsTheOneYouActuallyWantToUse instance = new ThisIsTheOneYouActuallyWantToUse();
instance.

and IntelliSense shows you all the methods and properties this class has to offer. Wow! 200 members! What were these guys thinking?! Do I need all those? I bet not. Why did they not just show me the ones that matter to me as a user?

Et cetera. You complain for the rest of the day and you go home tired and disgruntled.

[Edit]

This illustrates the experience of an application developer using a third party library, trying to find a useful method in a relevant class. Note that this issue plays out on all levels. It can be a problem when one developer on a team reviews the work of another. Think of an end user who gets a menu with a couple of hundred items all flattened to one level. Or a document without chapters or paragraphs, only punctuation. A map of a city with one street name (if you use an integer for a house number, that would simplify things radically, who needs all these stupid sectors and street names anyway?).

As a user of other people's work you will always look for hierarchy, for main chunks that represent something. You need to see the forest from the trees to understand anything and zoom in on what you need in a couple of steps. Access modifiers represent just one level in the chain of organisations, systems, applications, modules, name spaces, classes and members.

Answer 6

I don't know of specific research but there is a trove of failed software projects to study. Some of them fail because of their complexity. Complexity of monolithic software grows exponentially with size. Like all exponential growth the complexity eventually exceeds available resources: Throwing more and more manpower at a project will not save it if it is unstructured and too large.

Complexity is reduced through a software engineering paradigm conceived before most of us were born: Divide et impera.

For this, the parts must be loosely coupled or they are not real independent parts.

That's all there is to it. Access modifiers prevent one way of tight coupling by making only a defined subset of their members available to the outside. Enforcing this on the language level as opposed to making it a coding rule is necessary because programmers are notorious for their lack of self-discipline and coding rules are only enforced by rigorous reviews.

Answer 7

In addition to everything that others have said, access modifiers are or can be important documentation. They document what the intended API is. The intended API is often only a small subset of all the methods that are defined. Having methods clearly labeled as "Not intended for use by clients" helps to avoid mistakes, and find the correct methods to use. In addition, that contract is checked by the compiler, great!

Answer 8

Do access modifiers matter? Yes they do. I think the answer with the python example is illustrative enough. However, there are some pitfalls on this, especially considering how it is often used in the java world:

• You have to be honest with your access modifiers.
• What is public will be treated as public by any user of your class. You might not be able to change or remove public methods if users of your class are not under control
• As much as visibility, mutability matters.
• In larger systems decoupling is often already done by using interfaces which only expose the public methods but not any members or even the concrete implementations

Nothing makes a class more complicated than having 10 members with a trivial, often auto-generated getter and setter. It is not useful in any way to make the variable foo private and provide a direct, unchecked setter like this

    class Foobar {
      private Foo bar;

      public void setBar(Foo bar) { this.bar=bar; }
      public Foo getBar() { return bar; }
    }

In this case you have gained nothing on a public variable but added two methods to your class. And if everybody can directly set (almost) all your members you have not decoupled in any way. At the same time, knowing that something is immutable can make life easier as a caller.

So I would recommend the following

• If you have a primitive type and it is immutable, make it public and final
• For methods try to rely on interfaces for information hiding, not on individual classes. It allows you to exchange a bunch of collaborating classes without external dependencies
• For variables of complex types try to pass them during construction (if possible). Avoid trivial getters and setters as much as possible