Can access modifiers be completely replaced with programming to interfaces?

Question

If we program to interfaces various parts of the implementation can be effectively hidden. We can define multiple interfaces for a single implementation and use them as needed, instead of 4 fixed levels (public, protected, package protected, private).

From this point of view Access modifiers seems redundant and limited. From my experience, they also tend to promote bad practices and bad design decisions compared to interface-managed access. The private access modifier seems especially contra-productive on methods because it limits their testability.

Is there some case for access modifiers that can't be handled better in a more systematic way using interfaces?

Answer 1

Access modifiers and interfaces serve different purposes in an object-oriented language. An interface is used in cases where you desire loose coupling and polymorphism. Access modifiers are used to promote data hiding and encapsulation at the compiler level.

The critical flaw with using interfaces for data hiding and encapsulation is revealed when down-casting an interface to a concrete class. Most OO languages allow you to do this:

public interface IFoo
{
    void Something();
}

public class Foo : IFoo
{
    public void Something() { }
    public void DoNotCallMe() { }
}

IFoo foo = new Foo();

foo.Something(); // <-- "allowed" by the interface

Foo bar = (Foo)foo; // <-- cast IFoo down to concrete Foo

bar.DoNotCallMe(); // <-- this compiles and executes at runtime

This allows code to circumvent restrictions provided by the interface if you are willing to risk a runtime exception. Most programmers, since it compiles, will ignore the runtime risk, because they got something to work.

Access modifiers prevent unauthorized access at compile time. If you mark a method or field private, even down-casting from an interface to a concrete class prevents careless or malicious programmers from using something inappropriately.

---

A word of caution about languages that support class reflection. You can still circumvent private access modifiers in many languages, but it is a much bigger pain than simply down-casting an object.

Solution: trust that a developer who is using class reflection has a valid use case for doing so (see Object-Relational Mappers). If you do not trust the developer, do not hire them.

Also, a word of caution when using compilers that allow you to turn off access modifiers. Access modifiers are not magic. They are enforced by the compiler, so if you tell the compiler to not enforce this restriction, then you can circumvent those restrictions.

Solution: never compile your application using a compiler you do not trust, and never have someone compile your application if you do not trust them.

Answer 2

It really helps to understand what the keyword interface really is. It’s a hack. A retrofit. Created because they finally figured out how to support multiple inheritance but couldn’t make it work with existing classes. The venders wouldn’t allow a change that would require existing, working, tested Java byte code to be recompiled. So rather than classes that support multiple inheritance we got the keyword interface.

It started with Java and spread to every language that follows Java. And then it stopped. Because it’s not what you do if you have a choice.

If you have a choice you design your language to support multiple inheritance right in your classes. No need for the interface keyword at all.

With this in mind, understand that “program to an interface” simply means to access only what is meant to be publicly available. A keyword interface isn’t required. Just an understanding of what is meant to be public.

And since the understanding is the important thing here you don’t need access modifiers either. Just some way to signal what the public interface is.

And that brings me to Python. In Python you don’t have keyword interfaces. You don’t have access modifiers. You have a convention that says if it starts with an underscore it’s private. And by that we mean you’re on your own if you code against this. We might change it at any time. No whining if we do.

No keywords. No modifiers. Just a clear signal that you’re poking around in the employees only part of the store.

So yeah, access modifiers can be replaced. We can do without a lot of that stuff just with some clear communication.