Comments on: Who needs protected variables?

By: George Birbilis

George Birbilis — Tue, 30 Jan 2007 15:41:12 +0000

BTW, Delphi also doesn’t behave totally purely regarding protected fields, classes defined inside the same unit can treat them as public field. With recent Delphi versions introducting packages concept, maybe they also extend it this protected-fields access to packages scope, but I think not. They must have added a “Protected Friend” concept like in VB.net for that case

By: George Birbilis

George Birbilis — Tue, 30 Jan 2007 15:39:25 +0000

Java allows protection even against the scenario you describe, using a concept called “sealed packages”. Else it would be totally insecure to you protected variables cause third party runtime code could mess up with your code (exploit). I’m speaking of running code protection, cause at the disk level, before you run the JVM / classloader, you can open up the JAR files (they are of .zip format) and mess up with the third party classes (unseal the package [at the manifest.mf file], decompile its code etc.). Even if that package is signed you can do various tricks (load the classes via your classloader, store them again to another .zip and mess up with them there, then load that unsigned package or resign it yourself)

By: Josh Tynjala

Josh Tynjala — Mon, 02 Oct 2006 23:16:03 +0000

In the switch to the new version of ECMAScript, the private keyword from AS2 received a new meaning in AS3. Now, with private, you can no longer access a variable in subclasses. The protected keyword works like the old private.

Certainly, if you want to let anyone use a property, you should make it public. There are situations where you want subclasses to access your variables, but not everyone. For example, I often make subcomponents protected so that they can be manipulated by subclasses. Most of the time, a component user doesn’t need to access those subcomponents. If they do, they should probably be subclassing anyway.

By: Barney

Barney — Mon, 02 Oct 2006 19:58:53 +0000

Protected is a very important distinction. It’s not so much about the protection of the variable as it is protection of the API. Typically you see this to describe the access levels:

public : anyone
protected: pacakge and subclasses
private: this class (and it’s inner/nested classes)

However, better to think like this:

public: public API
protected: implementation API
private: private implementation API

Recast the terms like this, and it becomes quite obvious why the different levels. A protected member is tied to the implementation of a class that subclasses (i.e. classes that share part of it’s implementation) need to be aware of, but which classes that don’t share implementation shouldn’t care about (because it’s not part of their interface). A public member should be totally detached from implementation.

Of course, it’s easy to botch up your access levels and make something protected that should be public (or the converse), but that’s not an argument for not having the different levels, it’s an argument for ensuring you understand the tools you’re using before you use them.

NB: each language has specifics that may differ (e.g. Java’s “default” scope). I wasn’t aiming for completeness.