JavaWorld Forums: Modifier or Editor interface?

If setting the employee's salary is a business requirement, then your employee class may need a setter. However, this does not mean we are completely abandoning encapsulation. The data used by any business logic has to originally come from somewhere. We may not actually store the salary in the form it is passed to the setter (although this never really seems to happen), and we can refrain from having a getter. Even if we do these things, we can still avoid writing clients to the object that use the salary value directly in calculations, and put the code that do those calculations within the class.

Perhaps we could only allow package or protected access to the getter and setter. We could use extension to implement the GUI, or we could place it in the same package (even if it is distributed in a different jar).

Alternatively if you have a GUI editor that just allows you to edit the employee's salary, then the Importer/Exporter interface may well be a good approach. The GUI editor only has to do something with the attributes that it is concerned with (the salary). However, the pattern falls down a bit here as the builder will not have access to all the original data, and so can not reconstruct the original object with just the salary changed. Either the changed data must be re-imported into the original instance with a import() method that does not change an attribute when a null is returned, or else the GUI must hold all those attributes that we are so carefully trying to avoid telling anyone about.

InfoWorld: Modernizing IT

JavaWorld: Solutions for Java Developers