Bitter JSPs - Bitter Java - page 105

R EFACTORED SOLUTION TYPE : Software.
R EFACTORED SOLUTION DESCRIPTION : Command granularity should be
based on the model, not the view. Commands should contain fields that
are logically grouped and frequently used as a unit by clients of the
command.
T YPICAL CAUSES : New programmers tend to make command granularity
match the user interface so that there is one command for every page,
defeating reuse. Lazy programmers might make a command for each
method in a model, defeating the purpose of logical grouping.
S YMPTOMS , CONSEQUENCES : If the granularity is too coarse, commands
must be created for every user interface regardless of which model parts
are being reused. User interface redesigns significantly change the com-
mand architecture. If the granularity is too fine, commands are always
used in the same groups, and the solution is susceptible to the Round-
tripping antipattern.
Fat Commands
D ESCRIPTION : Functionality that belongs in the model or controller can
creep into the command layer.
M OST FREQUENT SCALE : Application.
R EFACTORED SOLUTION NAME : Model-based commands.
R EFACTORED SOLUTION TYPE : Software.
R EFACTORED SOLUTION DESCRIPTION : Commands should contain only a
thin wrapper around the model. The command layer is not the place for
general-purpose utilities or view logic.
T YPICAL CAUSES : The command layer is lightweight, and it's easy to
implement and use. Consequently, lazy or ignorant programmers might
use this layer as the default dumping ground for new functionalities.
S YMPTOMS , CONSEQUENCES : The base command methods contain public
methods beyond get , set , init , and execute . Command layers signifi-
cantly change with every model revision. The command layer looks like a
utility collection. The design is difficult to read.