Descriptive Observers

Simulation Modeling Toolkit (SMTK) Tips and Tricks
1

Descriptions for Observers

As one of its primary entrypoints, SMTK’s Observer pattern enables
consuming projects to dynamically interact with SMTK objects. Because
Observers have the ability to change the functionality of an
application, they are a common site for debugging. We have added API
to Observers to describe an Observer as it is inserted, allowing for
the query of an observer’s function during execution.

Structure of a description

Observers now accept an optional additional string for briefly
describing their function. Additionally, the ADD_OBSERVER macro has
been introduced to inject the insertion location as an Observer’s
description.

Currently, Observers in SMTK are described by a terse (or not-so-terse), human-readable description of the observer’s purpose. Since these messages will be commonly sifted when debugging logs, are there any suggestions about a preferred format?

2

Yes:

  • Include the class name at the beginning of the description (make it easy to find the source holding the observer code).
  • When many instances of a class will each have a separate observer, include the address of the instance or some other unique number in the description so people can distinguish instances.