I feel like touching a sacred OOP cow, but let me do it anyway. Yesterday, I’ve been working on custom resizing of one Flex screen. I was able to use the property unscaledWidth of the mx.core.Application object in onResize method. Then I had to make a change and apply this resizing just to one of the VBox components. Unfortunately, VBox does not expose unscaledWidth property.
Looking up the class hierarchy reveals that UIComponent has the variable unscaledWidth defined, and its description reads
“A convenience method for determining the unscaled width of the component All of a component’s drawing and child layout should be done within a bounding rectangle of this width, which is also passed as an argument to updateDisplayList()”.
But using the word “convenience” here is a stretch, because the variable is defined as protected, which means I can’t just access it just as a property on my VBox.
Why? Because a creator of UIComponent class did not want me to.
Why? Because s/he did not think I’d need access it this way.
This also proves that the person who documented this class is not the one who created it, otherwise the word convenience would not be used.
And it is inconvenient, indeed. As a workaround, I’ve created a subclass of the VBox and made unscaledWidth and unscaledHeight publicly available:
package
{
import mx.containers.VBox;
public class VBoxScalable extends VBox
{
public function get unscWidth():Number{
return unscaledWidth;
}
public function get unscHeight():Number{
return unscaledHeight;
}
}
}
Here comes the question. Why creators of a framework even use protected variables?
I’ve been asking this question for a while on different forums, and blogged about it in the past, and so far no one was able to give me an answer other than “Because the creator of this class wanted you to use this variable only from a descendant of the class”.
In my opinion, this is wrong. If you want to give me an access to a class variable, make it public, otherwise make it private. It’s either a yes or a no. You can’t be a little pregnant, really.
Now it’s your turn: please explain me why do we need protected variables?
Yakov Fain
tearaway_Tea said,
October 25, 2007 @ 5:53 pm
Yeah, I totaly agree with you. There is no sens of using protected properties and fields only methods.
dejager said,
October 25, 2007 @ 6:56 pm
The short answer is, we need protected variables and we don’t need protected variables. If anything, the protected keyword communicates a designer’s original intention for a property. Whether you use it or not in your own code should be a decision that is left entirely up to you. This being said we should be respectful of the fact that other designers may have logical reasons for wanting to limit the accessibility of a property, even if these reasons aren’t apparent to us at first glance. Some people choose to lock their front door and only give themselves and their children access to the things found in their house, while others live without doors have no qualms about exposing all of their possessions to the world. Both examples are based on personal preference, neither of which is right or wrong. However, while the person without doors may not mind you wandering through their house using their possessions, a person who chooses to live with their doors locked may require of you certain requirements (some type of relationship, a request to use one of their possessions, etc), even if you personally would never ask those things of someone else. These requirements, though not stopping you (you could always crawl through an open window, getting around a locked door), do set up guidelines for how the designer (owner) of the properties (possessions) expects others to interact with her/his objects. We should respect these guidelines and try to work within them whenever possible, even if the requirements for doing so seem a bit wacky from our point of view.
vsilaev said,
October 26, 2007 @ 10:38 am
Yakov,
Very strange way to override a property to make it public. Should be something like this:
package {
import mx.containers.VBox;
public class VBoxScalable extends VBox {
override public function get unscaledWidth():Number { return super.unscaledWidth; }
override public function get unscaledHeight():Number { return super.unscaledHeight; }
}
}
Anyway, let me disagree with you regarding protected variables. There are 3 roles involved here:
– Framework Developer (developer who puts “protected” visibility modifier)
– Custom library / component developer (who may use framework class as base and use all protected properties and even expose them to public)
– Application developer (who assembles application from components provided by [1] and [2])
In fact, you have to play both roles [2] and [3] during development, but I can’t say this is limitation. So when your cursor is placed somewhere between mx:Application tags you definitely may find certain design decisions of [1] boring, but if you quickly change your role from [3] to [2] you can easily fix this
“Private” is real limitation — just use some functionality “as is”, or reproduce it completely. “Protected” is just a friendly hint — this code may have side effects that are better controlled inside component code rather then from outside.
Anyway, [2] may always decide: ok, there is nothing wrong for these properties/methods to be public, at least for known set of applications (typically developed within same company). [1] has no such freedom for similar decisions.
VS
Yakov Fain said,
October 26, 2007 @ 11:51 am
You can\’t override a function increasing its accessibility.
But neither you nor dejager are answering my question: why Framework Developer put the protected modifier in the first place? Because he was under impression that the only way to use it is by forcing Component developer create a subclass? Why does this Framework developer forces me to use inheritance and not composition?
What you call a \”friendly hint\” can be better called \”Framework Developer is not sure how this particular property is used by other components of the framework, so he decided to declare it protected just in case\”.
Your arguments are not convincing.
dejager said,
October 26, 2007 @ 12:20 pm
The original question I addressed was, ‘why do we need protected variables?’ Not ‘why Framework Developer put the protected modifier in the first place?’ If you wanted a definitive answer to your second question I’m sure you can get one from any number of the engineers working on the Flex framework. From my experience I’ve found them to be quite transparent.
judah said,
November 15, 2007 @ 8:36 pm
I wrote a similar post about private variables (http://www.judahfrangipane.com/blog/?p=77). Chuck made a good point that if some variables were made protected or public the result could lead to buggy behavior.
I asked some of the Flex engineers why and they said that unless it was deemed necessary, they would use private variables instead of public because of optimizations made by the compiler on private variables. I’m not sure if those same optimizations are available to protected variables but I don’t use protected variables. The reason I sometimes use private variables is because I don’t want an application developer or user of my components to see every single property on my class. It would be way too much and too many “similarly” named variables where the only one I want them to use is the one I mark public. But I really think protected variables have been misapplied. I think they should be in the same class as mx internal. If they were still accessable but with an implied warning that may they not be safe to use and not show up in MXML code hinting then I think we might solve the reasons behind why protected variables were created. IMHO