Ruben’s blog

Yes, I think most people get the closed for modification part, but probably often don’t think enough about the open for extension part. In AS3, this means judicious use of protected methods and vars. I have heard several complaints about the Flex framework where certain members are private, which makes it hard to extend a particular component or class.

Spot on, in fact that was part of what started the discussion in the first place. Of course most (if not all) components in the Flex framework have their protected methods (commitProperties, createChildren, etc.), but almost all non-public variables are declared private (instead of protected).
This makes the protected methods a lot less useful seeing that added features in most cases will have to be completely new, instead of functionality that is built upon existing functionality in the original class..

I believe that most private variables can be made accessible with property functions (the so-called getter’s and setter’s) If you add this functionality to your class then extending classes don’t have to touch the private parts
I’m always a bit cautious adding protected variables, because you then release your control upon that variable. May in the future this variable change (ie: you want it to be 10% less) then the extending classes won’t pickup on this change, therefor building further upon bad data. With getter’s and setter’s you simply can change with it returns.
Your thoughts about this?

That’s actually a very valid point. Regarding releasing control upon protected vars, you can take the pros and leave the cons by creating a private setter and a protected (or even public) getter as to make a property read-only for subclasses.

Unfortunately in AS3 there’s a bug that throws a compile-time error when corresponding getters and setters don’t have the same namespace attribute:
Ambiguous reference bug for namespaces in Flex

Of course you could consider working with actual methods (function getMyProperty() instead of function get myProperty()), but I suppose that would kind of prevent data-binding from being applied (not completely sure there though), as far as Flex goes that is.

It’s dangerous to apply open/closed to designing classes in general.

Generally you want your code to clearly convey your intent. You should be able to ‘read’ what your code is doing. We try to use strong metaphors so that knowledge transfer about what a class does can be achieved by using things which we may already be familiar with. We group classes with similar notions using naming conventions (ie SubclassSuperclass). Even classes are organized in hierarchies so that we can better describe what we are trying to do. All of these things we do so that we, as well as other people, have a better time using our code after we have written it.

Ideally you would expect the same thing from how your code executes. You try to keep the consequences of changing some aspect of the class only within the class itself, which makes it relatively easier to make changes because the effects are immediately apparent. Allowing a field to be modified from anywhere within the application creates a situation where making a change can have consequences anywhere within the application, which in turn makes that change more difficult to make.

Introducing fields which can be accessed directly (either public, or protected) isn’t wrong, it just has it’s effects. It can be made much more apparent in the case of a code base that is distributed and likely to evolve. After a field has been released and is accessible you must support it in any updates. I suppose you could just remove it, but then I’d be dissapointed

By making a field public you are also providing explicit information about how a class structures it’s state, which makes it more difficult to change if you ever need to (which is probably pretty likely).

If you are asking yourself whether or not a set of properties (or even just one) should be accessible (or even exist within that class), it may be an indication that there is a bigger design problem, but then again getting done and going home is important too.

Meh I don’t know, as usual Ruben, just me rambling

Right on Michael, though my intention has never been to tell anyone that making your vars public or protected was in fact wrong. I’m also not completely sure if I agree that applying the open/closed principle is dangerous by definition, as a matter of fact I reckon that it might in fact be a pretty good point to start from, with of course a line of exceptions to the rule.

My rule of thumb is to use protected for data that simple-access, that is, just holding a value. I use private for fields that are complex-access, that is, has dependencies.

For example, if you were keeping track of a bunch of personal information, protected is fine. If you were keeping track of the length or amount of some chunk of data, private.

That said, most of my stuff I leave protected.

Yeah sounds pretty sensible, thanks man.