Recently I came across this post on www.builderau.com.au. The article is talking about how the author was attempting to figure out how to put a private variable onto a class in Python and how his efforts were fruitless. And so, like any good programmer, he questions the very need for a feature that isn't in his language of choice. And also, like a good programmer, I *completely* disagree with him. Now before I get into this rant, be aware that I do not know the author in question and I have nothing against him, I simply to not agree with him.

I am a Microsoft programmer as most of you know, and I write daily in C# and VB.net. I have written Delphi, Java, Javascript, Pascal, and a bit of C++ and Ruby, and have found that every language has its upsides and its downsides. In fact, most all languages have features that some people consider to be deficiencies. Just look at arguments over static typing versus duck typing and case sensitivity out there. They all boil down to personal preference (I'm sure a lot of people will even argue that), and the people that love dynamically typed languages are just not going to bend to people who want the compiler to check their types, and vice versa.

So, having said that, I still completely disagree with the argument that having private variables on a class in any way limits the "potential" of my code. Unless, if by "potential" you mean the potential to completely break in totally unexpected ways. One of the core tenets of object oriented development is encapsulation and having worked in several systems of varying complexity I cannot imagine what a system would look like if you had different objects going around modifying other objects private variables as if they owned them.

The whole purpose of software, and modern programming constructs, is to manage complexity. The encapsulation of data inside of a class limits the number of parts of the application that can interact with said variable, thus decreasing complexity. I would argue that the biggest problem in development is the growing complexity of code, and the feature interactions that come out of this. When Object Oriented programming was first thought up it was so that objects could encapsulate and control their own data. This would reduce complexity because now you could guarantee that certain data could only be accessed and modified by a controlled subset of methods, therefore limiting the number of potential interactions in your code, which in turn reduces complexity.

Although, in *some* instances being able to get to private variables might be useful, and even in .net you are able to do this using reflection. But just because you are able to doesn't mean you should, and in fact, there really should be very little reason to ever go into a class and modify a private variable. If you have enough knowledge of the class to modify the variable with complete confidence then you should probably rewrite it to do what you want without the need to delve into its nether regions. The class itself defines a contract through its properties and methods for what it is able to accomplish and by modifying internal parts of it you are compromising this integrity, which means that no other part of the system can trust that it is fulfilling its contract.

Another thing that I just don't understand is that this argument falls apart even more when you consider that Python isn't compiled. If you are working in a dynamic language then you are almost certainly going to have access to any code that you are calling. So, instead of manipulating the variables in a class directly, why wouldn't you just modify the class to do what you wanted? Or if you weren't able to modify the class, then surely you could just inherit from it and override the parts you don't like.

The author might have a *bit* (this is one tiny tiny bit) more of an argument if he was working in a compiled language, and therefore he could not directly modify the code. Then you might have some reasons why you would want to modify private variables, but in this case you would be flying blind and could accidentally modify something that could have unpredictable consequences. Also, the author says:

"There's a lot to be said for defensive programming, but after a certain point it's reducing the power of our code. I could see the argument towards field safety if you were distributing a library and you wanted to reduce the possible bugs others could write using your code, but for the majority of cases it appears that it's motivated out of a fear that users will tamper with the programmer's perfect code, in nothing less than a malicious attempt to destroy its purity."

I can't help but stare at that sentence in disbelief. I whole heartedly refuse to believe that a majority of programmers *hide* their variables inside of classes because we don't want some other developer to destroy the "purity" of our code. Seriously, who thinks like this? Does this author really think that having private variables is defensive programming? Far from it. Failing fast is defensive programming, unit testing is defensive programming, Design by Contract is defensive programming, and always assuming tampered data is defensive programming. Encapsulation is not defensive programming, it is just common sense.

The author then goes on to reference AJAX as an example of what happens when people use our code in unexpected ways, but I don't really think that this is even remotely a valid argument. First of all, the XMLHttpRequest object *is* being used in exactly the way that Microsoft envisioned it when it was first introduced in OWA (Outlook Web Access). People have begun to use it in many ways (the first popular example of AJAX that most people point out (Google Maps) wasn't even using the XMLHttpRequest object) that were not anticipated by the Outlook team, but not through direct manipulation of its internals. Its interface has been used properly to create many new ideas. If the XMLHttpRequest object had an externally visible variable to set its state, and then I just started resetting its value to whatever I wanted, I'm pretty sure that my efforts would not go very far.

So, in summary, please encapsulate. If I want to extend I will inherit, rewrite, override, replace, whatever...but please don't start exposing your object internals for all the world to see. I thought we left this kind of nonsense years ago.

P.S. We all have different languages that we like, and we all love to defend our particular languages, but we also have to accept that all languages have deficiencies. We have multiple languages for a reason and so make sure you keep in mind...

"If all you have is a hammer, everything looks like a nail."