Feb. 21, 2002; 1100. As tensions in Europe rose and eventually blossomed into war, Clyde was all but forgotten by the public—but not by Tombaugh, who continued to track the asteroid, computing and recomputing its orbit. His results were published in the appropriate journals and noted with growing concern by scientists on both sides of the growing political divide. The odds for a collision with Earth, though still low, continued to rise with every new measurement.
By early 1939, when most scientists realized that they would soon be unable to communicate with their colleagues on the other side of the Atlantic, Tombaugh held an astronomical conference in Stockholm. The conference was well attended, and not just by astronomers; scientists of many disciplines felt that this conference could be their last chance for an international gathering.
Clyde wasn't a major topic of the formal conference, but at the bar and in the lounges, the talk often drifted to "What if? These discussions were more entertaining than serious, but they served to generate some interesting ideas: Some favored destroying Clyde, others deflecting it, and still others argued for an escape to Venus or Mars.
Despite the range of ideas, everyone agreed that the fundamental problem was energy. All these solutions required energies that were beyond our abilities to generate; and so they were all relegated to the status of barroom fantasies.
Then, on the last night of the conference, Leo Szilard, Neils Bohr and Lise Meitner broke the news that their investigations into nuclear reactions suggested that such energies just might be within reach. In view of the political climate, it was clear to everyone there that this news was not all good. A few stayed very late that night to discuss options, whimsically naming themselves "The Stockholm Contingent.
The OO Debate
Jerry, Avery and I went to the observation lounge at the high-G end of the gamma arm, grabbed a cup of coffee and sat at a table watching the starbow whirl under our feet. Jerry looked over the table at Avery and said speculatively, "So, Avery, you complained about my use of public variables in the test fixture we were writing.
Avery grimaced, replying, "Well, it's not a very OO thing to do.
"Can you define OO for me? asked Jerry with a wry smile. "Why are public variables not OO?
"Because OO is about encapsulation, and public variables aren't encapsulated.
"Do you think that OO requires all variables to be encapsulated? Jerry prodded.
"Of course! replied Avery with a touch of indignation.
Seated at a nearby table with Adelade, Jasmine was clearly eavesdropping on our conversation.
Jerry then asked, "What bad thing happens if you have an unencapsulated variable?
Avery made a disdainful face and responded, "Other programs could change your variables!
"What if that's what you intend? Jerry pushed. "What if you want other programs to change certain variables?
"Well, then there's something wrong with your design! Avery proclaimed with righteous annoyance.
Jasmine loomed over our table and said lightly, "Oh pooh, Avery, that's just silly.
As Avery sputtered as though to answer her, Jasmine continued. "Look, it's not the rules, it's the reasons. The aim of OO is to help you manage dependencies. Most of the time, making your variables private helps you to do that. But sometimes private variables just get in the way.
Jerry butted in with, "Now, wait a minute, Jasmine. I agree that OO languages help you manage dependencies, but the more important benefit is expressivity. It's easier to express concepts using an OO language.
"Yeah, sure, Jasmine replied with a barely stifled yawn. "But it's not lack of expressivity that turns software systems into a tangled mass of interconnected modules; it's mismanaged dependencies. I can create very expressive systems that are tangled all to hell. I agree that expressivity is important, but keeping the coupling low is much more crucial.
"How can you say that? Jerry was sputtering this time. "Your approach is so sterile! Where's the art? Where's the finesse? All you care about is that the dependencies go in the right direction!
"What's so artful about nicely named modules that are coupled into a tangled mess? Jasmine replied coolly. "The art's in the structure, Jerry. The art's in the careful management of dependencies between modules.
"Structure is important, sure, Jerry replied, "but—
This exchange seemed likely to go on for awhile, and I really wanted to know about the public variables, because they bothered me, too. So I interrupted them. "Excuse me, Jasmine, Jerry—what does this have to do with public variables?
The two of them looked at Avery and me as though they had just remembered we were there. Jerry said, "Oh, sorry; this is an old argument between Jasmine and me. Look, we make variables private to tell other programmers to ignore them. It's a way of expressing to others that the variables aren't their problem, and that we want them to mind their own business.
Jasmine rolled her eyes. "Oh, here we go again! Look, boys, we make variables private to reduce coupling. Private variables are a firewall that dependencies can't cross. No other module can couple to a private variable.
"That's such an ice-cold view, said Jerry dismissively. "Don't you see how dehumanizing it is?
I wanted to stop this before it got going again, so I blurted out, "OK, but when is it all right for a variable to be public?
Avery seemed to recover himself, glanced at me and proclaimed, "Never!
That stopped Jasmine and Jerry in mid-stride. They both turned to Avery and exclaimed in unison, "Nonsense!
"Look, Avery, Jasmine said, a little more gently. "Sometimes you want to couple to a variable.
"Right, Jerry agreed. "Sometimes a public variable is the best way to communicate your intent.
"When is that? Avery asked with a touch of disbelief in his voice.
"Well, like in a test fixture, Jerry replied. "The data used by the fixture comes from one source, but the test is triggered by another. One party has to load the data, and the other party has to operate on it. We want to keep them separate.
"Right Jasmine chimed in. "It's all about the coupling. The important thing is that the source of the data isn't coupled to the application being tested. The fact that the variables in the fixture are public is harmless.
"But what if someone uses them? complained Avery.
"Who would? Jerry asked. "They're variables in a test fixture. Everybody on this project knows that those variables are under the control of FitNesse and aren't for anyone else to use.
"But they might! Avery insisted.
Jasmine rolled her eyes and said, "Yeah, and they might take one of your private variables and make it public. What's the difference?
Avery spluttered some more, but couldn't face her down. So I jumped in with the obvious question, "But couldn't you use setters and getters? Why make the variables public?
"Exactly! Avery blurted.
"Why bother? Jerry responded.
"Right, Jasmine agreed. "It's just extra code that doesn't buy you anything.
"But I thought getters and setters were the right way to provide access to variables, I replied.
"Getters and setters can be useful for variables that you specifically want to encapsulate, said Jerry, "but you don't have to use them for all variables. In fact, using them for all variables is a nasty code smell.
"Yep! responded Jasmine with a grin. "PeeYew! There's nothing worse than a class that has a getter and setter for each variable, and no other methods.
"But isn't that how you're supposed to implement a data structure? I asked.
"No, not at all. Jasmine replied. "A class can play two roles in Java. The first is as an object, in which case we usually make the variables private and provide a few getters and setters for the most important variables. The other role a class can play is as a data structure, in which case we make the variables public and provide no methods. Test fixtures are primarily data structures with a few methods for moving the data back and forth between FitNesse and the application under test.
"Right, said Jerry. "A class that has getters and setters but no other methods isn't an object at all—it's just a data structure that someone has wasted a lot of time and effort trying to encapsulate. That encapsulation buys nothing in the end. Data structures, by definition, aren't encapsulated.
"Agreed, Jasmine said. "Objects are encapsulated because they contain methods that change their variables. They don't have a lot of getters and setters, because the data in an object remains hidden for the most part.
"Right, said Jerry.
"Right, repeated Jasmine.
As the two previous combatants smiled at each other like bosom buddies, Avery and I glumly exchanged a glance.
To be continued ... Click here for past episodes and code listings.
Do you have a question for our intrepid space traveler? E-mail Alphonse at: firstname.lastname@example.org.
Robert C. Martin is CEO, president and founder of Object Mentor Inc., in Vernon Hills, Ill., and a frequent speaker at SD conferences.