An explicit interface is my preference. If I see anything interpreted by code or by reflection then it smells bad to me.
There is some history in ArgoUML and GEF of passing hashmaps of data around and its something that has made thing difficult for me to interpret and learn. I assume it was seen at one time as being ultimately flexible and extensible but I think there are better ways of doing that. I can look at your arguments but all that is relevant to me is clarity. Clarity is given by a clearly defined interface. A map does not give that. I'd be happy to see a more concrete definition of what make up the notation interface. What is the argument against this? Bob. 2008/12/16 Tom Morris <[email protected]>: > 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=985363 To unsubscribe from this discussion, e-mail: [[email protected]].
