Long before I joined ThoughtWorks I wrote a Data Access framework with a very simple public interface. The entry point to the framework was a IDataManager interface that contained Save(..), Delete(..), and Find(..). The framework was composed of several collaborating classes, but only the IDataManager interface was public. I designed the code this way because of fear. I was afraid that if I gave developers the rope, they would hang themselves.
During the development of this framework I came up with the idea of Accessing Private Members using conditional compilation. While interviewing with ThoughtWorks I briefly discussed this situation with Greg Warren. He suggested (but did not take credit for the idea) using a correctly scoped interface and making the methods of the concrete classes public. At the time, this sounded like a large risk. I didn't trust the other team members enough to give them that option.
Since joining ThoughtWorks, my opinion has completely changed. I now subscribe to the idea that a language should only have public and protected access (which I first heard from Zak Tamsen). So many language constructs are designed to protect us from ourselves that we often tie our own hands together. I'd prefer to have the rope and see what I can do with it. However, I strongly believe that I changed my mind based on the fact that I now trust the team I am working with. Because of this trust I don't feel I need to tie their hands together. And, with untied hands, my teammates produce some pretty brilliant ideas.
To me, this proves once again that People Matter Most.
It seems to me that an important use of visibility is in the documentation of a class. I like to know that the designer has created the class to be used through its public methods and properties. When a class has had some or all of its private members made public - solely for the purpose of testing them - you lose this information about how the class was intended to be used. Unless, of course, the designer decorates each member with comments saying whether it is meant to be used or not.
ReplyDeleteAlso, where a set of classes are compiled into a DLL for distribution to end users, it presents a risk if an enterprising developer can reference your DLL and start to drive its private methods from his own program.
What would be great would be a compiler mode that made all private members public for testing, with perhaps attributes to override this member by member where it caused a problem.