Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

More on getters and setters

Build user interfaces without getters and setters

By Allen Holub, JavaWorld.com, 01/02/04

Page 2 of 6

(Digression: Some of you will balk at the previous statement and scream that VB is based on the hallowed Model-View-Controller (MVC) architecture, so is sacrosanct. Bear in mind that MVC was developed almost 30 years ago. In the early 1970s, the largest supercomputer was on par with today's desktops. Most machines (such as the DEC PDP-11) were 16-bit computers, with 64 KB of memory, and clock speeds measured in tens of megahertz. Your user interface was probably a stack of punched cards. If you were lucky enough to have a video terminal, then you may have been using an ASCII-based console input/output (I/O) system. We've learned a lot in the past 30 years. Even Java Swing had to replace MVC with a similar "separable-model" architecture, primarily because pure MVC doesn't sufficiently isolate the UI and domain-model layers.)

So, let's define the problem in a nutshell:

If an object may not expose implementation information (through get/set methods or by any other means), then it stands to reason that an object must somehow create its own user interface. That is, if the way that an object's attributes are represented is hidden from the rest of the program, then you can't extract those attributes in order to build a UI.

Note, by the way, that you're not hiding the fact that an attribute exists. (I'm defining attribute, here, as an essential characteristic of the object.) You know that an Employee must have a salary or wage attribute, otherwise it wouldn't be an Employee. (It would be a Person, a Volunteer, a Vagrant, or something else that doesn't have a salary.) What you don't know—or want to know—is how that salary is represented inside the object. It could be a double, a String, a scaled long, or binary-coded decimal. It might be a "synthetic" or "derived" attribute, which is computed at runtime (from a pay grade or job title, for example, or by fetching the value from a database). Though a get method can indeed hide some of this implementation detail, as we saw with the Money example, it can't hide enough.

So how does an object produce its own UI and remain maintainable? Only the most simplistic objects can support something like a displayYourself() method. Realistic objects must:

• Display themselves in different formats (XML, SQL, comma-separated values, etc.).
• Display different views of themselves (one view might display all the attributes; another might display only a subset of the attributes; and a third might present the attributes in a different way).
• Display themselves in different environments (client side (JComponent) and served-to-client (HTML), for example) and handle both input and output in both environments.

Some of the readers of my previous getter/setter article leapt to the conclusion that I was advocating that you add methods to the object to cover all these possibilities, but that "solution" is obviously nonsensical. Not only is the resulting heavyweight object much too complicated, you'll have to constantly modify it to handle new UI requirements. Practically, an object just can't build all possible user interfaces for itself, if for no other reason than many of those UIs weren't even conceived when the class was created.