|
|
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
Page 4 of 6
Of course, a drawYourself() strategy means that I (gasp!) put UI code into the business logic. Consider what happens when the UI's requirements change.
Let's say I want to represent the attribute in a completely different way. Today an "identity" is a name; tomorrow it's a
name and ID number; the day after that it's a name, ID number, and picture. I limit the scope of these changes to one place
in the code. If I have a give-me-a-JComponent-that-represents-your-identity class, then I've isolated the way identities are represented from the rest of the system.
Bear in mind that I haven't actually put any UI code into the business logic. I've written the UI layer in terms of AWT (Abstract Window Toolkit) or Swing, which are both abstraction layers. The actual UI code is in the AWT/Swing implementation. That's the whole point of an abstraction layer—to isolate your business logic from a subsystem's mechanics. I can easily port to another graphical environment without changing the code, so the only problem is a little clutter. You can easily eliminate this clutter by moving all the UI code into an inner class (or by using the Façade design pattern).
You might object by saying, "But what about JavaBeans?" What about them? You can certainly build JavaBeans without getters
and setters. The BeanCustomizer, BeanInfo, and BeanDescriptor classes all exist for exactly this purpose. The JavaBean spec designers threw the getter/setter idiom into the picture because
they thought it would be an easy way to quickly make a bean—something you can do while you're learning how to do it right.
Unfortunately, nobody did that.
Accessors were created solely as a way to tag certain properties so a UI-builder program or equivalent could identify them.
You aren't supposed to call these methods yourself. They exist for an automated tool to use. This tool uses the introspection
APIs in the Class class to find the methods and extrapolate the existence of certain properties from the method names. In practice, this introspection-based
idiom hasn't worked out. It's made the code vastly too complicated and procedural. Programmers who don't understand data abstraction
actually call the accessors, and as a consequence, the code is less maintainable. For this reason, a metadata feature will
be incorporated into Java 1.5 (due in mid 2004). So instead of:
private int property;
public int getProperty ( ){ return property; }
public void setProperty (int value}{ property = value; }
You'll be able to use something like:
private @property int property;
The UI-construction tool or equivalent will use the introspection APIs to find the properties, rather than examine method names and infer a property's existence from a name. Therefore, no runtime accessor damages your code.
First, as I discussed earlier, it's okay for a method to return an object in terms of an interface that the object implements because that interface isolates you from changes to the implementing class. This sort of method (that returns an interface reference) is not really a "getter" in the sense of a method that just provides access to a field. If you change the provider's internal implementation, you just change the returned object's definition to accommodate the changes. You still protect the external code that uses the object through its interface.
Archived Discussions (Read only)
(