Michiel and I disagree over the design of the data structure to hold
settings which control the generation of text in the notation subsystem and
he considers this an "architecture level" decision, so asked that it be
opened to general discussion. Examples of the types of settings are things
like whether to use <<angle brackets>> or «guillemots» for stereotypes,
whether 1..1 multiplicities should be displayed as "1" or blank, etc.
The current design uses a raw HashMap<String, Object> to hold these settings
with the String keys being free form text. To change a setting, the caller
uses something like
getNotationArguments().put("visibilityVisible", Boolean.TRUE)
and then all the current arguments are passed to the text formatter in the
notation subsystem by something like
notationProvider.toString(modelElement,
modelElement.getNotationArguments())
where the formatter will check for the an entry with the key
"visibilityVisible" if it uses that in its formatting decisions.
I propose storing all notation settings in an explicitly designed
NotationSettings value object with setters/getters for each setting. The
example above would look like:
getNotationSettings().setShowVisibility(true);
and then the formatter would use
notationSettings.isShowVisibility()
to check the specific settings that it is interested in.
The problems that I see with the current design include:
- it's opaque - there's no way to tell who is using what settings without
searching for magic strings in the source code
- it's not opaque - the implementation type of the setting storage (i.e Map)
is exposed through the API
- it's big - hundreds of bytes vs dozens of bytes (ie 10X worse space
performance) for *every* Fig in the project
concretely 224 bytes vs 24 bytes for four settings entries on a 32-bit
machine
- it's slow - keys have to be hashed and then searched for
- it's error prone - since the keys are typed free form by hand every time,
any typo will cause things to stop working
There's a general discussion of why our existing design isn't a good idea on
the SAP blog and I agree with everything they've written.
https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/5163
My proposal will be smaller, faster because each setting is directly indexed
as a field in the object, less error prone because the compiler will check
all names, more transparent because we'll be able to easily tell which
settings are used where. For cases where extensibility is needed,
NotationSettings can be subclassed and extended with additional
setters/getters, so we don't lose the extensibility aspects of the current
design.
I am strongly in favor of changing the design, but I wanted to give others
the opportunity to defend the current design if they think it is a better
fit for the requirements of the task.
Discuss!
Tom
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=985204
To unsubscribe from this discussion, e-mail:
[[email protected]].
