I learned Object-Oriented programming (and a great many other things) while working in the Electronic Data Systems (EDS’s) Research and Development department in the late 1980’s. A lot of EDS R&D work was done in an internally developed OO language called “OWL” — a language that was inspired by Smalltalk, had an S-Expression text syntax for code, and could be interpreted by or compiled into C, running on Sun Unix workstations.
One particularly interesting feature of the EDS OWL programming language was that it supported “Property / Field Transparency” — meaning that there was no absolutely no difference, in client usage syntax, between use of “public fields” and the use of “properties” (where data access is mediated through code in getter and setter methods).
The big advantage of Property-Field Transparency is that you can safely DoTheSimplestThingThatCouldPossiblyWork, while writing code, by making all business object fields public. Should you discover later that you need an additional layer of abstraction, you can easily change a public field to a Property, and code the appropriate getter and setter methods, without making any changes to the code that uses that class at all. Thus in languages supporting Property-Field Transparency, you can avoid the source code clutter and maintenance expense of maintaining a great many meaningless repetitive boiler-plate getter and setter methods; and yet you can still quite easily and safely insert them later, where needed, with minimal impact. There isn’t even any need for refactoring support in your IDE, or multiple file checkins.
So it was with great interest that I noticed increasing levels of Property-Field Transparency support in modern languages in recent years: Most scripting languages in the Java environment do this, following the Java Bean standards. (But the Java language itself continues to steadfastly buck the trend!) And in the Microsoft environment, COM and then the .NET environment seem to have embraced support for properties — giving developers fairly good Property-Field Transparency across the board.
But it still annoys and troubles me that most of the industry seems to be avoiding taking advantage of Property-Field Transparency to simplify their code and reduce their costs. Sometimes most of the industry seems to be hooked on “Cargo Cult” practices and ideas — that is, we keep doing things that were the best thing to do at one time, but may no longer be appropriate now — possibly because the practitioners have long since stopped thinking about WHY they’re doing the things they’re doing, and just continue rote practices with the justification that “A great man said that we should do it this way some years go. How dare we question that?”
It was my experience with Property-Field Transparency in the EDS OWL language that inspired me to post some of my ideas on this topic by creating the PropertyFieldTransparency page on one of my favorite web sites, Ward’s Wiki:
Jeff Grigg's Blog 