AccessModifier

encapsulation · language feature

tags:

Object-oriented languages divide a program into modules called classes. Each class contains features, which consist of data (fields) and methods. (Not all languages use these terms, but they'll do for this.) Languages have various rules about what other classes can access the features of a class, these are often based on access modifiers that apply to a class.


C++ Choice

Probably the most influential set of access modifiers started with C++, which has three.

  • public: Any class can access the features
  • protected: Any subclass can access the feature
  • private: No other class can access the feature

A class can also give access to another class or method with the friend keyword - hence the comment that in C++ friends can touch each others' private parts.


Java

Java based itself on C++. It added the notion of package to the language, and this influenced behavior.

  • public: Any class
  • (package): (The default, and doesn't use a keyword in the code) Any class in the same package
  • protected: Any subclass or class in the same package
  • private: No other class

Notice the subtle distinction between Java's protected and C++'s protected (just to keep things confusing.)


C#

C# also is based on the C++ model

  • public: Any class
  • internal: Any class in the same assembly (default for methods and classes, but may be specified)
  • protected: Any subclass
  • protected internal: Any subclass or class in the same assembly
  • private: No other class (default for fields)

In C# an assembly is a physical unit of composition - equivalent to a dll, jar, or binary. C# also has logical units (namespaces) that are similar to java packages, but they don't play in access modifiers.


Smalltalk

Smalltalk is often considered to be the purest OO language, and predates C++, Java, and C#. It didn't use keywords to control access, but used a basic policy. Smalltalkers would say that fields were private and methods were public.

However the private fields don't really mean the same as what they mean in C++ based languages. In C++ et al access is thought of as textual scope. Consider an example with a class Programmer which is a subclass of class Person with two instances: Martin and Kent. In C++ since both instances are of the same class then Martin has access to the private features of Kent. In Smalltalk's world view access is based on objects, so since Martin and Kent are different objects Martin has no business getting at Kent's fields. But again, since everything is object based Martin can get at all his fields even if they were declared in the Person class. So data in Smalltalk is closer to protected than private, although the object scope makes things different in any case.


Access control does not control access

If you have a field that's private it means no other class can get at it. Wrong! If you really want to you can subvert the access control mechanisms in almost any language. Usually the way through is via reflection. The rationale is that debuggers and other system tools often need to see private data, so usually the reflection interfaces allow you to do this.

C++ doesn't have this kind of reflection, but there you can just use direct memory manipulation since C++ is fundamentally open memory.

The point of access control is not to prevent access, but more to signal that the class prefers to keep some things to itself. Using access modifiers, like so many things in programming, is primarily about communication.


Published Methods

I've argued that there is really room for another access type: PublishedInterface. I think there is a fundamental difference between features you expose to other classes within your project team and those you expose to other teams (such as in an API). These published features are a subset of public features and have to be treated differently, so much so that I believe that the distinction between published and public is more important than that between public and private..