Many thanks to Tristan Morris for creating a beautiful illustrated hardcover print edition of the site

tcc-case-title
extremely geeky  extremely geeky

Case 167

Back to Basics

Old master Banzen had volunteered to mentor the Spider Clan during master Suku’s travels, but as the months dragged on the experience had worn his nerves quite thin. In one critical application, the components written by different developers were somehow stepping on each other, leading to strange runtime errors.

In desperation, Banzen procured a bottle of huangjiu from master Bawan, downed half of it, and summoned his apprentice Djishin.

- - -

A week later, Djishin reported on his progress:

“Our problem lies with the Java servlet’s session and request contexts, where we store data for state and rendering. These contexts are HashMaps whose values are Objects and whose keys are Strings of the developer’s choosing. Since each developer has chosen their keys without consulting their peers, one component will sometimes overwrite the context values used by another—often with an object of an entirely different type.”

“What solution, then?” asked Banzen, uncorking his bottle.

“I have created a shared ContextUtil class with sixty String constants, one for every context key used across the application,” said Djishin proudly. “And for each key I have provided a pair of strongly-typed static utility methods to get or set that key’s value in a given context.”

“Much like property methods,” observed Banzen.

“Exactly!” said Djishin. “I am currently devising a namespace convention for keys so that each subsystem may have its own ContextUtil class, providing additional constants and static methods as needed.”

“Much like derived classes,” observed Banzen.

“Exactly!” said Djishin again.

“Excellent,” said Banzen, draining his cup. “So in seven days, by using only simple constants and functions operating on a generic Java hashtable, we have invented... the Object.”