OOP Access Modifiers: Compile-time or Run-time

问题:

I've heard that Access Modifiers Public, Private and Protected are just some Compiler Stuff, and they're not actually exists in the compiled Binary Code.

Now I'm wondering how much it's correct? And if it's correct, does it mean that Encapsulation is not exist in the binary code at run-time? So, if you modify the binary to access a Private method illegally, in theory, there isn't anything to check your rights, neither any OOP mechanism nor Operating System, right?

I've also tagged the question for both C++ and Java. I'm aware of the difference between them, just curious to see how different they handle Access Modifiers.

回答1:

Access modifiers are solely a compile time mechanism in C++. In Java however, they are enforced at runtime too, because Java also has a runtime typesystem, and it can dynamically (at runtime) create classes. So it needs to enforce access at runtime too for types it doesn't know about at compile time.

Why use access modifiers?

The sole purpose of access modifiers is to enforce design.

Say you have a class A that you implemented

class A
{
public:
  void DoSomething()
  {
    // use private member mPrivMember to do something
  }
private:
  int mPrivMember;
}

And some code using class A:

A a_obj;

The above code can call a_obj.DoSomething(), however they don't have direct access to mPrivMember, so a.mPrivMember written outside class A will not compile.

Now, why would you want some members accessible to outside code and some not? Well, here is why: at the moment, the method DoSomething() uses mPrivMember to actually do stuff. But after some time, you might decide you want to refactor the code in DoSomething, to improve it. You found a different way to do something that doesn't involve using mPrivMember anymore. So you delete mPrivMember and reimplement DoSomething some other way.

Now, if there was code outside your class using mPrivMember, that code wouldn't compile anymore because you have deleted mPrivMember when reimplementing DoSomething. To prevent existance of such code, you restrict access to mPrivMember. The mechanism to do that is through access qualifiers such as private and protected.

This allows you to refactor code in the future without worrying that other code might use internal members.

Recap

public private and protected are compile time mechanisms in C++. They do not exist in the generated binary form of your program, and thusly such protections are not enforced. Anything is accessible from anywhere.

In Java however, classes can be created at runtime if I'm not mistaken. Which is the reason why it also has to check for access at runtime too so it can enforce them, thus Private Public and Protected do exist in a Java binary.

回答2:

Please note this answer is with respect to Java
Both. If you try to compile code which tries to access inaccessible object or method, you'll get compile-time error:

and at run time, JVM checks the access:

You will get following exception if you try to access at run time. With improper access level java.lang.IllegalAccessError:

Hope it helps

回答3:

Compiled C++ code has no concept of private/protected/public. It goes down to machine code, which has no concept of those. Without native support for that, how could you support them? Better yet, how could you even make native support for that.

Access modifiers are for humans, not for machines. Access modifiers are a design aspect, not a security aspect.

tl;dr: By the time C++ code is actually running the machine has no idea private/public/protected ever existed.