Jonathan Hayward, in making a case for making unobtrusive web designs, makes this comparison with transparent acting:

Good acting does not leave people impressed with how good the acting is. The very best acting leads people to be so involved with the drama and tension that they forget they are watching actors at all. Not all acting reaches that standard — which is a very high standard — but acting has the quality that, at its best, it is transparent: people see through the acting to the important thing, the story.

There is a similar case that can be made in regards to transparency in code design.

I shouldn’t look at a piece of code that think how clever the programmer was. In fact, this is one of my complaints of Perl is its “Write Once” nature. To be truly maintainable, the logic (or point) should be clearly obvious. And this isn’t just for your team mates, for you may be young and clever now, but that may change and you the extra 5, 10 or 50 minutes you spend next week trying to figure out what you did, is time you really wasted on poor design.

There is another use of the term transparency which is a more technically correct that Bruce Tate in his book, Better, Faster, Lighter Java, describes:

When you can separate the primary purpose of a block of code from other issues, you’re building transparent code. A transparent persistence framework lets you save most any Java object without worrying about persistence details. A transparent container will accept any Java object without requiring invasive code changes.

It should be no surprise that I’m in love with… well serious like… okay, we are just going steady right now, but I’m very impressed with the Spring Framework. Many of the design considerations are built with transparency in mind. For instance, you can write your entire application without extending any class, and almost all of your classes don’t even have to implement any particular interface or think about the framework they are in (the exception to this is the controllers which tie models, views, and application logic together).

Compare this with creating a persistent component in EJBs… you have to create 5 Java classes, a deployment descriptor, the database schema, and a partridge in a pear tree. You can’t even unit test the bloody things as it requires the entire framework to be setup before they’ll run.

But Tate’s advice goes for more than just container or framework designers, for in every class you write should have its core contained in that class, and nothing else to distract.

Granted, this is the goal, and in practice, you need to add logging statements, security checks, trapping errors, exceptions and bad usage. Until we are all aspect programmers (and we all will be some day, right?), it will remain a goal.